Re: [BUG] ext4 trace events cause NULL pointer dereferences

From: Li Zefan
Date: Thu Jul 22 2010 - 01:40:32 EST


Steven Rostedt wrote:
> On Wed, 2010-07-21 at 22:31 +0900, KOSAKI Motohiro wrote:
>> Hi Steven,
>
>> if (ac)
>> trace_ext4_mb_release_group_pa(ac, pa);
>>
>> 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()?
>
> You could do:
>
> TP_fast_assign(
> if (ac) {
> __entry->dev = ac->ac_sb->s_dev;
> __entry->ino = ac->ac_inode->i_ino;
> __entry->pa_pstart = pa->pa_pstart;
> __entry->pa_len = pa->pa_len;
> }

This leaves __entry->dev etc as arbitrary value, since the entry returned
by the ring buffer is not zeroed, so I think better add an else branch to
zero those values.

> ),
>
> But this just makes the __entry null and wastes the ring buffer.
>
> I may be able to add a __discard_entry that may help. Then we could do
> something like this:
>
> if (ac) {
> __entry->dev = ac->ac_sb->s_dev;
> __entry->ino = ac->ac_inode->i_ino;
> __entry->pa_pstart = pa->pa_pstart;
> __entry->pa_len = pa->pa_len;
> } else
> __discard_entry;
>
> Does this seem reasonable?
>
> But for now, the wasting the entry seems to be the only choice we have,
> or to do as you suggested and have the "if (ac) trace_...", but I don't
> like that.
>

As I was (and still am) not sure what is the best fix, I decided
to send out a bug report instead of a patch..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/