Messages in this thread | | | Date | Wed, 23 Oct 2013 09:43:39 -0400 | From | Peter Hurley <> | Subject | Re: epoll oops. |
| |
On 10/14/2013 04:57 PM, Linus Torvalds wrote: > [ Adding Pekka to verify the SLAB_DESTROY_BY_RCU semantics, and Peter > Hurley due to the possible tty association ]
> And I see a few worrisome cases. For example, look at "tty_poll()". It > ends up doing something very similar, except it uses the tty instead > of sighand. And exactly like the sighand struct, the tty allocation > lifespan can - thanks to hangup() - be shorter than the file > allocation lifespan. > > Peter? Does a tty hangup end up actually possibly freeing the tty > struct? Looking at it, I'm starting to think that it only affects > f_op, and the "struct tty" stays around, in which case this is all > fine.
The tty_struct is only freed at the completion of the tty's file_operations .release method (tty_release()). Further, it should not be possible to advance past the tty_ldisc_release() call in tty_release() while file operations such as tty_poll() -> poll_wait() or a tty hangup are in-progress.
[Notwithstanding the above, if some kernel driver failed to acquire a tty reference, either directly or via tty_port_tty_hangup(), before hanging up, then the hangup could be racing with the .release(). But I don't think that's what's happening here.]
On 10/15/2013 11:48 AM, Oleg Nesterov wrote:>> Hmm? There might be other cases.. > > Yes. > > Dave, perhaps you have vmcore? I have no idea if this is possible or > not, but perhaps you can look at eventpoll_release_file's frame and > print file->f_op ?
I think Oleg's suggestion is the next diagnostic step.
Regards, Peter Hurley
| |