On 23 Oct 00 at 10:33, Linus Torvalds wrote:
> Trond Myklebust  <[EMAIL PROTECTED]> 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
                                            [EMAIL PROTECTED]
                                            
                        
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to