From: Linus Torvalds <torvalds@linux-foundation.org>
To: Matt Mackall <mpm@selenic.com>
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 21:27:18 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1003312118010.3707@i5.linux-foundation.org> (raw)
In-Reply-To: <1270092024.3552.1054.camel@calx>
On Wed, 31 Mar 2010, Matt Mackall wrote:
> >
> > 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 would suggest you go back and read my original email once more, now that
you realize that you had simply not understood the difference between
physical page pinning and virtual page pinning.
Seriously.
Now that you understand why I called the code buggy, maybe you realize
that calling the code "insane and misdesigned" is actually not overly
rude: it's just an accurate representation of the state of the code.
And if you read the mail once more, you'll also notice that every single
derogatory remark was about the _code_, not you.
Oh, and I did ask you for an explanation for why we shouldn't just remove
it. There can't be all that many users.
Because quite frankly, if you apparently want to keep the vma around, the
code is going to get way more complex and ugly. You may be able to avoid
some of the _worst_ crap if you require that user pointers have to always
be u64-aligned. Yes, that's a very ugly and non-intuitive requirement for
a read() interface, but probably better than the alternative.
Or maybe just do the double buffering, and limiting pagemap reads to
fairly small chunks at a time.
Linus
next prev parent reply other threads:[~2010-04-01 4:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 17:23 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
2010-04-01 4:27 ` Linus Torvalds [this message]
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=alpine.LFD.2.00.1003312118010.3707@i5.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=san@google.com \
--cc=swetland@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®