Messages in this thread | | | Date | Sun, 30 May 1999 10:42:05 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 2.2.9 hangs in truncate_inode_pages |
| |
On Sun, 30 May 1999, Alan Cox wrote: > > > > 2. __wait_on_page says you are supposed to own the page before waiting > > > on it (ie up page->count). I don't see where we do that. We even > > > go back to the start to allow for the pages on the inode changing > > > if we sleep but we don't up the count ourselves. > > > > This may be the real offender - I think you found a real bug, and it looks > > extremely hard to trigger, but it looks like it has been there from the > > very first version. > > With 2.2.7 I've never seen it, with 2.2.9 and 2.2.9ac1 I see a hang every 24-36 > hours. Both my test boxes hung on the same thing.
IF it is this one, then it's going to be rather timing-sensitive. The only thing that could make a difference is that you have a page that was locked just as you were going to truncate it (an unlikely event in the first place, but hey, it could happen, especially with the page being busy for read-ahead from a previous read) AND that page happened to be freed by the page deamon while you were waiting and re-used for something else.
Hmm... Thinking about it, even that should not have caused undue headache: you would have been woken up because it must have been unlocked at some point, and even if you're now going to look at the wrong page you should still be ok (because even if the page was re-allocated for something else, PG_locked would still be honoured as a bit, and the wait-queues would survive the switch).
So it's still something worth testing, but as far as I can see the bug shouldn't actually ever have resulted in anything bad.
Oh, and don't use "atomic_dec()" like I said in the previous mail: that would result in a memory leak if the bad timing ever triggers. You should obviously use "page_cache_release(page)", in order to actually free the page if the count has gone down to zero when it gets decremented.
Linus
- 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/
| |