Messages in this thread | | | From | Malte Schröder <> | Subject | Re: 2.6.20-rc4: known unfixed regressions (v2) | Date | Tue, 9 Jan 2007 19:08:40 +0100 |
| |
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 ---------------------------------------
[unhandled content-type:application/pgp-signature] | |