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

["Malte Schröder" <MalteSch@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

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@gmx.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@gmx.de
ICQ# 68121508
---------------------------------------


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]