From owner-freebsd-current Sat Aug 10 8:59:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19B8C37B400; Sat, 10 Aug 2002 08:59:23 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEA9543E72; Sat, 10 Aug 2002 08:59:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA25429; Sun, 11 Aug 2002 01:58:46 +1000 Date: Sun, 11 Aug 2002 02:03:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ian Dowse Cc: Alexander Leidinger , , , Subject: Re: Is anyone else having trouble with dump(8) on -current? In-Reply-To: <200208101504.aa40149@salmon.maths.tcd.ie> Message-ID: <20020811014214.D17412-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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