[lkml]   [2007]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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 :
> > Submitter : Malte Schröder <>
> > Status : unknown
> Adrian, this is also available as
> 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).


> 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
ICQ# 68121508

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2007-01-09 20:07    [W:0.098 / U:1.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site