Hello!
> Did I miss some way that multiple file objects can point to the
> same socket inode?
Absolutely prohibited. Always was.
Apparently, sock_fasync() was cloned from tty_fasync(), that's the only
reason why it is so creepy.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2006 03:15:16 -0700 (PDT)
> If my analysis is correct we can incredibly simplify sock_fasync().
I've also found more bugs in sock_fasync(), it's a real can of worms
:-)
It deviates from the return value policies used by othe
file_ops->fasy
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2006 14:28:20 +0400
> On Fri, Aug 11, 2006 at 03:15:16AM -0700, David Miller ([EMAIL PROTECTED])
> wrote:
> > Did I miss some way that multiple file objects can point to the
> > same socket inode?
>
> What about dup and pipe?
Dup make
On Fri, Aug 11, 2006 at 03:15:16AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> Did I miss some way that multiple file objects can point to the
> same socket inode?
What about dup and pipe?
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
I was studying sock_fasync() and it definitely has a bunch
of questionable issues.
Well firstly, it duplicates fasync_helper() entirely.
The only difference is that sock_fasync() does socket
local locking which is better for performance. fasync_helper()
uses a global spinlock to protect the fasy
