On Tue, 27 Jul 1999, Stephen C. Tweedie wrote:
> Hi,
>
> The patch below brings the large file descriptor set uptodate against
> the 2.3.12-pre5 kernel.
>
> The bulk of the patch is largely unchanged from the version that has
> been in the 2.2-*ac patches for months, except that the fd manipulation
> has been updated to deal with the new files spinlocking.
>
> There is one other thing changed from the 2.2 version of the patch, and
> I'd appreciate a glance over that. We have problems with the existing
> dup2() in 2.3: there is no guarantee that it is atomic. dup2() drops
> the file spinlock, calls sys_close(), then retakes the lock and performs
> a dup(). There is no guarantee that the closed fd hasn't been reused in
> the mean time: that is, "dup2(x,y)" may not actually return fd "y".
>
> The solution I've used is to keep the fdset bit set during the entire
> dup2(). Both the open and close code already have windows where the
> fdset bit is set and the fd array is clear.
That's OK, except that we may get a problem with fork() blindly copying
both the bitmap and array. Probably not fatal.
> I've taken care to ensure that the fast paths don't keep dropping and
> taking the files spinlocks, but a certain amount of extra locking is
> inevitable if we end up growing the tables, and that necessarily grows
> the code paths a little.
I'll look through the patch this night - at least it's much saner business
than the @#$!^ing Intel MMU ;-/
ObIntelMMU: Anybody knows about the conditions when IRET from ring 0 to
ring 3 may give a reboot? Code on the other side of IRET is in core, pl's
on segments are OK, NT is not set, IOPL raised to 3 (in the EFLAGS image
on ring 0 stack) and code on the other side does cli and loops. System
reboots upon or after IRET. Down, not across...
Al
