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

From: Al Viro <[email-masked]>
Date: Thu, 22 Oct 2015 22:57:41 +0100

On Thu, Oct 22, 2015 at 09:51:05PM +0200, [email-masked] wrote:
> 
> >On Thu, Oct 22, 2015 at 08:24:51PM +0200, [email-masked] wrote:
> >
> >> The external behaviour atomic; you cannot distinguish the order
> >> between the closing of the original file (and waking up other threads
> >> waiting for a record lock) or changing the file referenced by that newfd.
> >> 
> >> But this not include a global or process specific lock.
> >
> >Interesting...  Do you mean that decriptor-to-file lookup blocks until that
> >rundown finishes?
> 
> For that particular file descriptor, yes.  (I'm assuming you mean the 
> Solaris kernel running down all lwps who have a system in progress on that 
> particular file descriptor).  All other fd to file lookups are not blocked 
> at all by this locking.
> 
> It should be clear that any such occurrences are application errors and 
> should be hardly ever seen in practice.  It is also known when this is 
> needed so it is hardly even attempted.

Ho-hum...  It could even be made lockless in fast path; the problems I see
are
	* descriptor-to-file lookup becomes unsafe in a lot of locking
conditions.  Sure, most of that happens on the entry to some syscall, with
very light locking environment, but... auditing every sodding ioctl that
might be doing such lookups is an interesting exercise, and then there are
->mount() instances doing the same thing.  And procfs accesses.  Probably
nothing impossible to deal with, but nothing pleasant either.
	* memory footprint.  In case of Linux on amd64 or sparc64,
main()
{
	int i;
	for (i = 0; i < 1<<24; dup2(0, i++))	// 16M descriptors
		;
}
will chew 132Mb of kernel data (16Mpointer + 32Mbit, assuming sufficient ulimit -n,
of course).  How much will Solaris eat on the same?
	* related to the above - how much cacheline sharing will that involve?
These per-descriptor use counts are bitch to pack, and giving each a cacheline
of its own...  <shudder>