* null pointer at cls_api.c
@ 2010-08-05 19:24 Franchoze Eric
2010-08-05 20:07 ` David Miller
2010-08-06 10:22 ` [PATCH] pkt_sched: Fix sch_sfq vs tcf_bind_filter oops Jarek Poplawski
0 siblings, 2 replies; 4+ messages in thread
From: Franchoze Eric @ 2010-08-05 19:24 UTC (permalink / raw)
To: netdev
Hello, can somebody follow up with approriate fix for that bug? It's reproducible on the latest 2.6.32.17 kernel with Centos5 user land.
Script to reproduce is bellow. I did quick fix for that to show where is the issue.
Thanks.
--- net/sched/cls_api.c_orig 2010-08-05 10:46:01.000000000 -0700
+++ net/sched/cls_api.c 2010-08-05 12:03:01.000000000 -0700
@@ -255,6 +255,11 @@ replay:
kfree(tp);
goto errout;
}
+
+ if (!tp || !tp->ops) {
+ err = -ENOENT;
+ goto errout;
+ }
tp->ops = tp_ops;
tp->protocol = protocol;
tp->prio = nprio ? : TC_H_MAJ(tcf_auto_prio(*back));
#!/bin/bash
DEV=tun1
SPEED="100kbit"
ISPEED="10Mbit"
tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: htb default 1
tc class add dev $DEV parent 1: classid 1:1 htb rate ${ISPEED}
tc class add dev $DEV parent 1:1 classid 1:2 htb rate ${SPEED} ceil ${SPEED} prio 0
tc qdisc add dev $DEV parent 1:2 handle 2: sfq perturb 10
tc filter add dev $DEV parent 2: protocol ip u32 match ip dport 80 0xffff flowid 2:1
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<(null)>] (null)
PGD 81ca27067 PUD 825b8e067 PMD 0
Oops: 0010 [#1] PREEMPT SMP
last sysfs file: /sys/class/misc/watchdog/dev
CPU 7
Modules linked in: wdt_pci sc520_wdt pcwd_pci i6300esb hpwdt cls_u32 sch_sfq sch_htb lockd sunrpc xt_connlimit xt_MARK iptable_mangle ipt_REDIRECT iptable_nat nf_nat tun ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables dm_mirror dm_multipath scsi_dh sbs sbshc power_meter hwmon battery ac tpm_tis serio_raw rtc_cmos rtc_core rtc_lib tpm tpm_bios button tg3 firmware_class libphy amd64_edac_mod edac_core i2c_piix4 i2c_core dm_region_hash dm_log dm_mod sata_svw libata cciss sd_mod scsi_mod ext3 jbd
Pid: 4807, comm: tc Not tainted 2.6.32.17-af #1 ProLiant DL165 G6
RIP: 0010:[<0000000000000000>] [<(null)>] (null)
RSP: 0018:ffff880823547880 EFLAGS: 00010286
RAX: ffffffffa0292b80 RBX: ffff88082484f700 RCX: ffff880823547898
RDX: 0000000000020001 RSI: 0000000000000000 RDI: ffff88082568e000
RBP: ffff8808235478d8 R08: ffff880427c00040 R09: 0000000000000000
R10: 0000000000000000 R11: ffff88082484f7c0 R12: ffff88082546603c
R13: ffff88081ca8f440 R14: ffff88082484f7c0 R15: ffff880823547908
FS: 00007fb0ca8186e0(0000) GS:ffff880436440000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000008259ec000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process tc (pid: 4807, threadinfo ffff880823546000, task ffff880824b68800)
Stack:
ffffffffa0299836 ffff8808235478c8 0000000000000000 0000000000000000
<0> ffff88081ca8f440 ffff88082546603c ffff88081ca8f440 ffff88082546603c
<0> 0000000080000800 ffff88082484f700 0000000000000000 ffff880823547998
Call Trace:
[<ffffffffa0299836>] ? u32_set_parms+0xca/0x14f [cls_u32]
[<ffffffffa0299e49>] u32_change+0x316/0x3bd [cls_u32]
[<ffffffffa0299696>] ? kzalloc+0xf/0x11 [cls_u32]
[<ffffffff8126f9e1>] tc_ctl_tfilter+0x505/0x5f6
[<ffffffff810d4fbd>] ? ____cache_alloc+0x1d/0x223
[<ffffffff81262377>] rtnetlink_rcv_msg+0x1c3/0x1e2
[<ffffffff812621b4>] ? rtnetlink_rcv_msg+0x0/0x1e2
[<ffffffff81273273>] netlink_rcv_skb+0x3e/0x8d
[<ffffffff812620aa>] rtnetlink_rcv+0x20/0x29
[<ffffffff812730e8>] netlink_unicast+0xed/0x154
[<ffffffff8127464b>] netlink_sendmsg+0x245/0x258
[<ffffffff812730f8>] ? netlink_unicast+0xfd/0x154
[<ffffffff81248ffc>] __sock_sendmsg+0x59/0x62
[<ffffffff8124988e>] sock_sendmsg+0xc7/0xe0
[<ffffffff810604bb>] ? autoremove_wake_function+0x0/0x38
[<ffffffff810604bb>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8124a345>] ? move_addr_to_kernel+0x40/0x49
[<ffffffff8125254b>] ? verify_iovec+0x4f/0x94
[<ffffffff81249a85>] sys_sendmsg+0x1de/0x24d
[<ffffffff810ae914>] ? lru_cache_add_lru+0x38/0x3d
[<ffffffff810c6468>] ? page_add_new_anon_rmap+0x3a/0x49
[<ffffffff810bee8f>] ? handle_mm_fault+0x5e8/0x602
[<ffffffff8100bb6b>] system_call_fastpath+0x16/0x1b
Code: Bad RIP value.
RIP [<(null)>] (null)
RSP <ffff880823547880>
CR2: 0000000000000000
---[ end trace 62c007c0b888891e ]---
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: null pointer at cls_api.c
2010-08-05 19:24 null pointer at cls_api.c Franchoze Eric
@ 2010-08-05 20:07 ` David Miller
2010-08-05 20:21 ` Stephen Hemminger
2010-08-06 10:22 ` [PATCH] pkt_sched: Fix sch_sfq vs tcf_bind_filter oops Jarek Poplawski
1 sibling, 1 reply; 4+ messages in thread
From: David Miller @ 2010-08-05 20:07 UTC (permalink / raw)
To: franchoze; +Cc: netdev
From: Franchoze Eric <franchoze@yandex.ru>
Date: Thu, 05 Aug 2010 23:24:15 +0400
> @@ -255,6 +255,11 @@ replay:
> kfree(tp);
> goto errout;
> }
> +
> + if (!tp || !tp->ops) {
> + err = -ENOENT;
> + goto errout;
> + }
> tp->ops = tp_ops;
> tp->protocol = protocol;
> tp->prio = nprio ? : TC_H_MAJ(tcf_auto_prio(*back));
>
This patch makes no sense.
We check for "tp" being non-NULL in the code block about the if() block you're
adding these checks to.
And tp->ops of course might be NULL here, and that's perfectly fine,
as we're about to assign "tp_ops" to it.
Looking at your backtrace I think perhaps your crash is elsewhere.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: null pointer at cls_api.c
2010-08-05 20:07 ` David Miller
@ 2010-08-05 20:21 ` Stephen Hemminger
0 siblings, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2010-08-05 20:21 UTC (permalink / raw)
To: David Miller; +Cc: franchoze, netdev
On Thu, 05 Aug 2010 13:07:55 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Franchoze Eric <franchoze@yandex.ru>
> Date: Thu, 05 Aug 2010 23:24:15 +0400
>
> > @@ -255,6 +255,11 @@ replay:
> > kfree(tp);
> > goto errout;
> > }
> > +
> > + if (!tp || !tp->ops) {
> > + err = -ENOENT;
> > + goto errout;
> > + }
> > tp->ops = tp_ops;
> > tp->protocol = protocol;
> > tp->prio = nprio ? : TC_H_MAJ(tcf_auto_prio(*back));
> >
>
> This patch makes no sense.
>
> We check for "tp" being non-NULL in the code block about the if() block you're
> adding these checks to.
>
> And tp->ops of course might be NULL here, and that's perfectly fine,
> as we're about to assign "tp_ops" to it.
>
> Looking at your backtrace I think perhaps your crash is elsewhere.
Looks like a cls_u32 bug:
Aug 5 12:58:21 nehalam kernel: [15160.920162] u32 classifier
Aug 5 12:58:21 nehalam kernel: [15160.920165] Actions configured
Aug 5 12:58:21 nehalam kernel: [15160.920346] PGD b6901067 PUD 93323067 PMD 0
Aug 5 12:58:21 nehalam kernel: [15160.920357] CPU 6
Aug 5 12:58:21 nehalam kernel: [15160.920358] Modules linked in: cls_u32 sch_sfq sch_htb dummy ntfs vfat msdos fat nfs lockd fscache nfs_acl auth_rpcgss sunrpc autofs4 binfmt_misc ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc kvm_intel kvm radeon ttm drm_kms_helper drm i2c_algo_bit snd_hda_codec_analog ipv6 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse asus_atk0110 soundcore serio_raw snd_page_alloc usbhid mvsas libsas floppy scsi_transport_sas e1000e sky2
Aug 5 12:58:21 nehalam kernel: [15160.920427]
Aug 5 12:58:21 nehalam kernel: [15160.920433] Pid: 25645, comm: tc Not tainted 2.6.35+ #31 P6T DELUXE/System Product Name
Aug 5 12:58:21 nehalam kernel: [15160.920436] RIP: 0010:[<0000000000000000>] [<(null)>] (null)
Aug 5 12:58:21 nehalam kernel: [15160.920441] RSP: 0018:ffff880093399850 EFLAGS: 00010286
Aug 5 12:58:21 nehalam kernel: [15160.920445] RAX: ffffffffa0502fc0 RBX: ffff8801b38bd9c0 RCX: ffff880093399878
Aug 5 12:58:21 nehalam kernel: [15160.920449] RDX: 0000000000020001 RSI: 0000000000000000 RDI: ffff880047d88000
Aug 5 12:58:21 nehalam kernel: [15160.920452] RBP: ffff8800933998b8 R08: ffffffffa050a4a0 R09: 0000000000000000
Aug 5 12:58:21 nehalam kernel: [15160.920456] R10: ffffffffa050997e R11: 2222222222222222 R12: ffff8801b4eb9d40
Aug 5 12:58:21 nehalam kernel: [15160.920461] R13: ffff8800933998e8 R14: ffff880093399878 R15: ffff8801b4fdc740
Aug 5 12:58:21 nehalam kernel: [15160.920466] FS: 00007fb43c74d700(0000) GS:ffff880001ec0000(0000) knlGS:0000000000000000
Aug 5 12:58:21 nehalam kernel: [15160.920471] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Aug 5 12:58:21 nehalam kernel: [15160.920475] CR2: 0000000000000000 CR3: 000000001ccfb000 CR4: 00000000000006e0
Aug 5 12:58:21 nehalam kernel: [15160.920480] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Aug 5 12:58:21 nehalam kernel: [15160.920484] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 5 12:58:21 nehalam kernel: [15160.920489] Process tc (pid: 25645, threadinfo ffff880093398000, task ffff8801b77802c0)
Aug 5 12:58:21 nehalam kernel: [15160.920495] ffffffffa0509c05 ffff8800933998a8 ffffffff8110208a ffff8800933998b8
Aug 5 12:58:21 nehalam kernel: [15160.920501] <0> 0000000000000000 0000000000000000 ffff8801b4fdc740 ffff8801b38bd9c0
Aug 5 12:58:21 nehalam kernel: [15160.920509] <0> ffff8801b4fdc740 ffff8801b38bd9c0 ffff8800933999e8 0000000080000800
Aug 5 12:58:21 nehalam kernel: [15160.920524] [<ffffffffa0509c05>] ? u32_set_parms+0x125/0x260 [cls_u32]
Aug 5 12:58:21 nehalam kernel: [15160.920531] [<ffffffff8110208a>] ? __kmalloc+0x21a/0x230
Aug 5 12:58:21 nehalam kernel: [15160.920537] [<ffffffffa0509f18>] u32_change+0x1d8/0x4f0 [cls_u32]
Aug 5 12:58:21 nehalam kernel: [15160.920543] [<ffffffffa050a338>] ? u32_init+0x108/0x180 [cls_u32]
Aug 5 12:58:21 nehalam kernel: [15160.920551] [<ffffffff813f90e1>] tc_ctl_tfilter+0x321/0x780
Aug 5 12:58:21 nehalam kernel: [15160.920560] [<ffffffff813ea733>] rtnetlink_rcv_msg+0x163/0x270
Aug 5 12:58:21 nehalam kernel: [15160.920564] [<ffffffff813ea5d0>] ? rtnetlink_rcv_msg+0x0/0x270
Aug 5 12:58:21 nehalam kernel: [15160.920568] [<ffffffff813fed31>] netlink_rcv_skb+0xa1/0xd0
Aug 5 12:58:21 nehalam kernel: [15160.920572] [<ffffffff813ea5c0>] rtnetlink_rcv+0x20/0x30
Aug 5 12:58:21 nehalam kernel: [15160.920576] [<ffffffff813fe966>] netlink_unicast+0x296/0x2e0
Aug 5 12:58:21 nehalam kernel: [15160.920579] [<ffffffff813ff73e>] netlink_sendmsg+0x1fe/0x2e0
Aug 5 12:58:21 nehalam kernel: [15160.920585] [<ffffffff813cac9e>] sock_sendmsg+0xee/0x120
Aug 5 12:58:21 nehalam kernel: [15160.920590] [<ffffffff813cb77d>] ? move_addr_to_kernel+0x5d/0x60
Aug 5 12:58:21 nehalam kernel: [15160.920594] [<ffffffff813d6513>] ? verify_iovec+0x93/0x100
Aug 5 12:58:21 nehalam kernel: [15160.920598] [<ffffffff813cc510>] sys_sendmsg+0x240/0x3a0
Aug 5 12:58:21 nehalam kernel: [15160.920604] [<ffffffff8109a664>] ? audit_syscall_entry+0x254/0x280
Aug 5 12:58:21 nehalam kernel: [15160.920609] [<ffffffff8148622d>] ? do_page_fault+0x14d/0x310
Aug 5 12:58:21 nehalam kernel: [15160.920614] [<ffffffff810026ab>] system_call_fastpath+0x16/0x1b
Aug 5 12:58:21 nehalam kernel: [15160.920625] RSP <ffff880093399850>
Aug 5 12:58:21 nehalam kernel: [15160.920629] ---[ end trace fad08b9c79000a10 ]---
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] pkt_sched: Fix sch_sfq vs tcf_bind_filter oops
2010-08-05 19:24 null pointer at cls_api.c Franchoze Eric
2010-08-05 20:07 ` David Miller
@ 2010-08-06 10:22 ` Jarek Poplawski
1 sibling, 0 replies; 4+ messages in thread
From: Jarek Poplawski @ 2010-08-06 10:22 UTC (permalink / raw)
To: Franchoze Eric; +Cc: netdev, David Miller, Patrick McHardy
Franchoze Eric wrote:
> Hello, can somebody follow up with approriate fix for that bug? It's reproducible on the latest 2.6.32.17 kernel with Centos5 user land.
> Script to reproduce is bellow. I did quick fix for that to show where is the issue.
I can't test it with 2.6.32 now but it seems the patch below should
help. Please send your "Tested-by" if so.
Thanks,
Jarek P.
------------>
Since there was added ->tcf_chain() method without ->bind_tcf() to
sch_sfq class options, there is oops when a filter is added with
the classid parameter.
Fixes commit 7d2681a6ff4f9ab5e48d02550b4c6338f1638998
netdev thread: null pointer at cls_api.c
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Reported-by: Franchoze Eric <franchoze@yandex.ru>
---
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index e85352b..534f332 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -513,6 +513,12 @@ static unsigned long sfq_get(struct Qdisc *sch, u32 classid)
return 0;
}
+static unsigned long sfq_bind(struct Qdisc *sch, unsigned long parent,
+ u32 classid)
+{
+ return 0;
+}
+
static struct tcf_proto **sfq_find_tcf(struct Qdisc *sch, unsigned long cl)
{
struct sfq_sched_data *q = qdisc_priv(sch);
@@ -567,6 +573,7 @@ static void sfq_walk(struct Qdisc *sch, struct qdisc_walker *arg)
static const struct Qdisc_class_ops sfq_class_ops = {
.get = sfq_get,
.tcf_chain = sfq_find_tcf,
+ .bind_tcf = sfq_bind,
.dump = sfq_dump_class,
.dump_stats = sfq_dump_class_stats,
.walk = sfq_walk,
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-08-06 10:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-05 19:24 null pointer at cls_api.c Franchoze Eric
2010-08-05 20:07 ` David Miller
2010-08-05 20:21 ` Stephen Hemminger
2010-08-06 10:22 ` [PATCH] pkt_sched: Fix sch_sfq vs tcf_bind_filter oops Jarek Poplawski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).