Re: VM: Fix nasty and subtle race in shared mmap'ed page writeback

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Jan 29, 2007 at 03:08:44PM +0100, Andrea Gelmini wrote:
> On Mon, Jan 22, 2007 at 10:10:39AM +0100, Peter Zijlstra wrote:
> > On Fri, 2007-01-12 at 01:39 +0100, Andrea Gelmini wrote:
> > > Hi,
> > > 	I can't do the test 'till next week.
> > > 
> > > Thanks a lot for your time,
> > > Gelma
> > 
> > Have you ever gotten around to testing this?
> 
> well, I spent some time doing more deeply test.
> DB corruption happens anyway, even with the kernel that seems to work
> (I say seems because it needs much more effort to get corruption).
> I'm trying to understand it.
> I will work more over it next week.

I'm a bit skeptical that bdb would really be the only thing able to
reproduce a longstanding MAP_SHARED corruption. bdb may be using mmap
a lot but there are tons of other apps using MAP_SHARED a lot too, so
while not impossible I rate it not very probable that a vm race is to
blame for bdb troubles.

bdb is quite a complex piece of code (I once almost fallen in the trap
of depending on it myself), and if you use threads you exercise even
more of its complexity (more than you probably should). So if you're
using threads, the first thing I'd be looking at would be locking bugs
in userland. Also make sure it's properly linked with NPTL at compile
time (compile it yourself if you have no other way to make sure), and
that the locking is working right. If really this is a kernel issue
with 2.6.18 and previous (just ignore the 2.6.19 release), perhaps we
should look at the futex instead of the dirty bits ;).

Not very helpful I know, but just sharing my feelings on the bdb
troubles mentioned here.