[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130509202815.GH25399@ZenIV.linux.org.uk>
Date: Thu, 9 May 2013 21:28:15 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] more vfs.git stuff
On Thu, May 09, 2013 at 01:12:43PM -0700, Linus Torvalds wrote:
> On Thu, May 9, 2013 at 12:26 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> > Regression fix from Geert + yet another open-coded kernel_read().
>
> Hmm. I get one more commit - a racy usbmon thing.
Oops - pull stats not updated... My apologies.
> Which looks fine per
> se, but would look even better if it just made mmap_active an atomic_t
> instead, wouldn't you say?
The only place checking that sucker is in a fairly large area protected by
->b_lock (in mon_bin_event()); I really don't want to dig deep enough to
tell if having it changed right after it had been checked is safe. OTOH,
from a cursory look through that code it appears that the whole map_count
thing is completely misguided - it seems to assume that ->open() is called for
each VMA, including the one created by mmap(2). Sigh...
OK, it might make more sense to drop that last commit for now. It's obviously
more broken in mmap-related code than just a buggered locking for counter
and it probably doesn't make much sense to patch just that one. And I'll
have several more fixes of similar turds tomorrow, when mchehab finishes
testing videobuf ones. Up to you, really.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists