On Mon, 07 Jan 2008 20:54:19 +0300 Anton Salikhmetov <salikhmetov@gmail.com> wrote:As long as the ctime and mtime stamps change when the memory is written to, what exactly is the problem? Is it that the ctime and mtime does not change again when the memory is written to again? Is there a way for backup programs to miss file modification times? Could you explain (using short words and simple sentences) what the exact problem is? Eg. 1) program mmaps file 2) program writes to mmaped area 3) ??? <=== this part, in equally simple words :) 4) data loss An explanation like that will help people understand exactly what the bug is, and why the patch should be applied ASAP. Due to the various cleanups all being in one file, it took me a while to understand the patch. In an area of code this subtle, it may be better to submit the cleanups in (a) separate patch(es) from the patch that adds the call to file_update_time(). I wonder if calling file_update_time() from inside the loop is the best idea. Why not call that function just once, after msync breaks from the loop? thanks, Rik -- All Rights Reversed --
| Lennart Sorensen | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Dmitry Torokhov | Re: 2.6.21-rc5-mm3 |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
