All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Theodore Ts'o <tytso@mit.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [BUG] ext4 trace events cause NULL pointer dereferences
Date: Thu, 22 Jul 2010 01:49:57 -0400	[thread overview]
Message-ID: <20100722054957.GA11670@infradead.org> (raw)
In-Reply-To: <20100721222508.8704.A69D9226@jp.fujitsu.com>

On Wed, Jul 21, 2010 at 10:31:20PM +0900, KOSAKI Motohiro wrote:
> But, I don't think this is proper fix because we don't want any overhead
> if the tracepoint is disabled.
> 
> So, How do we check NULL in TP_fast_assign()?

I think ext4 is simply using an incorrectly typed tracepoint here.
If you want it to be useful in any way it needs a sb paramter and
an optional inode paramter, not the allocation context.

Also the whole ext4_mb_release_group_pa function seems to be a bit
misdesigned.  The code using ac is a totally separate block at the
end of the function and does work that's unrelated to the rest
of the function.  Just making it a separate helper can calling it
only from those places that have the allocation context would make
the code more clear.

  parent reply	other threads:[~2010-07-22  5:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-16  8:48 [BUG] ext4 trace events cause NULL pointer dereferences Li Zefan
2010-07-21 13:31 ` KOSAKI Motohiro
2010-07-21 14:16   ` Steven Rostedt
2010-07-21 14:21     ` Frederic Weisbecker
2010-07-22  5:45     ` Li Zefan
2010-07-22  5:49   ` Christoph Hellwig [this message]
2010-07-23  1:13     ` Ted Ts'o
2010-07-23  5:47       ` KOSAKI Motohiro
2010-07-23  5:47         ` KOSAKI Motohiro
2010-07-23  9:11         ` Theodore Tso
2010-07-23  9:19           ` Li Zefan
2010-07-26  2:20           ` Li Zefan

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=20100722054957.GA11670@infradead.org \
    --to=hch@infradead.org \
    --cc=fweisbec@gmail.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=rostedt@goodmis.org \
    --cc=tytso@mit.edu \
    /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.