From: Cong Wang <xiyou.wangcong@gmail.com>
To: Chengfeng Ye <dg573847474@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
jhs@mojatatu.com, jiri@resnulli.us, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/sched: use spin_lock_bh() on &gact->tcf_lock
Date: Sun, 8 Oct 2023 10:56:09 -0700 [thread overview]
Message-ID: <ZSLtOViO2p31Jzd6@pop-os.localdomain> (raw)
In-Reply-To: <CAAo+4rW=zh_d7AxJSP0uLuO7w+_PmbBfBr6D4=4X2Ays7ATqoA@mail.gmail.com>
On Thu, Oct 05, 2023 at 05:01:07PM +0800, Chengfeng Ye wrote:
> Hi Jakub,
>
> Thanks for the reply,
>
> I inspected the code a bit more, it seems that the TC action is called from
> tcf_proto_ops.classify() callback, which is called from Qdisc_ops enqueue
> callback.
>
> Then Qdisc enqueue callback is from
>
> -> __dev_queue_xmit()
> -> __dev_xmit_skb()
> -> dev_qdisc_enqueue()
>
> inside the net core. It seems that this __dev_queue_xmit() callback is
> typically called from BH context (e.g., NET_TX_SOFTIRQ) with BH
> already disabled, but sometimes also can from a work queue under
> process context, one case is the br_mrp_test_work_expired() inside
> net/bridge/br_mrp.c. Does it indicate that this TC action could also be
> called with BH enable? I am not a developer so really not sure about it,
> as the networking code is a bit long and complicated.
Doesn't __dev_queue_xmit() itself disable BH with rcu_read_lock_bh()??
Thanks.
next prev parent reply other threads:[~2023-10-08 17:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 18:26 [PATCH] net/sched: use spin_lock_bh() on &gact->tcf_lock Chengfeng Ye
2023-10-01 17:54 ` Simon Horman
2023-10-01 18:32 ` Cong Wang
2023-10-01 18:53 ` Chengfeng Ye
2023-10-05 0:01 ` Jakub Kicinski
2023-10-05 9:01 ` Chengfeng Ye
2023-10-05 11:46 ` Jamal Hadi Salim
2023-10-05 12:15 ` Chengfeng Ye
2023-10-09 6:35 ` Horatiu Vultur
2023-10-09 15:52 ` Jamal Hadi Salim
2023-10-08 17:56 ` Cong Wang [this message]
2023-10-08 18:06 ` Chengfeng Ye
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=ZSLtOViO2p31Jzd6@pop-os.localdomain \
--to=xiyou.wangcong@gmail.com \
--cc=davem@davemloft.net \
--cc=dg573847474@gmail.com \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.