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()
> 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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message