> > > This still does not address the situation where a file is 'permanently'You're right. In theory, at least. But in practice I don't think this matters. Show me an application that writes to a shared mapping then doesn't call either msync or munmap and doesn't even exit. If there were lot of these apps, then this bug would have been fixed lots of years earlier. In fact there are _very_ few apps writing to shared mappings at all. Applications should be encouraged to call msync(MS_ASYNC) because: - it's very fast (basically a no-op) on recent linux kernels - it's the only portable way to guarantee, that the data you written will _ever_ hit the disk. There's really no downside to using msync(MS_ASYNC) in your application, so making an effort to support applications that don't do this is stupid, IMO. Thanks, Miklos -
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |
| Junio C Hamano | Re: Rss produced by git is not valid xml? |
| Linux Kernel Mailing List | iSeries: fix section mismatch in iseries_veth |
| Linux Kernel Mailing List |
