All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xishi Qiu <qiuxishi@huawei.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: <benh@kernel.crashing.org>, <rob@landley.net>,
	<ananth@in.ibm.com>, <anil.s.keshavamurthy@intel.com>,
	<davem@davemloft.net>, <masami.hiramatsu.pt@hitachi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	<linux-doc@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] doc: fix some typos
Date: Mon, 16 Sep 2013 09:42:02 +0800	[thread overview]
Message-ID: <523661EA.9040500@huawei.com> (raw)
In-Reply-To: <5234938E.7010809@infradead.org>

On 2013/9/15 0:49, Randy Dunlap wrote:

> On 09/13/13 20:49, Xishi Qiu wrote:
> 
>> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
>> index 0cfb00f..ca278d5 100644
>> --- a/Documentation/kprobes.txt
>> +++ b/Documentation/kprobes.txt
>> @@ -92,7 +92,7 @@ stack contents as the probed function.  When it is done, the handler
>>  calls jprobe_return(), which traps again to restore the original stack
>>  contents and processor state and switch to the probed function.
>>  
>> -By convention, the callee owns its arguments, so gcc may produce code
> 
> Are you sure about that?
> It looks correct to me (before the patch).
>

Hi Randy, you are right, I confused caller and callee.

Thanks,
Xishi Qiu

>> +By convention, the caller owns its arguments, so gcc may produce code
>>  that unexpectedly modifies that portion of the stack.  This is why
>>  Kprobes saves a copy of the stack and restores it after the jprobe
>>  handler has run.  Up to MAX_STACK_SIZE bytes are copied -- e.g.,
>>
> 
> 




  reply	other threads:[~2013-09-16  1:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-14  3:49 [PATCH] doc: fix some typos Xishi Qiu
2013-09-14 16:49 ` Randy Dunlap
2013-09-16  1:42   ` Xishi Qiu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-09-01 11:02 Juergen Gross
2016-09-02  8:30 ` Wei Liu
2016-09-02  8:57   ` Wei Liu
2020-06-16 21:03 Luc Van Oostenryck
2021-01-02 17:40 Thomas Ackermann via GitGitGadget
2021-01-02 21:53 ` Martin Ågren
2021-01-02 22:26   ` Felipe Contreras
2021-01-02 22:59     ` Martin Ågren
2021-01-02 23:40       ` Felipe Contreras
2021-01-03 14:50     ` Chris Torek
2022-09-28  2:35 [PATCH] doc:fix " dominic_riscx
2022-09-28  9:04 ` Andrew Jones
2022-09-28 15:51 ` Xiang W
2022-10-13  4:01 ` Anup Patel

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=523661EA.9040500@huawei.com \
    --to=qiuxishi@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=rdunlap@infradead.org \
    --cc=rob@landley.net \
    /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.