On 11.05.2006 [17:04:46 -0400], linux-os (Dick Johnson) wrote:
>
> On Thu, 11 May 2006, Nishanth Aravamudan wrote:
>
> > On 11.05.2006 [10:25:29 -0400], linux-os (Dick Johnson) wrote:
> >>
> >>
> >> Hello,
> >>
> >> I'm trying to fix a long-standing bug which has a
> >> work-around that has been working for a year or
> >> so.
> >
> > <snip valiant efforts>
> >
> >> Here is relevent code:
> >>
> >> for(;;) {
> >> mem->pfd.fd = fd;
> >> mem->pfd.events = POLLIN|POLLERR|POLLHUP|POLLNVAL;
> >> mem->pfd.revents = 0x00;
> >
> > Hrm, in looking at the craziness that is sys_poll() for a bit, I think
> > it's the underlying f_ops that are responsible for not setting POLLHUP,
> > that is:
> >
> > if (file != NULL) {
> > mask = DEFAULT_POLLMASK;
> > if (file->f_op && file->f_op->poll)
> > mask = file->f_op->poll(file, *pwait);
> > mask &= fdp->events | POLLERR | POLLHUP;
> > fput_light(file, fput_needed);
> > }
> >
> > and file->f_op->poll(file, *pwait) is not setting POLLHUP on the
> > disconnect. What filesystem is this?
>
> I think that's the problem. A socket isn't a file-system and the
> code won't set either bits if it isn't. Perhaps, the kernel code
> needs to consider a socket as a virtual file of some kind? Surely
> one needs to use poll() on sockets, no?
Duh, I'm not reading well today -- for sockets, we do
file->f_op->poll() -> (socket_file_ops) sock_poll() -> sock->ops->poll()
So, now I need to know what kind of socket is this to go from there ...
Thanks,
Nish
--
Nishanth Aravamudan <[email protected]>
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
