bin/175799: Adding more tools to be used by operator group members (reboot, apm, acpiconf)
>Number: 175799
>Category: bin
>Synopsis: Adding more tools to be used by operator group members
>(reboot, apm, acpiconf)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Feb 03 14:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Olivier Cochard-Labbe
>Release:-current
>Organization:
>Environment:
FreeBSD bigdev.bsdrp.net 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r245977M: Sun Jan
27 13:56:05 CET 2013 r...@bigdev.bsdrp.net:/usr/obj/usr/src/sys/GENERIC
amd64
>Description:
There are only 2 useable tools by "operator" group members:
shutdown (and its child: poweroff, halt, etcÂ…) and mksnap_ffs.
On my HAL-less laptop, I've put my user in the operator group that let
me reboot/power-off it with shutdown.
But I would to be able to suspend-resume it too with zzz (that call apm and
acpiconf).
Here is the list of tool useable by operator group:
/sbin/reboot/
/usr/sbin/apm
/usr/sbin/acpiconf
Here is the thread on the -current mailing-list regarding this proposal:
http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039198.html
>How-To-Repeat:
>Fix:
By applying the simple attached patch.
Patch attached with submission follows:
Index: sbin/reboot/Makefile
===
--- sbin/reboot/Makefile(revision 245914)
+++ sbin/reboot/Makefile(working copy)
@@ -14,6 +14,10 @@
MLINKS+= boot_i386.8 boot.8
.endif
+BINOWN= root
+BINGRP= operator
+BINMODE=4550
+
LINKS= ${BINDIR}/reboot ${BINDIR}/halt ${BINDIR}/reboot ${BINDIR}/fastboot \
${BINDIR}/reboot ${BINDIR}/fasthalt
Index: sys/amd64/conf/GENERIC
===
--- sys/amd64/conf/GENERIC (revision 245914)
+++ sys/amd64/conf/GENERIC (working copy)
@@ -80,11 +80,11 @@
optionsDDB # Support DDB.
optionsGDB # Support remote GDB.
optionsDEADLKRES # Enable the deadlock resolver
-optionsINVARIANTS # Enable calls of extra sanity checking
-optionsINVARIANT_SUPPORT # Extra sanity checks of internal
structures, required by INVARIANTS
-optionsWITNESS # Enable checks to detect deadlocks and
cycles
-optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for
speed
-optionsMALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
+#options INVARIANTS # Enable calls of extra sanity checking
+#options INVARIANT_SUPPORT # Extra sanity checks of internal
structures, required by INVARIANTS
+#options WITNESS # Enable checks to detect deadlocks and
cycles
+#options WITNESS_SKIPSPIN# Don't run witness on spinlocks for
speed
+#options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
# Make an SMP-capable kernel by default
optionsSMP # Symmetric MultiProcessor Kernel
Index: usr.sbin/acpi/acpiconf/Makefile
===
--- usr.sbin/acpi/acpiconf/Makefile (revision 245914)
+++ usr.sbin/acpi/acpiconf/Makefile (working copy)
@@ -4,4 +4,8 @@
PROG= acpiconf
MAN= acpiconf.8
+BINOWN= root
+BINGRP= operator
+BINMODE=4550
+
.include
Index: usr.sbin/apm/Makefile
===
--- usr.sbin/apm/Makefile (revision 245914)
+++ usr.sbin/apm/Makefile (working copy)
@@ -5,4 +5,8 @@
MLINKS=apm.8 apmconf.8
MANSUBDIR= /${MACHINE_CPUARCH}
+BINOWN= root
+BINGRP= operator
+BINMODE=4550
+
.include
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/175799: Adding more tools to be used by operator group members (reboot, apm, acpiconf)
The following reply was made to PR bin/175799; it has been noted by GNATS. From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= To: bug-follo...@freebsd.org Cc: Subject: Re: bin/175799: Adding more tools to be used by operator group members (reboot, apm, acpiconf) Date: Sun, 3 Feb 2013 15:54:53 +0100 --bcaec5015f0913dbfc04d4d32a2e Content-Type: text/plain; charset=ISO-8859-1 Oops, it was the wrong patch, here is the good one (that didn't touch the generic kernel config file). --bcaec5015f0913dbfc04d4d32a2e Content-Type: text/plain; charset=US-ASCII; name="More.use.of.operator.group.diff.txt" Content-Disposition: attachment; filename="More.use.of.operator.group.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hcqbaojy0 SW5kZXg6IHNiaW4vcmVib290L01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vcmVib290L01h a2VmaWxlCShyZXZpc2lvbiAyNDU5MTQpCisrKyBzYmluL3JlYm9vdC9NYWtlZmlsZQkod29ya2lu ZyBjb3B5KQpAQCAtMTQsNiArMTQsMTAgQEAKIE1MSU5LUys9IGJvb3RfaTM4Ni44IGJvb3QuOAog LmVuZGlmCiAKK0JJTk9XTj0gcm9vdAorQklOR1JQPSBvcGVyYXRvcgorQklOTU9ERT00NTUwCisK IExJTktTPQkke0JJTkRJUn0vcmVib290ICR7QklORElSfS9oYWx0ICR7QklORElSfS9yZWJvb3Qg JHtCSU5ESVJ9L2Zhc3Rib290IFwKIAkke0JJTkRJUn0vcmVib290ICR7QklORElSfS9mYXN0aGFs dAogCkluZGV4OiB1c3Iuc2Jpbi9hY3BpL2FjcGljb25mL01ha2VmaWxlCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHVzci5zYmluL2FjcGkvYWNwaWNvbmYvTWFrZWZpbGUJKHJldmlzaW9uIDI0NTkxNCkKKysrIHVz ci5zYmluL2FjcGkvYWNwaWNvbmYvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTQsNCArNCw4 IEBACiBQUk9HPQlhY3BpY29uZgogTUFOPQlhY3BpY29uZi44CiAKK0JJTk9XTj0gcm9vdAorQklO R1JQPSBvcGVyYXRvcgorQklOTU9ERT00NTUwCisKIC5pbmNsdWRlIDxic2QucHJvZy5taz4KSW5k ZXg6IHVzci5zYmluL2FwbS9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9hcG0vTWFr ZWZpbGUJKHJldmlzaW9uIDI0NTkxNCkKKysrIHVzci5zYmluL2FwbS9NYWtlZmlsZQkod29ya2lu ZyBjb3B5KQpAQCAtNSw0ICs1LDggQEAKIE1MSU5LUz0JYXBtLjggYXBtY29uZi44CiBNQU5TVUJE SVI9IC8ke01BQ0hJTkVfQ1BVQVJDSH0KIAorQklOT1dOPSByb290CitCSU5HUlA9IG9wZXJhdG9y CitCSU5NT0RFPTQ1NTAKKwogLmluY2x1ZGUgPGJzZC5wcm9nLm1rPgo= --bcaec5015f0913dbfc04d4d32a2e-- ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
The following reply was made to PR kern/175674; it has been noted by GNATS.
From: Jilles Tjoelker
To: Giorgos Keramidas
Cc: Jukka Ukkonen , freebsd-gnats-sub...@freebsd.org,
davi...@freebsd.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
of a separate flock() call
Date: Sun, 3 Feb 2013 21:20:31 +0100
On Sun, Feb 03, 2013 at 06:25:25AM +0100, Giorgos Keramidas wrote:
> On 2013-01-29 18:03, Jukka Ukkonen wrote:
> > >Number: 175674
> > >Category: kern
> > >Synopsis: sem_open() should use O_EXLOCK with open() instead of a
> > >separate flock() call
>
> > >Environment:
> > FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29
> > 07:33:01 EET 2013 root@sleipnir:/usr/obj/usr/src/sys/Sleipnir amd64
> > >Description:
> > sem_open() is calling flock() to set a lock on a newly created file
> > descriptor.
> > That is pointless. The open() call a few lines before the flock() could,
> > and
> > in my opinion should, be done with the O_EXLOCK flag set.
> It's also a bit safer to obtain the exclusive lock atomically before
> open() returns. Waiting for open() to complete and then calling flock()
> has a race condition.
> Jilles and David, do you think this patch looks ok for libc?
> > Patch attached with submission follows:
> >
> > --- lib/libc/gen/sem_new.c.flock 2012-11-09 18:50:05.0 +0200
> > +++ lib/libc/gen/sem_new.c 2012-11-09 18:44:59.0 +0200
> > @@ -198,11 +198,13 @@
> >goto error;
> >}
> >
> > - fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
> > + fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
> >if (fd == -1)
> >goto error;
> > +#if 0
> >if (flock(fd, LOCK_EX) == -1)
> >goto error;
> > +#endif
> >if (_fstat(fd, &sb)) {
> >flock(fd, LOCK_UN);
> >goto error;
For a reason unknown to me, open(2) does not restart but always returns
[EINTR] when a signal is caught. This is not POSIX-compliant. On the
other hand, flock(2) is not broken in this way. So this change breaks
sem_open(3) in the unlikely case that a signal with SA_RESTART arrives
while it is waiting for the lock.
The best way to fix this is in kern_openat() in the kernel but this
might cause compatibility issues.
The #if 0 is silly; we have version control to restore old code if need
be.
--
Jilles Tjoelker
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
The following reply was made to PR kern/175674; it has been noted by GNATS.
From: Giorgos Keramidas
To: Jilles Tjoelker
Cc: Jukka Ukkonen , freebsd-gnats-sub...@freebsd.org,
davi...@freebsd.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
of a separate flock() call
Date: Sun, 3 Feb 2013 21:49:55 +0100
On 2013-02-03 21:20, Jilles Tjoelker wrote:
> On Sun, Feb 03, 2013 at 06:25:25AM +0100, Giorgos Keramidas wrote:
> > On 2013-01-29 18:03, Jukka Ukkonen wrote:
> > > >Number: 175674
> > > >Category: kern
> > > >Synopsis: sem_open() should use O_EXLOCK with open() instead of a
> > > >separate flock() call
> >
> > > >Environment:
> > > FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29
> > > 07:33:01 EET 2013 root@sleipnir:/usr/obj/usr/src/sys/Sleipnir amd64
> > > >Description:
> > > sem_open() is calling flock() to set a lock on a newly created file
> > > descriptor.
> > > That is pointless. The open() call a few lines before the flock() could,
> > > and
> > > in my opinion should, be done with the O_EXLOCK flag set.
>
> > It's also a bit safer to obtain the exclusive lock atomically before
> > open() returns. Waiting for open() to complete and then calling flock()
> > has a race condition.
>
> > Jilles and David, do you think this patch looks ok for libc?
>
> > > Patch attached with submission follows:
> > >
> > > --- lib/libc/gen/sem_new.c.flock 2012-11-09 18:50:05.0 +0200
> > > +++ lib/libc/gen/sem_new.c 2012-11-09 18:44:59.0 +0200
> > > @@ -198,11 +198,13 @@
> > > goto error;
> > > }
> > >
> > > -fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
> > > +fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
> > > if (fd == -1)
> > > goto error;
> > > +#if 0
> > > if (flock(fd, LOCK_EX) == -1)
> > > goto error;
> > > +#endif
> > > if (_fstat(fd, &sb)) {
> > > flock(fd, LOCK_UN);
> > > goto error;
>
> For a reason unknown to me, open(2) does not restart but always
> returns [EINTR] when a signal is caught. This is not POSIX-compliant.
> On the other hand, flock(2) is not broken in this way. So this change
> breaks sem_open(3) in the unlikely case that a signal with SA_RESTART
> arrives while it is waiting for the lock.
I see where kern_openat() returns an error when vn_open is interrupted:
1083 error = vn_open(&nd, &flags, cmode, fp);
1084 if (error) {
1109 if (error == ERESTART)
1110 error = EINTR;
goto bad;
1112 }
> The best way to fix this is in kern_openat() in the kernel but this
> might cause compatibility issues.
Not sure if there would be serious compatibility problems if open() would
automatically restart instead of returning EINTR. It definitely seems a rather
intrusive change though.
> The #if 0 is silly; we have version control to restore old code if
> need be.
That's true. I'm guessing the OP wanted to keep this around for testing
purposes. We don't really need the old code in an #if 0 block.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: conf/19573: Dot Files for Optional Shells
Synopsis: Dot Files for Optional Shells State-Changed-From-To: suspended->open State-Changed-By: eadler State-Changed-When: Mon Feb 4 01:05:16 UTC 2013 State-Changed-Why: I just don't have time to deal with this Responsible-Changed-From-To: eadler->freebsd-bugs Responsible-Changed-By: eadler Responsible-Changed-When: Mon Feb 4 01:05:16 UTC 2013 Responsible-Changed-Why: I just don't have time to deal with this http://www.freebsd.org/cgi/query-pr.cgi?pr=19573 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
On 3 February 2013 16:00, Giorgos Keramidas wrote: > The following reply was made to PR kern/175674; it has been noted by GNATS. > > The best way to fix this is in kern_openat() in the kernel but this > > might cause compatibility issues. > > Not sure if there would be serious compatibility problems if open() would > automatically restart instead of returning EINTR. It definitely seems a > rather > intrusive change though. I can not see major application breakage should open(3) be changed. That said, I am confused by jilles' comment: http://pubs.opengroup.org/onlinepubs/95399/functions/open.html open(3) is permitted to return EINTR. -- Eitan Adler ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
The following reply was made to PR kern/175674; it has been noted by GNATS.
From: David Xu
To: Giorgos Keramidas
Cc: Jukka Ukkonen , freebsd-gnats-sub...@freebsd.org,
jil...@freebsd.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
of a separate flock() call
Date: Mon, 04 Feb 2013 10:05:31 +0800
On 2013/02/03 13:25, Giorgos Keramidas wrote:
> On 2013-01-29 18:03, Jukka Ukkonen wrote:
>>> Number: 175674
>>> Category: kern
>>> Synopsis: sem_open() should use O_EXLOCK with open() instead of a
>>> separate flock() call
>
>>> Environment:
>> FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29
>> 07:33:01 EET 2013 root@sleipnir:/usr/obj/usr/src/sys/Sleipnir amd64
>>> Description:
>> sem_open() is calling flock() to set a lock on a newly created file
>> descriptor.
>> That is pointless. The open() call a few lines before the flock() could, and
>> in my opinion should, be done with the O_EXLOCK flag set.
>
> It's also a bit safer to obtain the exclusive lock atomically before
> open() returns. Waiting for open() to complete and then calling flock()
> has a race condition.
>
> Jilles and David, do you think this patch looks ok for libc?
>
>> Patch attached with submission follows:
>>
>> --- lib/libc/gen/sem_new.c.flock2012-11-09 18:50:05.0 +0200
>> +++ lib/libc/gen/sem_new.c 2012-11-09 18:44:59.0 +0200
>> @@ -198,11 +198,13 @@
>> goto error;
>> }
>>
>> - fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
>> + fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
>> if (fd == -1)
>> goto error;
>> +#if 0
>> if (flock(fd, LOCK_EX) == -1)
>> goto error;
>> +#endif
>> if (_fstat(fd, &sb)) {
>> flock(fd, LOCK_UN);
>> goto error;
>
>
I don't think there is a race condition, the flock is used to ensure
the semaphore is already initialized, whether you use flock or E_EXLOCK,
they are same, because only one thread can lock the file at same time,
and in locked state, the code checks and initializes semaphore if it is
needed.
Regards,
David Xu
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
The following reply was made to PR kern/175674; it has been noted by GNATS.
From: David Xu
To: Jilles Tjoelker
Cc: Giorgos Keramidas , Jukka Ukkonen ,
freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
of a separate flock() call
Date: Mon, 04 Feb 2013 10:08:54 +0800
On 2013/02/04 04:20, Jilles Tjoelker wrote:
> On Sun, Feb 03, 2013 at 06:25:25AM +0100, Giorgos Keramidas wrote:
>> On 2013-01-29 18:03, Jukka Ukkonen wrote:
Number: 175674
Category: kern
Synopsis: sem_open() should use O_EXLOCK with open() instead of a
separate flock() call
>>
Environment:
>>> FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29
>>> 07:33:01 EET 2013 root@sleipnir:/usr/obj/usr/src/sys/Sleipnir amd64
Description:
>>> sem_open() is calling flock() to set a lock on a newly created file
>>> descriptor.
>>> That is pointless. The open() call a few lines before the flock() could,
>>> and
>>> in my opinion should, be done with the O_EXLOCK flag set.
>
>> It's also a bit safer to obtain the exclusive lock atomically before
>> open() returns. Waiting for open() to complete and then calling flock()
>> has a race condition.
>
>> Jilles and David, do you think this patch looks ok for libc?
>
>>> Patch attached with submission follows:
>>>
>>> --- lib/libc/gen/sem_new.c.flock 2012-11-09 18:50:05.0 +0200
>>> +++ lib/libc/gen/sem_new.c 2012-11-09 18:44:59.0 +0200
>>> @@ -198,11 +198,13 @@
>>>goto error;
>>>}
>>>
>>> - fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
>>> + fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
>>>if (fd == -1)
>>>goto error;
>>> +#if 0
>>>if (flock(fd, LOCK_EX) == -1)
>>>goto error;
>>> +#endif
>>>if (_fstat(fd, &sb)) {
>>>flock(fd, LOCK_UN);
>>>goto error;
>
> For a reason unknown to me, open(2) does not restart but always returns
> [EINTR] when a signal is caught. This is not POSIX-compliant. On the
> other hand, flock(2) is not broken in this way. So this change breaks
> sem_open(3) in the unlikely case that a signal with SA_RESTART arrives
> while it is waiting for the lock.
>
> The best way to fix this is in kern_openat() in the kernel but this
> might cause compatibility issues.
>
> The #if 0 is silly; we have version control to restore old code if need
> be.
>
Note that EINTR is allowed to be returned for sem_open().
http://pubs.opengroup.org/onlinepubs/009604499/functions/sem_open.html
Regards,
David Xu
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
The following reply was made to PR kern/175674; it has been noted by GNATS. From: Eitan Adler To: bug-followup Cc: Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call Date: Sun, 3 Feb 2013 21:30:28 -0500 -- Forwarded message -- From: Eitan Adler Date: 3 February 2013 20:52 Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call To: Giorgos Keramidas , Jilles Tjoelker Cc: freebsd-bugs@freebsd.org On 3 February 2013 16:00, Giorgos Keramidas wrote: > The following reply was made to PR kern/175674; it has been noted by GNATS. > > The best way to fix this is in kern_openat() in the kernel but this > > might cause compatibility issues. > > Not sure if there would be serious compatibility problems if open() would > automatically restart instead of returning EINTR. It definitely seems a > rather > intrusive change though. I can not see major application breakage should open(3) be changed. That said, I am confused by jilles' comment: http://pubs.opengroup.org/onlinepubs/95399/functions/open.html open(3) is permitted to return EINTR. -- Eitan Adler -- Eitan Adler ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
On Sun, 3 Feb 2013, Giorgos Keramidas wrote:
> For a reason unknown to me, open(2) does not restart but always
> returns [EINTR] when a signal is caught. This is not POSIX-compliant.
Actually, it is restarting that would be POSIX-non-compliant. From
an old POSIX draft:
@ 27392 ERRORS
@ 27393The open( ) function shall fail if:
@ ...
@ 27399[EINTR] A signal was caught during open( ).
Since it says "shall", this is not optional.
I see where kern_openat() returns an error when vn_open is interrupted:
1083 error = vn_open(&nd, &flags, cmode, fp);
1084 if (error) {
1109 if (error == ERESTART)
1110 error = EINTR;
goto bad;
1112 }
This code is wrong for a different reason. Some lower layers return
ERESTART when there was no interrupt, because they actually want to
restart. The tty top layer and some drivers at least used to do this.
This code breaks the restart, and also confuses applications by return
EINTR when there is no interrupt.
The above code is backwards compared with the usual handling of EINTR
that is done for example in read(). Lower layers should return raw
EINTR and let upper layers convert it to ERESTART, but the above does
the reverse. I don't know why it does that. This hasn't changed since
at least FreeBSD-1.
> The best way to fix this is in kern_openat() in the kernel but this
> might cause compatibility issues.
Not sure if there would be serious compatibility problems if open() would
automatically restart instead of returning EINTR. It definitely seems a rather
intrusive change though.
It would probably break something even if restarting were an option. But
probably the breakage wouldn't be very serious.
The EINTR handling is more of a problem for close(). The old POSIX
draft says much the same for close():
@ 6918 If close( ) is interrupted by a signal that is to be
caught, it shall return -1 with errno set to [EINTR]
@ 6919 and the state of fildes is unspecified. If an I/O error
occurred while reading from or writing to the
@ 6920 file system during close( ), it may return -1 with errno
set to [EIO]; if this error is returned, the
@ 6921 state of fildes is unspecified.
But this behaviour is unusable. EINTR from open() is easy to recover from
in the application, but EINTR with the above specification is impossible
to recover from. The above specification makes it even more unrecoverable
that EIO, since it only says "may fail" for EIO. The latter requires the
system to try very hard to recover before actually returning EIO. But any
reasonable signal handling doesn't have the option of not returning EINTR.
What it can do is try very hard to put filedes in a good state before
returning. But without this state being specified, the application cannot
recover. Moreover, most applications don't even check for success of
close(). This gives broken behaviour for EIO too, but EIO is rare and
usually really is unrecoverable.
Returning of EINTR from close() was discussed in the POSIX list last
year. I didn't like the results. Most systems are very broken in
this area. POSIX requires close() on ttys to flush input, but to wait
(possibly forever, but mostly limited by the length of the sysadmin's
holidays) for any buffered output to drain. This is unusable, and
most systems don't comply with it and have many bugs in their
non-compliance. However, I just noticed that the above part of the
spec allows almost any mishandling for EINTR -- since the state of
filedes is unspecified, it can be anything, so weaselnix is not
non-compliant when it flushes output before returning EINTR.
Bruce
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
On Sun, 3 Feb 2013, Eitan Adler wrote: On 3 February 2013 16:00, Giorgos Keramidas wrote: The following reply was made to PR kern/175674; it has been noted by GNATS. > The best way to fix this is in kern_openat() in the kernel but this > might cause compatibility issues. Not sure if there would be serious compatibility problems if open() would automatically restart instead of returning EINTR. It definitely seems a rather intrusive change though. I can not see major application breakage should open(3) be changed. That said, I am confused by jilles' comment: http://pubs.opengroup.org/onlinepubs/95399/functions/open.html open(3) is permitted to return EINTR. Actually, open(3) is _required_ to return EINTR (if a signal occurs). This hasn't changed since the old (2001) POSIX draft that I quoted in a more detailed reply. The wording is "shall fail...[with EINTR] if a signal was caught during open()". Only a perverse implementation of weaselnix would justify not returning EINTR by not catching signals. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
