msdosfs not MPSAFE

[Tz-Huan Huang]

hi,

I have a patch that remove the global variables nambuf_ptr, nambuf_len and
nambuf_last_id entirely. It should be applied on recent 7-current. Please give
it a try, thanks a lot.

http://w.csie.org/~tzhuan/freebsd/msdosfs.diff

Tz-Huan

2007/8/14, Bruce Evans <brde at optusnet.com.au>:
> On Fri, 10 Aug 2007, Kostik Belousov wrote:
>
> > On Fri, Aug 10, 2007 at 01:54:48PM +1000, Bruce Evans wrote:
> >> I wrote yet another patch, with allocation on the stack so that no locking
> >> is required.  This is simpler and doesn't require any new functions.
> >> Unfortunately, it is larger because it changes the interfaces for most
> >> functions.  The interface changes are routine, so this is probably better.
> >> Note that 'struct dirent's are already allocated on the stack.  This
> >> patch adds allocation of 'struct mbnambuf's which are slightly smaller
> >> (~256 bytes).  I think this is just small enough for stack allocation.
> >
> > I agree that this is the best approach. The size of the on-stack
> > structure still make me worry, although ~270 bytes seems to be not too
> > large for 3-pages stack.
>
> Stack growth seems to be nowhere near a problem.  With the extra ~270
> bytes.  ls -lR on i386 uses less than a 1-page stack (about 3.5K,
> including 0x270 bytes for the pcb).  I think the maximum stack depth
> is attained when a debugger trap traps a fast interrupt interrupting
> a page fault in an i/o routine called from msdosfs_readdir().  Unlike
> in RELENG_4, nested interrupts can't occur, so a 1-page stack should
> be enough for everything on i386 (but of course isn't quite enough).
> I didn't try hard to attain the maximum depth, and just looked at where
> the stack got to after running a large ls -lR for a while.  msdosfs_readdir()
> now allocates 0x2b0 bytes on the stack using "subl $0x2b0,%esp" and
> that is now the largest single allocation.  This is without INVARIANTS
> etc.
>
> Bruce
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msdosfs.diff
Type: application/octet-stream
Size: 14114 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070830/742e4ebf/msdosfs.obj