linux-kernel - Re: 2.6.20-rc4: known unfixed regressions (v2)

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]

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