lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0701091022180.3594@woody.osdl.org>
Date:	Tue, 9 Jan 2007 10:30:43 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Malte Schröder <MalteSch@....de>
cc:	Adrian Bunk <bunk@...sta.de>, Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	reiserfs-dev@...esys.com
Subject: Re: 2.6.20-rc4: known unfixed regressions (v2)



On Tue, 9 Jan 2007, Malte Schröder wrote:
> 
> > So something interesting is definitely going on, but I don't know exactly
> > what it is. Why does reiserfs do the truncate as part of a close, if the
> > same inode is actually mapped somewhere else? And if it's a race with two
> > different CPU's (one doing a "munmap()" and the other doing a "close()",
> > then the unmap should _still_ have actually unmapped the pages before it
> > actually did _its_ "release()" call.
> 
> This was on a single core. But with CONFIG_PREEMPT_VOLUNTARY=y.
> It didn't happen again since then. 

Yeah, PREEMPT would be able to show most races like this too. In fact, 
some races show up much better with preemption than they do with real SMP.

But I haven't looked at what exactly reiserfs does. I did check that the 
VM layer definitely does the remove_vma() stuff (that actually closes the 
files) _after_ it has unmapped everything. It would have surprised me if 
we had had that kind of bug, but still..

		Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ