Date: Mon, 2 May 2005 21:20:01 +0200 (CEST) From: Sten Spans <sten@blinkenlights.nl> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: net@freebsd.org Subject: Re: if_tap unaligned access problem Message-ID: <Pine.SOC.4.61.0505022116410.709@tea.blinkenlights.nl> In-Reply-To: <42765799.6090201@savvis.net> References: <20050428135120.GB21428@cell.sick.ru> <427111BF.2050607@savvis.net> <42712BAA.4070201@elischer.org> <42715269.3010306@errno.com> <4272743A.2030003@savvis.net> <20050429182819.GP2670@funkthat.com> <42765799.6090201@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 May 2005, Maksim Yevmenkin wrote: > Hello, > >>>>>>> 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? I've tested the code on fbsd-current alpha and it fixes the crash. I was kinda waiting for somebody to test it on sparc, but that's taking a few days longer than expected. I may run a test on one of my own sparcs to verify the results. That said, the issue seems pretty clear-cut, as is the solution. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOC.4.61.0505022116410.709>