Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: page->mapping == 0 | Date | Mon, 30 Oct 2000 02:57:26 +0100 |
| |
Linus Torvalds wrote: > Now, I don't think this is really a valid usage pattern, so it's most > likely to be a result of a buggy application, but I can imagine having > some strange kind of user-space VM memory management scheme that depends > on SIGBUS to maintain a file length. I've never heard of such a thing, but > I could imagine somebody doing some kind of persistent data object store > in user space this way. > > Does anybody actually know of an application that does something like > this? Because I'm more and more inclined to just going with the half-fix > for now. It would at least guarantee internal kernel data consistency (and > no oopses, of course). > > Don't get me wrong - we need to clean this part up, but as far as I can > tell we have never done this "right", so in that sense it's not a new > 2.4.x bug and it can't break existing applications.
Strace shows that the history really is updated with no locking:
4030 open("/home/phillips/.bash_history", O_WRONLY|O_TRUNC) = 4 4030 write(4, "l\nless README\ne ../*test8/fs/ext"..., 7546) = 7546 4030 close(4) = 0
There's no reason to continue doing the read after you've detected the page was pulled out from under you - clearly it's a user error state, the only question is: return the error and break the buggy application? Or gloss over it. And it seems like returning the error might actually break bash - maybe it deserves it... but...
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |