>And no, I'm not fond of such irregular ways to pass file descriptors, but
>we can't kill ioctl(2) with all weirdness hiding behind it, more's the pity...
Yeah, there are a number of calls which supposed work on one but have a
second argument which is also a file descriptor; mostly part of ioct
>Yet another POSIX deficiency.
>
>When a server deals with 10,000,000+ socks, we absolutely do not care of
>this requirement.
>
>O(log(n)) is still crazy if it involves O(log(n)) cache misses.
You miss the fire point of the algorithm; you *always* find an available
file descriptor in O(log(N))
>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
From: Al Viro
>On Thu, Oct 22, 2015 at 06:39:34PM +0100, Alan Burlison wrote:
>> On 22/10/2015 18:05, Al Viro wrote:
>>
>> >Oh, for... Right in this thread an example of complete BS has been quoted
>> >from POSIX close(2). The part about closing a file when the last descriptor
>> >gets closed
>On Thu, Oct 22, 2015 at 08:24:51PM +0200, casper@oracle.com 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.
>>
>>
>On Thu, Oct 22, 2015 at 08:34:19AM +0200, casper@oracle.com wrote:
>>
>>
>> >And I'm really curious about the things Solaris would do with dup2() there.
>> >Does it take into account the possibility of new accept() coming just as
>> >dup2() is trying to terminate the ongoing ones? Is there
From: Al Viro
>Except that in this case "correctness" is the matter of rather obscure and
>ill-documented areas in POSIX. Don't get me wrong - this semantics isn't
>inherently bad, but it's nowhere near being an absolute requirement.
It would more fruitful to have such a discussion in one of t
>And I'm really curious about the things Solaris would do with dup2() there.
>Does it take into account the possibility of new accept() coming just as
>dup2() is trying to terminate the ongoing ones? Is there a window when
>descriptor-to-file lookups would fail? Looks like a race/deadlock count
>It's been said that the current mechanisms in Linux & some BSD variants
>can be subject to races, and the behaviour exhibited doesn't conform to
>POSIX, for example requiring the use of shutdown() on unconnected
>sockets because close() doesn't kick off other threads accept()ing on
>the same
>On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote:
>
>> >There's going to be a notion of "last close"; that's what this refcount is
>> >about and _that_ is more than implementation detail.
>>
>> Yes, POSIX distinguishes between "file descriptor" and "file
>> description" (ugh!) and t
From: David Miller
Date: Wed, 21 Oct 2015 08:30:08 -0700 (PDT) (17:30 CEST)
>From: Alan Burlison
>Date: Wed, 21 Oct 2015 15:38:51 +0100
>
>> While this algorithm is pretty expensive, it is not often invoked.
>
>I bet it can be easily intentionally invoked, by a malicious entity no
>less.
It is
11 matches
Mail list logo
