lkml.org 
[lkml]   [1999]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] struct file handlinhg in ->poll()


On Thu, 24 Jun 1999, Alexander Viro wrote:

> Linus, just a quick question: what is guaranteed about ->poll()
> behaviour? Specifically, can it block before calling poll_wait()? Can it
> block other than in poll_wait()?
> fcheck() usage in do_select() worries me - if ->poll() may block
> before incrementing f_count we have a race on hands right now. Even if it

Oops. We *do* have a race here. Scenario:
processes A and B share the files_struct.
process A calls sys_select() (which leads to do_select())
Big lock grabbed.
When wait table had grown to 4K we are looking at the next file.
Doing fcheck().
Calling file->poll().
Calling poll_wait() (i.e. __pollwait()).
Noticing that table is full.
Calling __get_free_page().
Sleeping.
Process B calls sys_close().
File in question is excluded from the files_struct.
f_count hits zero.
we block somewhere in __fput().
Process A wakes up.
And installs the pointer to the doomed struct file into the table.
Process A sleeps.
Process B wakes up and does its thing.
Process A now has a nice dangling pointer.

Notice that it doesn't require SMP at all - we can get into that mess on
UP box. I think that replacing fcheck() with fget() is the right thing
here. If you have no objections I'm including that into SMP-patch, OK?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.035 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site