Date: Sun, 11 Aug 2002 02:03:40 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: Alexander Leidinger <Alexander@Leidinger.net>, <bhlewis@wossname.net>, <freebsd-current@FreeBSD.ORG>, <bde@FreeBSD.ORG> Subject: Re: Is anyone else having trouble with dump(8) on -current? Message-ID: <20020811014214.D17412-100000@gamplex.bde.org> In-Reply-To: <200208101504.aa40149@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Aug 2002, Ian Dowse wrote: > In message <20020810152354.470317e4.Alexander@Leidinger.net>, Alexander Leiding > er writes: > >Have a look at Message-ID: <20020606063157.V8685-100000@gamplex.bde.org> > >(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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020811014214.D17412-100000>