Messages in this thread |  | | From | "Petr Vandrovec" <> | Date | Mon, 23 Oct 2000 19:44:05 MET-1 | Subject | Re: 2.4.0-test10-pre3:Oops in mm/filemap.c:filemap_write_pa |
| |
On 23 Oct 00 at 10:33, Linus Torvalds wrote: > Trond Myklebust <trond.myklebust@fys.uio.no> wrote: > > > >As for simply settling for a self-consistent mmap() rather than > >tackling the problem of rereading; the main crime is that you're > >rendering file locking unusable. ... > This is not a crime. > ... > And yes, I know that file locking can try to be nice in both of these > cases. I know that there are systems that try to revert shared mappings > etc upon file locking (or not allow file locking at all if mappings are > present). Linux is not one of them, and never has been. Neither are > most UNIXes out there. > Linus
Hi Linus, unfortunately, this does not explain problem I reported. In my case, underlying fs is ext2, and there is no locking around - only one task does ftruncate() on (big) shareable mapped file (original code does it to prevent dirty pages to be written to disk after their contents is no longer relevant). And for some reason, not all instance of shared mapping are invalidated - some are still connected to underyling pages, but these pages have page->mapping = NULL... (and no, in testcase there is no vmware around). So on task exit kernel dies with page->mapping dereference in filemap_write_page (->filemap_sync->filemap_unmap->exit_mmap-> ->mmput->do_exit)... Thanks, Petr Vandrovec vandrove@vc.cvut.cz
- 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/
|  |