Messages in this thread | | | Date | Thu, 24 Jun 1999 15:00:25 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [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/
| |