From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Masami Hiramatsu <mhiramat@redhat.com>,
Mel Gorman <mel@csn.ul.ie>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: [PATCH v1 4/10] User Space Breakpoint Assistance Layer
Date: Tue, 23 Mar 2010 16:56:15 +0530 [thread overview]
Message-ID: <20100323112615.GB16818@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100322214009.bb90d6e2.akpm@linux-foundation.org>
>
> > User Space Breakpoint Assistance Layer (USER_BKPT)
> >
>
> A quick scan, just to show I was paying attention ;)
Thanks for taking a look and commenting on the code.
>
> > +int user_bkpt_read_vm(struct task_struct *tsk, unsigned long vaddr,
> > + void *kbuf, int nbytes)
> > +{
> > + if (tsk == current) {
> > + int nleft = copy_from_user(kbuf, (void __user *) vaddr,
> > + nbytes);
> > + return nbytes - nleft;
> > + } else
> > + return access_process_vm(tsk, vaddr, kbuf, nbytes, 0);
> > +}
>
> copy_from_user() takes and returns an unsigned long arg but this
> function is converting these to and from ints. That's OK if we're 100%
> sure that we'll never get or return an arg >2G. Otherwise things could
> get ghastly. Please have a think. (Dittoes for some other functionss
> around here).
>
nbytes would not be greater than the maximum size of a instruction for
that architecture. Hence I dont see it going above 2G. However I will
take a relook.
I will rework the rest of the comments as suggested by you.
It would be part of the next version.
--
Thanks and Regards
Srikar
next prev parent reply other threads:[~2010-03-23 11:26 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-20 14:24 [PATCH v1 0/10] Uprobes patches Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 1/10] Move Macro W to insn.h Srikar Dronamraju
2010-03-20 15:50 ` Masami Hiramatsu
2010-03-22 6:24 ` Srikar Dronamraju
2010-03-22 14:11 ` Masami Hiramatsu
2010-03-20 14:25 ` [PATCH v1 2/10] Move replace_page() to mm/memory.c Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 3/10] Enhance replace_page() to support pagecache Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 4/10] User Space Breakpoint Assistance Layer Srikar Dronamraju
2010-03-23 1:40 ` Andrew Morton
2010-03-23 4:48 ` Randy Dunlap
2010-03-23 11:26 ` Srikar Dronamraju [this message]
2010-03-20 14:25 ` [PATCH v1 5/10] X86 details for user space breakpoint assistance Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 6/10] Slot allocation for Execution out of line Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 7/10] Uprobes Implementation Srikar Dronamraju
2010-03-23 11:01 ` Peter Zijlstra
2010-03-23 11:04 ` Peter Zijlstra
2010-03-23 12:23 ` Srikar Dronamraju
2010-03-23 13:46 ` Peter Zijlstra
2010-03-23 14:20 ` Masami Hiramatsu
2010-03-23 15:15 ` Peter Zijlstra
2010-03-23 17:36 ` Masami Hiramatsu
2010-03-24 10:22 ` Srikar Dronamraju
2010-03-23 15:05 ` Ananth N Mavinakayanahalli
2010-03-23 15:15 ` Peter Zijlstra
2010-03-23 15:26 ` Frank Ch. Eigler
2010-03-24 5:59 ` Ananth N Mavinakayanahalli
2010-03-24 7:58 ` Srikar Dronamraju
2010-03-24 13:00 ` Peter Zijlstra
2010-03-25 7:56 ` Srikar Dronamraju
2010-03-25 8:41 ` Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 8/10] X86 details for uprobes Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 9/10] Uprobes Documentation patch Srikar Dronamraju
2010-03-22 3:00 ` Randy Dunlap
2010-03-22 5:34 ` Srikar Dronamraju
2010-03-22 14:51 ` Randy Dunlap
2010-03-20 14:26 ` [PATCH v1 10/10] Uprobes samples Srikar Dronamraju
2010-03-23 1:38 ` [PATCH v1 0/10] Uprobes patches Andrew Morton
2010-03-23 10:55 ` Srikar Dronamraju
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=20100323112615.GB16818@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=randy.dunlap@oracle.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.