Date: Wed, 20 Jun 2001 00:03:59 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Terry Lambert <tlambert@primenet.com>, freebsd-alpha@FreeBSD.ORG Subject: Re: vx, lge, nge, dc, rl, sf, sis, sk, vr, wb users please TEST Message-ID: <3B304ADF.C5131399@mindspring.com> References: <20010619191602.A28591@technokratis.com> <200106200224.TAA24251@usr05.primenet.com> <20010619232624.A29829@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic wrote: > > On Wed, Jun 20, 2001 at 02:24:02AM +0000, Terry Lambert wrote: > > > http://people.freebsd.org/~bmilekic/code/mdevget.patch > > > > Please run this past Bill Paul. > > I already did this. :-) If he approves, I approve. Like that really matters, if he approves... Bill is the Driver God. 8-) > I know. The problem is that the way the alignment > issue is presently handeled is wrong. See, to trick m_devget() > into writing the start of the data offset two bytes into the > target mbuf chain's first mbuf's data region (to make the > alignment OK), what was done was to pass for the `source buffer > address' argument to m_devget(), the actual address of the > source buffer MINUS ETHER_ALIGN (2 bytes). This had the effect > of copying the end of the previous cluster or the end of the > mbuf header (depending on where the source buffer is stored) > to the first two bytes of the target mbuf. Admittedly, this is > a cute trick, but it's wrong. What can happen (and will likely > happen w/ mb_alloc b/c mb_alloc keeps separate maps for clusters > and mbufs, to make address space limitations easier to maintain) > is that the "previous cluster" sits on another page which just > so happens to not be allocated yet, which will generate a page > fault during the bcopy() in m_devget(). Ah. I never see this, the way I allocate and back mbufs. The change makes much more sense now. I wondered why you cared about the potential for "leaking" two bytes of information, when the "leak" only occurred to other things already in kernel space, which could just look at anything they wanted to, anyway. > > Are these changes really necessary for the Alpha to work? > > Absolutely. I wouldn't exactly say "absolutely", unless you are actually measuring significant faulting as a result; I would say that they are harmless. I was just a bit nervous, since I had a long conversation with Bill on this and other nasty topics (e.g. I want to add a new function to the list of externally accessible functions exported by all ethernet drivers; more on that later, after the code is happy). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B304ADF.C5131399>