From: Namhyung Kim <namhyung@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
dm-devel@redhat.com
Subject: Re: [PATCH] block: add missing block_bio_complete() tracepoint
Date: Wed, 01 Feb 2012 11:18:33 +0900 [thread overview]
Message-ID: <4F28A0F9.9070603@gmail.com> (raw)
In-Reply-To: <CAOS58YP1F6_yBxRArcP4oyzAJVArLJB-ckjdXU35U1SNwi75XQ@mail.gmail.com>
Hi,
2012-01-31 7:39 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 30, 2012 at 10:30 PM, Namhyung Kim<namhyung@gmail.com> wrote:
>> Right, but the point is it could make a NULL pointer dereference during
>> evaluation of the argument of the TP AFAICS. I'm not sure about the TP
>> implementation though, I think I was wrong - T_E_C() cannot protect us from
>> it because it happens just before jumping to the TP, right?
>>
>> So I think we need a conditional jump (with the "likely" annotation) for
>> this even when the TP is disabled.
>
> Hmmm... still not following. Where the said NULL dereference happen?
> TEC conditional is equivalent to "if (COND) TP;". If you don't use
> TEC, it'll be "if (COND) if (TP enabled) TP;". With TEC, it will be
> "if (TP enabled) if (COND) TP;". There's no other difference.
>
> Thanks.
>
I've made a quick investigation on TP implementation, and finally
figured out what I was wrong - I thought the COND would be checkd in a
probe, but it's not. Thanks for pointing it out.
However, for some reason, it seems gcc generated code that evaluates the
arguments - bdev_get_queue() in this case - before checking the COND.
Simple test module below caused a NULL pointer dereference when I used
TRACE_EVENT_CONDITION(), but not for conditional jump:
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/bio.h>
static int __init init_mod(void)
{
struct bio *bio = bio_alloc(GFP_KERNEL, 0);
bio_endio(bio, 0);
bio_put(bio);
return 0;
}
static void __exit exit_mod(void)
{
}
module_init(init_mod);
module_exit(exit_mod);
Thanks,
Namhyung
prev parent reply other threads:[~2012-02-01 2:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-29 9:41 [PATCH] block: add missing block_bio_complete() tracepoint Namhyung Kim
2012-01-29 9:41 ` Namhyung Kim
2012-01-29 19:24 ` Tejun Heo
2012-01-30 1:44 ` Namhyung Kim
2012-01-30 1:47 ` Tejun Heo
2012-01-30 2:22 ` Namhyung Kim
2012-01-30 2:30 ` Tejun Heo
2012-01-30 2:49 ` Namhyung Kim
2012-01-30 2:53 ` Tejun Heo
2012-01-30 5:51 ` Namhyung Kim
2012-01-30 5:54 ` Tejun Heo
2012-01-30 6:02 ` Namhyung Kim
2012-01-30 6:38 ` Namhyung Kim
2012-01-30 6:38 ` Namhyung Kim
2012-01-30 17:05 ` Tejun Heo
2012-01-31 6:30 ` Namhyung Kim
2012-01-31 10:39 ` Tejun Heo
2012-02-01 2:18 ` Namhyung Kim [this message]
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=4F28A0F9.9070603@gmail.com \
--to=namhyung@gmail.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.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.