netdev - Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <562943C6.5020402@oracle.com>
Date:	Thu, 22 Oct 2015 21:15:02 +0100
From:	Alan Burlison <Alan.Burlison@...cle.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Casper.Dik@...cle.com, Eric Dumazet <eric.dumazet@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	netdev@...r.kernel.org, dholland-tech@...bsd.org
Subject: Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On 22/10/15 19:16, Al Viro wrote:

>> Don't you have to do that anyway, to do anything useful with the file?
>
> Dirtying the cacheline that contains struct file itself is different, but
> that's not per-descriptor.

Yes, true enough.

> Usually it's per-process, but any thread could ask for a private instance
> to work with (and then spawn more threads sharing that instance - or getting
> independent copies).

[snip]

Thanks again for the info, interesting. Solaris also does things along 
the same lines. In fact we recently extended posix_spawn so it could be 
used by the JVM to create subprocesses without wholescale copying, and 
Casper has done some optimisation work on posix_spawn as well.

>> I don't think that it's possible to claim that a non-atomic dup2()
>> is POSIX-compliant.
>
> Except that it's in non-normative part of dup2(2), AFAICS.  I certainly
> agree that it would be a standard lawyering beyond reason, but "not
> possible to claim" is too optimistic.  Maybe I'm just more cynical...

Possibly so, and possibly justifiably so as well ;-)

>> ThreadA remains sat in accept on fd1 which is now a plain file, not
>> a socket.
>
> No.  accept() is not an operation on file descriptors; it's an operation on
> file descriptions (pardon for use of that terminology).  They are specified
> by passing descriptors, but there's a hell of a difference between e.g.
> dup() or fcntl(,F_SETFD,) (operations on descriptors) and read() or lseek()
> (operations on descriptions).
>
> Lookups are done once per syscall; the only exception is F_SETFL{,W}, where
> we recheck that descriptor is refering to the same thing before granting
> the lock.

Yes, but if you believe that dup2() requires an implicit close() within 
it and that dup2() has to be atomic then expecting that other threads 
waiting on the same fd in accept() will get a notification seems 
reasonable enough.

> Again, POSIX is still underspecifying the semantics of shared descriptor
> tables; back when the bulk of it had been written there had been no way
> to have a descriptor -> description mapping changed under a syscall by
> action of another thread.  Hell, they still hadn't picked on some things
> that happened in early 80s, let alone early-to-mid 90s...

That's indisputably true - much of the POSIX behaviour predates threads 
and it shows, quite badly, in some places.

> Linux and Solaris happen to cover these gaps differently; FreeBSD and
> OpenBSD are probably closer to Linux variant, NetBSD - to Solaris one.

Yes, true enough.

-- 
Alan Burlison
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html