From: Simon Horman <horms@kernel.org>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, jiri@resnulli.us, xiyou.wangcong@gmail.com,
daniel@iogearbox.net, idosch@idosch.org, netdev@vger.kernel.org
Subject: Re: [PATCH net 1/1] net, sched: Fix SKB_NOT_DROPPED_YET splat under debug config
Date: Sat, 4 Nov 2023 13:10:54 +0000 [thread overview]
Message-ID: <20231104131054.GB891380@kernel.org> (raw)
In-Reply-To: <20231028171610.28596-1-jhs@mojatatu.com>
On Sat, Oct 28, 2023 at 01:16:10PM -0400, Jamal Hadi Salim wrote:
> Getting the following splat [1] with CONFIG_DEBUG_NET=y and this
> reproducer [2]. Problem seems to be that classifiers clear 'struct
> tcf_result::drop_reason', thereby triggering the warning in
> __kfree_skb_reason() due to reason being 'SKB_NOT_DROPPED_YET' (0).
>
> Fixed by disambiguating a legit error from a verdict with a bogus drop_reason
>
> [1]
> WARNING: CPU: 0 PID: 181 at net/core/skbuff.c:1082 kfree_skb_reason+0x38/0x130
> Modules linked in:
> CPU: 0 PID: 181 Comm: mausezahn Not tainted 6.6.0-rc6-custom-ge43e6d9582e0 #682
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014
> RIP: 0010:kfree_skb_reason+0x38/0x130
> [...]
> Call Trace:
> <IRQ>
> __netif_receive_skb_core.constprop.0+0x837/0xdb0
> __netif_receive_skb_one_core+0x3c/0x70
> process_backlog+0x95/0x130
> __napi_poll+0x25/0x1b0
> net_rx_action+0x29b/0x310
> __do_softirq+0xc0/0x29b
> do_softirq+0x43/0x60
> </IRQ>
>
> [2]
>
> ip link add name veth0 type veth peer name veth1
> ip link set dev veth0 up
> ip link set dev veth1 up
> tc qdisc add dev veth1 clsact
> tc filter add dev veth1 ingress pref 1 proto all flower dst_mac 00:11:22:33:44:55 action drop
> mausezahn veth0 -a own -b 00:11:22:33:44:55 -q -c 1
>
> Ido reported:
>
> [...] getting the following splat [1] with CONFIG_DEBUG_NET=y and this
> reproducer [2]. Problem seems to be that classifiers clear 'struct
> tcf_result::drop_reason', thereby triggering the warning in
> __kfree_skb_reason() due to reason being 'SKB_NOT_DROPPED_YET' (0). [...]
>
> [1]
> WARNING: CPU: 0 PID: 181 at net/core/skbuff.c:1082 kfree_skb_reason+0x38/0x130
> Modules linked in:
> CPU: 0 PID: 181 Comm: mausezahn Not tainted 6.6.0-rc6-custom-ge43e6d9582e0 #682
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014
> RIP: 0010:kfree_skb_reason+0x38/0x130
> [...]
> Call Trace:
> <IRQ>
> __netif_receive_skb_core.constprop.0+0x837/0xdb0
> __netif_receive_skb_one_core+0x3c/0x70
> process_backlog+0x95/0x130
> __napi_poll+0x25/0x1b0
> net_rx_action+0x29b/0x310
> __do_softirq+0xc0/0x29b
> do_softirq+0x43/0x60
> </IRQ>
>
> [2]
> #!/bin/bash
>
> ip link add name veth0 type veth peer name veth1
> ip link set dev veth0 up
> ip link set dev veth1 up
> tc qdisc add dev veth1 clsact
> tc filter add dev veth1 ingress pref 1 proto all flower dst_mac 00:11:22:33:44:55 action drop
> mausezahn veth0 -a own -b 00:11:22:33:44:55 -q -c 1
>
> What happens is that inside most classifiers the tcf_result is copied over
> from a filter template e.g. *res = f->res which then implicitly overrides
> the prior SKB_DROP_REASON_TC_{INGRESS,EGRESS} default drop code which was
> set via sch_handle_{ingress,egress}() for kfree_skb_reason().
>
> Commit text above copied verbatim from Daniel. The general idea of the patch
> is not very different from what Ido originally posted but instead done at the
> cls_api codepath.
>
> Fixes: 54a59aed395c ("net, sched: Make tc-related drop reason more flexible")
> Reported-by: Ido Schimmel <idosch@idosch.org>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Link: https://lore.kernel.org/netdev/ZTjY959R+AFXf3Xy@shredder
Hi Jamal,
FWIIW, I think it would be nicer to fix this the classifiers so they don't
do this, which by my reading is what Daniel's patch did.
But, I don't feel strongly about this and I do tend to think the
approach taken in this patch is a nice clean fix for net.
Reviewed-by: Simon Horman <horms@kernel.org>
BTW, this patch is marked as Not Applicable in patchwork.
I am unsure why.
next prev parent reply other threads:[~2023-11-04 13:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-28 17:16 [PATCH net 1/1] net, sched: Fix SKB_NOT_DROPPED_YET splat under debug config Jamal Hadi Salim
2023-11-04 13:10 ` Simon Horman [this message]
2023-11-04 15:46 ` Jamal Hadi Salim
2023-11-04 16:12 ` Simon Horman
2023-11-06 9:00 ` patchwork-bot+netdevbpf
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=20231104131054.GB891380@kernel.org \
--to=horms@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@idosch.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=xiyou.wangcong@gmail.com \
/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.