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>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42766F6E.1060300>