From: Matt Mackall <mpm@selenic.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: San Mehat <san@google.com>,
linux-kernel@vger.kernel.org,
Brian Swetland <swetland@google.com>,
Dave Hansen <haveblue@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] proc: pagemap: Hold mmap_sem during page walk
Date: Wed, 31 Mar 2010 22:20:23 -0500 [thread overview]
Message-ID: <1270092024.3552.1054.camel@calx> (raw)
In-Reply-To: <alpine.LFD.2.00.1003311754110.3707@i5.linux-foundation.org>
On Wed, 2010-03-31 at 18:33 -0700, Linus Torvalds wrote:
>
> On Wed, 31 Mar 2010, Matt Mackall wrote:
> >
> > Linus, I must say your charm has really worn thin. I've just stuck a
> > post-it on my monitor saying "don't be Linus" to remind me not to be
> > rude to my contributors.
>
> You didn't actually answer the problem, though.
>
> I'm rude, because I think the code is buggy.
And what does that achieve? I've got plenty of other work I could be
doing where people are nice to me when asking me to fix bugs.
> I pointed out how, and why I
> think it's pretty fundamental. You quoted it, but you didn't answer it.
Yes, I was muddling the distinction between pinned in page cache and
pinned in the mm, and you've just now re-clarified it for me. So I'll
agree the current code is bogus.
> So Matt, please actually address the _bug_ I pointed out rather than talk
> about other things. And yes, getting rid of the vma accesses sounds like
> it would fix it best. If that means that it doesn't work for hugepages, so
> be it.
That'd actually take us back to where it was when it hit mainline, which
would make a lot of people unhappy. I wouldn't be one of them as there
thankfully aren't any huge pages in my world. But I'm convinced
put_user() must go. In which case, get_user_pages() stays, and I've got
to switch things to direct physical page access into that array.
Even if I fix that, I believe San's original bug can still be triggered
though, as all the new callers to find_vma are run outside of the
target's mm_sem. Fixing that should be reasonably straight-forward.
--
http://selenic.com : development and support for Mercurial and Linux
next prev parent reply other threads:[~2010-04-01 3:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 17:23 [PATCH] proc: pagemap: Hold mmap_sem during page walk San Mehat
2010-03-31 17:54 ` Linus Torvalds
2010-03-31 21:40 ` Matt Mackall
2010-04-01 1:33 ` Linus Torvalds
2010-04-01 2:10 ` KOSAKI Motohiro
2010-04-01 3:20 ` Matt Mackall [this message]
2010-04-01 4:27 ` Linus Torvalds
2010-04-01 5:54 ` KOSAKI Motohiro
2010-04-01 5:55 ` KAMEZAWA Hiroyuki
2010-04-01 6:05 ` KOSAKI Motohiro
2010-04-01 6:09 ` KAMEZAWA Hiroyuki
2010-04-01 6:34 ` KAMEZAWA Hiroyuki
2010-04-01 7:09 ` Matt Mackall
2010-04-01 7:21 ` KOSAKI Motohiro
2010-04-01 15:10 ` Linus Torvalds
2010-04-02 0:11 ` KAMEZAWA Hiroyuki
2010-04-02 14:30 ` Matt Mackall
2010-04-06 6:48 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1270092024.3552.1054.camel@calx \
--to=mpm@selenic.com \
--cc=akpm@linux-foundation.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=san@google.com \
--cc=swetland@google.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.