[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0706092159110.20321@woody.linux-foundation.org>
Date: Sat, 9 Jun 2007 22:06:27 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: dean gaudet <dean@...tic.org>
cc: Al Viro <viro@....linux.org.uk>,
Kyle Moffett <mrmacman_g4@....com>,
Ulrich Drepper <drepper@...hat.com>,
Davide Libenzi <davidel@...ilserver.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Theodore Tso <tytso@....edu>,
Eric Dumazet <dada1@...mosbay.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Sat, 9 Jun 2007, dean gaudet wrote:
>
> for an example of a library wanting to cache an open fd ... and failing
> miserably at protecting itself from the application closing its fd read:
Heh.
Why the hell doesn't that thing just do an "fstat()" on the thing, and
compare the inode number? Not that I would guarantee that it works either
for a socket, but it would seem to make more sense than what it apparently
does now, and I think it should work at least on Linux.
(Ie linux will give fake "st_ino" numbers to sockets. Whether anybody else
will do that, I have no friggin clue. And you probably shouldn't depend on
it even under Linux, but damn, despite all of those issues, it's likely
better and more logical than what libnss-ldap apparently does now ;)
Doing a "fstat()" call is how you generally test if two fd's point to the
same file. Doing the same thing for sockets would at least be half-way
sane, and even if the OS doesn't give new sockets individual st_ino
numbers, they probably won't be *changing*.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists