From: Matt Mackall <mpm@selenic.com>
To: Thomas Tuttle <ttuttle@google.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] pagemap: Modify add_to_pagemap to use copy_to_user instead of put_user.
Date: Thu, 05 Jun 2008 11:20:10 -0500 [thread overview]
Message-ID: <1212682810.3953.180.camel@calx> (raw)
In-Reply-To: <4ca0a85e0806050901q52deba94r3056fdb0e7d46c8c@mail.gmail.com>
On Thu, 2008-06-05 at 12:01 -0400, Thomas Tuttle wrote:
> On Thu, Jun 5, 2008 at 11:57 AM, Matt Mackall <mpm@selenic.com> wrote:
> >
> > On Thu, 2008-06-05 at 11:04 -0400, Thomas Tuttle wrote:
> >> While fiddling with pagemap, I discovered a bug in add_to_pagemap.
> >> When it is copying an entry that is not at the end of the buffer, it
> >> uses put_user to copy a u64 into a char* buffer. The problem is that
> >> put_user determines how much to copy based on the size of the
> >> *destination*, not the source, so it only copied one byte. To fix
> >> this, I replaced the call to put_user with a call to copy_to_user, as
> >> is used when copying the last (possibly partial) PFN into the buffer.0
> >
> > This looks fine to me, so:
> >
> > Acked-by: Matt Mackall <mpm@selenic.com>
> >
> > But your 3/5 undoes this, right? So we should just take one or the other
> > route. While I like going the simplifying route, it's not very pretty
> > from the user interface point of view. But it does have plenty of
> > precedent in direct-I/O-like things.
>
> No, my 3/5 further keeps the use of copy_to_user instead of put_user,
> but eliminates entirely the code for partial reads. 3/5 depends on
> 1/5.
Hmm, I read this backwards the first time through then. Rather than
finding a small bug at the end of the buffer, you've found a REALLY BIG
WEAR-A-BROWN-PAPER-BAG-ON-MY-HEAD BUG.
Sigh. Some clever person (me?) probably removed a cast or changed a
pointer type somewhere along the way and didn't notice the fallout
because the MSBs still came through.
I'm pretty sure we want to do the put_user because it's faster. On a
64-bit system, it boils down to a simple assignment. If we commit
ourselves to the alignment thing, then we should probably just change
all the relevant pointers to u64, and then it will just do the right
thing.
ps: perhaps put_user can be made to compare the src and dst sizes at
compile time?
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2008-06-05 16:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 15:04 [PATCH 1/5] pagemap: Modify add_to_pagemap to use copy_to_user instead of put_user Thomas Tuttle
2008-06-05 15:57 ` Matt Mackall
2008-06-05 16:01 ` Thomas Tuttle
2008-06-05 16:20 ` Matt Mackall [this message]
2008-06-05 19:02 ` Andrew Morton
2008-06-05 19:06 ` Matt Mackall
2008-06-05 19:09 ` Thomas Tuttle
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=1212682810.3953.180.camel@calx \
--to=mpm@selenic.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ttuttle@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 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.