Date: Mon, 02 May 2005 11:20:30 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: net@freebsd.org Subject: Re: if_tap unaligned access problem Message-ID: <42766F6E.1060300@savvis.net> In-Reply-To: <20050502180910.GV2670@funkthat.com> References: <20050428135120.GB21428@cell.sick.ru> <427111BF.2050607@savvis.net> <42712BAA.4070201@elischer.org> <42715269.3010306@errno.com> <Pine.SOC.4.61.0504291132520.28551@tea.blinkenlights.nl> <4272743A.2030003@savvis.net> <20050429182819.GP2670@funkthat.com> <42765799.6090201@savvis.net> <20050502180910.GV2670@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote:
> Maksim Yevmenkin wrote this message on Mon, May 02, 2005 at 09:38 -0700:
>
>>>>>>>>i think we have few options here:
>>>>>>>>
>>>>>>>>1) revert back original tapwrite function that was changed in v.
>>>>>>>>1.48 and set offset to 2 bytes in top mbuf
>>>>>>>>
>>>>>>>>2) change current version of tapwrite so it would m_prepend and
>>>>>>>>m_pullup mbuf after m_uiotombuf
>>>>>>>>
>>>>>>>>3) change m_uiotombuf to accept one more parameter - mbuf offset at
>>>>>>>>which data should be copied. there are not that many users of
>>>>>>>>m_uiotombuf
>>>>
>>>>please find and review the attached patch (untested) that implements
>>>>option (3) above.
>>
>>any objections to the attached (revised) patch? can i commit it?
>>
>>thanks,
>>max
>
>
>>Index: sys/kern/uipc_mbuf.c
>>===================================================================
>>RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v
>>retrieving revision 1.147
>>diff -u -r1.147 uipc_mbuf.c
>>--- sys/kern/uipc_mbuf.c 17 Mar 2005 19:34:57 -0000 1.147
>>+++ sys/kern/uipc_mbuf.c 2 May 2005 16:33:41 -0000
>>@@ -1333,7 +1333,7 @@
>> #endif
>>
>> struct mbuf *
>>-m_uiotombuf(struct uio *uio, int how, int len)
>>+m_uiotombuf(struct uio *uio, int how, int len, int align)
>> {
>> struct mbuf *m_new = NULL, *m_final = NULL;
>> int progress = 0, error = 0, length, total;
>>@@ -1342,12 +1342,15 @@
>> total = min(uio->uio_resid, len);
>> else
>> total = uio->uio_resid;
>>- if (total > MHLEN)
>>+ if (align >= MHLEN)
>>+ goto nospace;
>>+ if (total + align > MHLEN)
>
>
> I kinda noticed this a bit ago, but didn't think much of it till now...
> do we want to allow align >= MHLEN if total requires a cluster? since
> if we use a cluster, we'd have enough space for a larger align...
>
well, you got me here :) MHLEN is 200+ bytes, so i can not imagine why
one would want to align something on 200+ bytes. i was kind of hoping
that no one would ever need to align on anything greater then 128 bytes.
perhaps i'm wrong here?
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42766F6E.1060300>