On Sat, 10 Aug 2002, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Alexander Leiding > er writes: > >Have a look at Message-ID: <[EMAIL PROTECTED]> > >(should be in the archive of audit). > > Ah, I had forgotten about that -audit thread. > > >Short: open shouldn't be able to return EINTR in practice... > > > >My assumptions: > > - Bruce hasn't made a mistake > > - something broke in the kernel (either for a "short" period of > > time, or it's still broken), so we should look for the real > > problem instead > > I had a quick look yesterday, and I found a PCATCH tsleep call in > diskopen(), though I do not know if this is the one that affects > dump. Does open(2) need to loop on ERESTART? Currently it just > maps ERESTART to EINTR and returns the error.
I think I did make a mistake. It is this remapping of ERESTART to EINTR that is the normal way for EINTR to be returned despite SA_RESTART being set. Only a few syscalls do this. The main (only?) ones are open(), connect(), select() and poll(). This is quite different from remapping ERESTART to 0 for read() and write() (these functions avoid returning EINTR if SA_RESTART is set by returning the amount of data if there is some and restarting otherwise; they never restart if there is some data). This is also quite different from doing nothing special in close() -- if kern_descrip.c:close() returns ERESTART (which is quite possible if it is interrupted and SA_RESTART is set), then close() is restarted. > We should fix this broken dump behaviour anyway - I don't think it > matters too much for now whether it is fixed in userland or the > kernel, as it will only affect the tiny set of applications that > receive signals while opening a disk device at the same time as > another open on the same device is occurring (I think). I don't know how open() of a disk device can be interrupted by a signal in practice. Most disk operations don't check for signals. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message