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]

Message-Id: <200701091908.44576.MalteSch@gmx.de>
Date:	Tue, 9 Jan 2007 19:08:40 +0100
From:	Malte Schröder <MalteSch@....de>
To:	Linus Torvalds <torvalds@...l.org>
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 Tuesday 09 January 2007 18:58, Linus Torvalds wrote:
> On Tue, 9 Jan 2007, Adrian Bunk wrote:
> > Subject : BUG: at mm/truncate.c:60 cancel_dirty_page()  (reiserfs)
> > References : http://lkml.org/lkml/2007/1/7/117
> > Submitter : Malte Schröder <MalteSch@....de>
> > Status : unknown
>
> Adrian, this is also available as
>
> 	http://lkml.org/lkml/2007/1/5/308
>
> But, at worst, I don't think this is a show-stopper (oh, well: I actually
> liked it better when "WARN_ON()" said _warning_, not BUG, since it
> separates out the two cases visually much better, but others disagreed.
> Crud).

--8<--

> 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. 

>
> In general, a filesystem should never do a truncate at "release()" time
> _anyway_. It should do it at "drop_inode" time.
>
> So I think this does show some confusion in reiserfs, but it's not
> anything new. The only new thing is that the _message_ happens.
>
> So I don't personally consider this a regression. Just a sign of old and
> preexisting confusion that is now uncovered by new code (and it will print
> out the scary message at most four times, and then stop complaining about
> it. So apart from the scary message, nothing new and bad has really
> happened).

I also didn't reboot the machine afterwards and did not notice any problems 
beside that one message.

-- 
---------------------------------------
Malte Schröder
MalteSch@....de
ICQ# 68121508
---------------------------------------


Content of type "application/pgp-signature" skipped