On Sun, 14 Oct 2007, Erez Zadok wrote:... I don't disagree with your unionfs_writepages patch, Pekka, but I think it should be viewed as an optimization (don't waste time trying to write a group of pages when we know that nothing will be done) rather than as essential. Prior to unionfs's own use of AOP_WRITEPAGE_ACTIVATE, there have only been ramdisk and shmem generating it. ramdisk is careful only to return it in the wbc->for_reclaim case: I think (as in the patch I sent out before) shmem now ought to do so too for safety. Back in 2.4 days it was reasonable to assume that ->writepage would only get called from certain places, but things move faster nowadays, and the unionfs example shows others are liable to start ab/using it. I'll send Andrew that patch tomorrow (it's simple enough, but I'd like at least to try to reproduce the page_mapped bug first). Can it now? Current git has a patch from Andrew which bears a striking resemblance to that from Pekka, stopping the leak from write_cache_pages. Hugh -
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| James Bottomley | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| David Woodhouse | Re: [PATCH 2/3] firmware: convert korg1212 driver to use firmware loader exclusively |
| Kamalesh Babulal | Re: 2.6.24-rc8-mm1 Build Failure on S390x |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
