[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFydsXqRg-QwfVBuUOSfpGQ24MjgWaK-z+3Qvgn-BHn6Tw@mail.gmail.com>
Date: Thu, 29 Dec 2011 17:26:56 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Darren Hart <dvhltc@...ibm.com>
Subject: Re: [GIT PULL] futex fixlet
On Thu, Dec 29, 2011 at 1:07 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
> Please pull the latest core-urgent-for-linus git tree from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-urgent-for-linus
>
> Please have a good look at it - it was probably not tested
> by everyone with the usual vigor, due to holiday excesse^W
> festivities.
Ugh.
It's not about the testing, that thing is disgusting, and I really dislike it.
Why do we even bother to check "page->mapping" at all? What's the
*use* of that loop? My gut feeling is that *that* is the fundamental
problem, and we should just get rid of it, rather than add all these
totally random work-arounds for the problem.
Peter Z? That "if (!page->mapping) goto again" actually goes back to
38d47c1b7075, in 2008. Why does it exist in the first place? There's
no comment nor explanation in the changelog.
Why don't we just unconditionally return -EFAULT? What is the retry
actually supposed to *do*? If somebody races with a mmap/munmap, why
the hell would we care? What is it doing?
So there's no way I'll pull that patch. Even if the patch is
technically correct, what it *really* needs is the comment about why
retrying would be needed and a good idea in the first place. The
comments about all the cases where retrying cannot work are completely
pointless without that much more important commentary.
I really don't understand what race we could be fixing by retrying,
and why we should care about that race.
Linus
--
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