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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 13:48:58 EDT