Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Daniel Phillips
Linus Torvalds wrote: > Ok, pre-5 should have all the same places you found already fixed, but > please do give it some heavy-duty testing to make sure there isn't > anything hidden.. I've beaten on it fairly heavily with the BUG in there as you suggested, with no problems. This kernel even

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Linus Torvalds
On Thu, 28 Dec 2000, Daniel Phillips wrote: > > OK, I see you just posted -pre5 while I was making the patch, but here > it is anyway, as a cross-check. Ok, pre-5 should have all the same places you found already fixed, but please do give it some heavy-duty testing to make sure there isn't

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Daniel Phillips
Linus Torvalds wrote: > We don't want to lose dirty bits by mistake. The only cases where it's ok > to clear the dirty bit is when we truncate a page completely (so it won't > be needed and obviously really shouldn't be written out) and when we've > lost the last user of a swap cache entry. > >

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Daniel Phillips
Linus Torvalds wrote: > No, I'd much rather have > > if (PageDirty(page)) BUG(); > > there, and then have the free_swap_cache code clear the dirty bit. > > We don't want to lose dirty bits by mistake. The only cases where it's ok > to clear the dirty bit is when we truncate a page

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Linus Torvalds
On Thu, 28 Dec 2000, Daniel Phillips wrote: > [in vmscan.c] > > Between line 573 and 594 the page can have 1 user and be unlocked, so it > > can be removed by invalidate_inode_pages, and the mapping will be > > cleared here: > >

[PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Daniel Phillips
[in vmscan.c] > Between line 573 and 594 the page can have 1 user and be unlocked, so it > can be removed by invalidate_inode_pages, and the mapping will be > cleared here: > http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v=v2.3#L98 This seems like the obvious thing to do: ---

[PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Daniel Phillips
[in vmscan.c] Between line 573 and 594 the page can have 1 user and be unlocked, so it can be removed by invalidate_inode_pages, and the mapping will be cleared here: http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v=v2.3#L98 This seems like the obvious thing to do: ---

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Linus Torvalds
On Thu, 28 Dec 2000, Daniel Phillips wrote: [in vmscan.c] Between line 573 and 594 the page can have 1 user and be unlocked, so it can be removed by invalidate_inode_pages, and the mapping will be cleared here:

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Daniel Phillips
Linus Torvalds wrote: No, I'd much rather have if (PageDirty(page)) BUG(); there, and then have the free_swap_cache code clear the dirty bit. We don't want to lose dirty bits by mistake. The only cases where it's ok to clear the dirty bit is when we truncate a page completely

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Daniel Phillips
Linus Torvalds wrote: We don't want to lose dirty bits by mistake. The only cases where it's ok to clear the dirty bit is when we truncate a page completely (so it won't be needed and obviously really shouldn't be written out) and when we've lost the last user of a swap cache entry. Any

Re: [PATCH] Re: innd mmap bug in 2.4.0-test12

2000-12-28 Thread Linus Torvalds
On Thu, 28 Dec 2000, Daniel Phillips wrote: OK, I see you just posted -pre5 while I was making the patch, but here it is anyway, as a cross-check. Ok, pre-5 should have all the same places you found already fixed, but please do give it some heavy-duty testing to make sure there isn't