On Tue, 24 Oct 2000, Petr Vandrovec wrote:
> On 23 Oct 00 at 23:05, Alexander Viro wrote:
>
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
> > Unfortunately, clean test would take the
On 23 Oct 00 at 23:05, Alexander Viro wrote:
> Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> analysis had been done? Petr, can you reproduce the problem on -test7?
> Unfortunately, clean test would take the backport of ext2 changes
> (truncate-related, happened around
On 23 Oct 00 at 23:05, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the
On Tue, 24 Oct 2000, Petr Vandrovec wrote:
On 23 Oct 00 at 23:05, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Note that if there really are only 9 "nopage" routines, then it is a lot
> easier to just add the single "SetPageUptodate(page)" into those 9
> routines, and thus let the VM know of the race.
Works for me. And yes, the list of ->nopage instances
On Tue, 24 Oct 2000, Alexander Viro wrote:
>
> It's not the only problem, but I would feel _much_ safer if pagefault
> wouldn't rely on pagecache miss. Actually... Hey. Why don't we do the
> insertion into page tables _within_ ->nopage()?
NO!
We used to do this a LOONG time ago.
On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
>
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
>
> I don't think that is it - that code
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> analysis had been done? Petr, can you reproduce the problem on -test7?
I don't think that is it - that code looks very straightforward (and is
needed on some silly
Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the same time), but IIRC -test7 was
relatively
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Also, the fact that Petr didn't see anything trigger in nopage() makes me
> nervous again. Even if the problem happened during read-ahead, it should
> have gotten into the address space only through nopage. Maybe there is
> some vma that isn't added
On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> I'm starting to suspect that we leave this path as-is, and just fix the
> mapping case (and PageUptodate() can work there). That should also avoid
> the nasties.
..and even that looks like I'd have to do the quick-and-dirty case with
the race
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> With ClearPageDirty() kernel locked up (but no watchdog, so probably
> some livelock) during bootup after fsck /
Actually, it turns out that even with this issue fixed, there's the more
serious issue that the page _has_ to be removed from the
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> With ClearPageDirty() kernel locked up (but no watchdog, so probably
> some livelock) during bootup after fsck /.
Yeah, the way the truncate logic works right now truncate_whole_page() has
to remove the page from the inode list - otherwise
On 23 Oct 00 at 14:34, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> > On Mon, 23 Oct 2000, Linus Torvalds wrote:
> > >
> > > Nope, that just makes the race window smaller. We should check for i_size
> > > after we've gotten the page table lock and just before actually
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
> >
> > Nope, that just makes the race window smaller. We should check for i_size
> > after we've gotten the page table lock and just before actually entering
> > the page into the page tables. Otherwise
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Yes. With sleep(60) no oops occur (it takes ~45 secs to exit child).
> This signals to me: should not vmtruncate_list acquire mm->mmap_sem,
> if it modifies page tables?
No.
It should get the page_table lock, but that is sufficient for
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > That's fine, but I'm afraid that we'll need a bit more than that. A couple of
> > obvious ones:
> > * filemap_nopage() needs the second check for ->i_size. Upon exit.
>
> Nope, that just makes
On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> That's fine, but I'm afraid that we'll need a bit more than that. A couple of
> obvious ones:
> * filemap_nopage() needs the second check for ->i_size. Upon exit.
Nope, that just makes the race window smaller. We should check for i_size
On 23 Oct 00 at 13:57, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> > First page->mapping == NULL entry in syslog is dated 22:23:58, but
> > couple of entries was lost before (probably I should print only '.' for
> > each such page; this run there was more than 100 such
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> > On Mon, 23 Oct 2000, Linus Torvalds wrote:
> >
> > > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > > the race open, and make truncate_complete_page() just leave such a
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> Yes. Bad news. No problem was catched in filemap_nopage, but one
> (of 57000) pages was dirty and had page->mapping == NULL... (maybe
> only one was caused that this was just after bootup, with plenty of memory)
> Maybe I should look at readahead
On Mon, 23 Oct 2000, Alexander Viro wrote:
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > the race open, and make truncate_complete_page() just leave such a "racy"
> > page in the page cache. It will still race,
On 23 Oct 00 at 16:13, Alexander Viro wrote:
> On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
> > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > the race open, and make truncate_complete_page() just leave such a "racy"
> > page in the page cache. It will still race,
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Al, any ideas? I have this feeling that the simplest fix is just to leave
> the race open, and make truncate_complete_page() just leave such a "racy"
> page in the page cache. It will still race, and the invalid page will
> still exist, but the end
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
> > I'll take a better look at the truncate case (I consider the invalidate
> > case closed). Do you have a simple test-program around?
>
> Well, I cannot say simple. As I was not able to reproduce it with only
> one task, code below:
Ok, without
On 23 Oct 00 at 12:09, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Petr Vandrovec wrote:
> >
> > 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
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
>
> 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
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.
>
In article <[EMAIL PROTECTED]>,
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.
Anybody who uses file locking
In article [EMAIL PROTECTED],
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.
Anybody who uses file locking over NFS
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,
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
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
On 23 Oct 00 at 12:09, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
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
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
I'll take a better look at the truncate case (I consider the invalidate
case closed). Do you have a simple test-program around?
Well, I cannot say simple. As I was not able to reproduce it with only
one task, code below:
Ok, without running
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
page in the page cache. It will still race, and the invalid page will
still exist, but the end result
On 23 Oct 00 at 16:13, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
page in the page cache. It will still race, and the
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
page in the page cache. It will still race, and the
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
Yes. Bad news. No problem was catched in filemap_nopage, but one
(of 57000) pages was dirty and had page-mapping == NULL... (maybe
only one was caused that this was just after bootup, with plenty of memory)
Maybe I should look at readahead code?
On Mon, 23 Oct 2000, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Al, any ideas? I have this feeling that the simplest fix is just to leave
the race open, and make truncate_complete_page() just leave such a "racy"
On 23 Oct 00 at 13:57, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
First page-mapping == NULL entry in syslog is dated 22:23:58, but
couple of entries was lost before (probably I should print only '.' for
each such page; this run there was more than 100 such pages)
On Mon, 23 Oct 2000, Alexander Viro wrote:
That's fine, but I'm afraid that we'll need a bit more than that. A couple of
obvious ones:
* filemap_nopage() needs the second check for -i_size. Upon exit.
Nope, that just makes the race window smaller. We should check for i_size
after
On Mon, 23 Oct 2000, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
That's fine, but I'm afraid that we'll need a bit more than that. A couple of
obvious ones:
* filemap_nopage() needs the second check for -i_size. Upon exit.
Nope, that just makes the race
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
Yes. With sleep(60) no oops occur (it takes ~45 secs to exit child).
This signals to me: should not vmtruncate_list acquire mm-mmap_sem,
if it modifies page tables?
No.
It should get the page_table lock, but that is sufficient for anybody who
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Nope, that just makes the race window smaller. We should check for i_size
after we've gotten the page table lock and just before actually entering
the page into the page tables. Otherwise we'll
On 23 Oct 00 at 14:34, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Nope, that just makes the race window smaller. We should check for i_size
after we've gotten the page table lock and just before actually entering
the
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
With ClearPageDirty() kernel locked up (but no watchdog, so probably
some livelock) during bootup after fsck /.
Yeah, the way the truncate logic works right now truncate_whole_page() has
to remove the page from the inode list - otherwise truncate
On Mon, 23 Oct 2000, Petr Vandrovec wrote:
With ClearPageDirty() kernel locked up (but no watchdog, so probably
some livelock) during bootup after fsck /
Actually, it turns out that even with this issue fixed, there's the more
serious issue that the page _has_ to be removed from the page
On Mon, 23 Oct 2000, Linus Torvalds wrote:
I'm starting to suspect that we leave this path as-is, and just fix the
mapping case (and PageUptodate() can work there). That should also avoid
the nasties.
..and even that looks like I'd have to do the quick-and-dirty case with
the race still
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Also, the fact that Petr didn't see anything trigger in nopage() makes me
nervous again. Even if the problem happened during read-ahead, it should
have gotten into the address space only through nopage. Maybe there is
some vma that isn't added to
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the same time), but IIRC -test7 was
relatively
On Mon, 23 Oct 2000, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
I don't think that is it - that code looks very straightforward (and is
needed on some silly architectures
On Mon, 23 Oct 2000, Linus Torvalds wrote:
On Mon, 23 Oct 2000, Alexander Viro wrote:
Oh, crap... Who introduced -i_mmap_shared/-i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
I don't think that is it - that code looks very
On Tue, 24 Oct 2000, Alexander Viro wrote:
It's not the only problem, but I would feel _much_ safer if pagefault
wouldn't rely on pagecache miss. Actually... Hey. Why don't we do the
insertion into page tables _within_ -nopage()?
NO!
We used to do this a LOONG time ago.
Distributing the
On Mon, 23 Oct 2000, Linus Torvalds wrote:
Note that if there really are only 9 "nopage" routines, then it is a lot
easier to just add the single "SetPageUptodate(page)" into those 9
routines, and thus let the VM know of the race.
Works for me. And yes, the list of -nopage instances that
On Thu, 19 Oct 2000, Linus Torvalds wrote:
> You'd have to do something like
>
> LockPage(page); /* Nobody gets to write to this page (except
>through mmaps, ugh) */
> gather_all_mmap_users(page);/* THIS is the nasty one */
Wait a second.
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> Again, consider the case when two processes share the
> mapping. Process A has page faulted in. Page is
> invalidated. Process B tries to access the same page. If you
> leave it in page tables of A you _MUST_ leave it
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> For the general case of the page cache I think we can keep them quite
> simple:
>
> + We do in any case want to drop all pages that are unreferenced. (The
> reason for flushing may be that the file size has changed.)
>
> + For pages that are
On 20 Oct 2000, Trond Myklebust wrote:
> > " " == Russell King <[EMAIL PROTECTED]> writes:
>
> > invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
> > do_fcntl sys_fcntl
>
> > So I guess that NFS locking is really bad if the region is
> > mmapped!
>
> Yep,
On 20 Oct 2000, Trond Myklebust wrote:
> Under NFS the problem is that pages can (and *should*) be invalidated
> despite there being pending write backs. The server can trigger the
> need for a cache invalidation at any time.
OK, so what should happen if user does mmap() on NFS file, dirties
On Fri, 20 Oct 2000, Roger Larsson wrote:
> Is it legal/good practice to unmap the file after closing it?
Yes.
> (Since the sharing needs the fd to mmap it)
It doesn't. Mapping needs struct file * and it doesn't care about
fd. mmap() takes a reference to struct file by fd you've passed and
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> > " " == David S Miller <[EMAIL PROTECTED]> writes:
>
> > Actually, judging by the trace you provided Russell, I'd say
> > this is some peculiarity with NFS silly rename handling, and
> > it'd be best to look for the bug in that
[ Final comment, and then I'll shut up ]
On Thu, 19 Oct 2000, Linus Torvalds wrote:
>
> You'd have to do something like
>
> LockPage(page); /* Nobody gets to write to this page (except
>through mmaps, ugh) */
> gather_all_mmap_users(page);/* THIS is the nasty
On Thu, 19 Oct 2000, Linus Torvalds wrote:
>
> I'm saying that we're much much better off guaranteeing local consistency
> over knowingly breaking local consistency over a uncertain global
> consistency issue. Especially as NFS has never guaranteed global
> consistency in the first place, and
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> which is really really bad, because now you have the case that
> you have 'n' copies of the same page in memory, with 'n' users,
> out of which 'n-1' users have the wrong page. And those 'n-1'
> users don't even have
On 20 Oct 2000, Trond Myklebust wrote:
>
> The problem here is that NFS pages have 3 rather than 2 states:
> 1) mmapped & correct.
> 2) mmapped & incorrect. (but possibly dirty)
> 3) Unmapped
>
> For case 1), we clearly want to have the page in inode->i_mapping.
> For cases 2) & 3) we
On 20 Oct 2000, Trond Myklebust wrote:
>
> Under NFS the problem is that pages can (and *should*) be invalidated
> despite there being pending write backs. The server can trigger the
> need for a cache invalidation at any time.
> The existence of file locks that aren't page aligned, as well as
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> The advantage of clearing the uptodate flag (as opposed to
> doing what we do now - dropping the page altogether) is that
> there would be no cache aliasing issues, and there would be no
> issues with a page and its
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> Btw, that "invalidate_inode_pages()" thing is just wrong - we
> can't just remove pages that are mapped etc, because that would
> result in no end of fun aliasing problems etc.
> How about adding a test in
Alexander Viro writes:
> Trond, I'm not asking about implementation - the question being what
> semantics do you want for nfs_zap_caches() wrt user-mapped pages.
Ok, looking through sendmail, and then db2, the situation is
created by the db2 library. If the process does the following:
1.
On 19 Oct 00 at 16:32, Linus Torvalds wrote:
> How about adding a test in invalidate_inode_pages() like
>
> /* We cannot invalidate a locked page */
> if (TryLockPage(page))
> continue;
>
> + /* We cannot invalidate a page that is in use */
> + if
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> So what exactly do you want it to do when page is mapped by
> user process? Should it remain visible or not? What should
> happen if process writes to that page?
> Trond, I'm not asking about implementation - the
On Fri, 20 Oct 2000, Trond Myklebust wrote:
>
> The problem lies with writes that haven't yet been msync()ed (and
> hence do not have writebacks). For shared mappings, one should perhaps
> schedule an automatic msync() of the dirty pages (???). For private
> mappings, perhaps the best thing
On Fri, 20 Oct 2000, Trond Myklebust wrote:
The problem lies with writes that haven't yet been msync()ed (and
hence do not have writebacks). For shared mappings, one should perhaps
schedule an automatic msync() of the dirty pages (???). For private
mappings, perhaps the best thing would
" " == Alexander Viro [EMAIL PROTECTED] writes:
So what exactly do you want it to do when page is mapped by
user process? Should it remain visible or not? What should
happen if process writes to that page?
Trond, I'm not asking about implementation - the question being
On 19 Oct 00 at 16:32, Linus Torvalds wrote:
How about adding a test in invalidate_inode_pages() like
/* We cannot invalidate a locked page */
if (TryLockPage(page))
continue;
+ /* We cannot invalidate a page that is in use */
+ if
Alexander Viro writes:
Trond, I'm not asking about implementation - the question being what
semantics do you want for nfs_zap_caches() wrt user-mapped pages.
Ok, looking through sendmail, and then db2, the situation is
created by the db2 library. If the process does the following:
1. creates
" " == Linus Torvalds [EMAIL PROTECTED] writes:
Btw, that "invalidate_inode_pages()" thing is just wrong - we
can't just remove pages that are mapped etc, because that would
result in no end of fun aliasing problems etc.
snip
How about adding a test in
On 20 Oct 2000, Trond Myklebust wrote:
Under NFS the problem is that pages can (and *should*) be invalidated
despite there being pending write backs. The server can trigger the
need for a cache invalidation at any time.
The existence of file locks that aren't page aligned, as well as
On 20 Oct 2000, Trond Myklebust wrote:
The problem here is that NFS pages have 3 rather than 2 states:
1) mmapped correct.
2) mmapped incorrect. (but possibly dirty)
3) Unmapped
For case 1), we clearly want to have the page in inode-i_mapping.
For cases 2) 3) we don't.
I
[ Final comment, and then I'll shut up ]
On Thu, 19 Oct 2000, Linus Torvalds wrote:
You'd have to do something like
LockPage(page); /* Nobody gets to write to this page (except
through mmaps, ugh) */
gather_all_mmap_users(page);/* THIS is the nasty one */
" " == Linus Torvalds [EMAIL PROTECTED] writes:
which is really really bad, because now you have the case that
you have 'n' copies of the same page in memory, with 'n' users,
out of which 'n-1' users have the wrong page. And those 'n-1'
users don't even have any way of
On 20 Oct 2000, Trond Myklebust wrote:
Under NFS the problem is that pages can (and *should*) be invalidated
despite there being pending write backs. The server can trigger the
need for a cache invalidation at any time.
OK, so what should happen if user does mmap() on NFS file, dirties the
On Fri, 20 Oct 2000, Roger Larsson wrote:
Is it legal/good practice to unmap the file after closing it?
Yes.
(Since the sharing needs the fd to mmap it)
It doesn't. Mapping needs struct file * and it doesn't care about
fd. mmap() takes a reference to struct file by fd you've passed and
On 20 Oct 2000, Trond Myklebust wrote:
" " == Russell King [EMAIL PROTECTED] writes:
invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
do_fcntl sys_fcntl
So I guess that NFS locking is really bad if the region is
mmapped!
Yep, but that's a symptom,
On Fri, 20 Oct 2000, Trond Myklebust wrote:
For the general case of the page cache I think we can keep them quite
simple:
+ We do in any case want to drop all pages that are unreferenced. (The
reason for flushing may be that the file size has changed.)
+ For pages that are referenced
" " == Alexander Viro [EMAIL PROTECTED] writes:
Again, consider the case when two processes share the
mapping. Process A has page faulted in. Page is
invalidated. Process B tries to access the same page. If you
leave it in page tables of A you _MUST_ leave it in
On Thu, 19 Oct 2000, Linus Torvalds wrote:
You'd have to do something like
LockPage(page); /* Nobody gets to write to this page (except
through mmaps, ugh) */
gather_all_mmap_users(page);/* THIS is the nasty one */
Wait a second. invalidate_inode_pages()
On Fri, 20 Oct 2000, Trond Myklebust wrote:
" " == David S Miller [EMAIL PROTECTED] writes:
Actually, judging by the trace you provided Russell, I'd say
this is some peculiarity with NFS silly rename handling, and
it'd be best to look for the bug in that code (early
> " " == Linus Torvalds <[EMAIL PROTECTED]> writes:
> How about adding a test in invalidate_inode_pages() like
> /* We cannot invalidate a locked page */ if
> (TryLockPage(page))
> continue;
> + /* We cannot invalidate a page that
> " " == Russell King <[EMAIL PROTECTED]> writes:
> invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
> do_fcntl sys_fcntl
> So I guess that NFS locking is really bad if the region is
> mmapped!
Yep, but that's a symptom, not a cause. We want to be able to run
> " " == Russell King <[EMAIL PROTECTED]> writes:
> Indeed. page->mapping is set to NULL in two places, one in
> __remove_inode_pages() and the other one in the swap code after
> we've checked that it was NULL. I hadn't found the particular
> call trace that caused us
> " " == David S Miller <[EMAIL PROTECTED]> writes:
> Actually, judging by the trace you provided Russell, I'd say
> this is some peculiarity with NFS silly rename handling, and
> it'd be best to look for the bug in that code (early inode
> reference loss, for example?)
Linus Torvalds writes:
> Can you get a full stack trace?
filemap_write_page
filemap_sync
filemap_unmap
do_munmap
sys_munmap
> How about adding a test in invalidate_inode_pages() like
(Added, along with a call to drop a stack trace out).
Yes, this does stop the problem in filemap_write_page.
In article <8snvuj$1l0$[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>Hmm.. Looks like page->mapping was cleared by truncate_inode_pages()
>when the inode was free'd, and there was still write-back activity on
>one of the pages in question.
Looking some more, the fact that the
In article <[EMAIL PROTECTED]>,
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>> " " == Petr Vandrovec <[EMAIL PROTECTED]> writes:
>
> > You do not have to use NFS - look for my postings with
> > 'page->mapping == NULL' in archive. Your code uses shared mmap,
> > 'page->isn't
>
In article <[EMAIL PROTECTED]>,
Russell King <[EMAIL PROTECTED]> wrote:
>Petr Vandrovec writes:
>> ... or from sys_exit() if you forget to unmap. Or from anywhere if
>> swapping code decides to swap such page. I'm trying to hunt it down
>> for more than month, but I have no idea what's wrong. In
From: Russell King <[EMAIL PROTECTED]>
Date:Fri, 20 Oct 2000 00:07:55 +0100 (BST)
Trond Myklebust writes:
> It's probably particularly nasty under NFS because of
> invalidate_inode_pages(). The latter empties the page cache whenever
> we can no longer trust it and calls
Trond Myklebust writes:
> It's probably particularly nasty under NFS because of
> invalidate_inode_pages(). The latter empties the page cache whenever
> we can no longer trust it and calls remove_inode_page() on every
> unlocked page. It won't care whether the page is mmapped or not.
>
> My
> " " == Petr Vandrovec <[EMAIL PROTECTED]> writes:
> You do not have to use NFS - look for my postings with
> 'page->mapping == NULL' in archive. Your code uses shared mmap,
> 'page->isn't
> it? Probably shared by couple of processes.
It's probably particularly nasty
Roger Larsson writes:
> Will it work correctly if 4. is done before 3. (even before 2?)
> Is it legal/good practice to unmap the file after closing it?
> (Since the sharing needs the fd to mmap it)
Dunno, haven't tried that yet. I'll have a go tomorrow, but I think
it'll work correctly. I'll
1 - 100 of 118 matches
Mail list logo
