From: Jiri Pirko <jiri@resnulli.us>
To: Victor Nogueira <victor@mojatatu.com>
Cc: jhs@mojatatu.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, xiyou.wangcong@gmail.com,
idosch@idosch.org, mleitner@redhat.com, vladbu@nvidia.com,
paulb@nvidia.com, pctammela@mojatatu.com, netdev@vger.kernel.org,
kernel@mojatatu.com,
syzbot+84339b9e7330daae4d66@syzkaller.appspotmail.com,
syzbot+806b0572c8d06b66b234@syzkaller.appspotmail.com,
syzbot+0039110f932d438130f9@syzkaller.appspotmail.com
Subject: Re: [PATCH net-next v2 1/1] net/sched: We should only add appropriate qdiscs blocks to ports' xarray
Date: Tue, 2 Jan 2024 10:59:44 +0100 [thread overview]
Message-ID: <ZZPekLXICu2AUxlX@nanopsycho> (raw)
In-Reply-To: <20231231172320.245375-1-victor@mojatatu.com>
The patch subject should briefly describe the nature of the change. Not
what "we" should or should not do.
Sun, Dec 31, 2023 at 06:23:20PM CET, victor@mojatatu.com wrote:
>We should only add qdiscs to the blocks ports' xarray in ingress that
>support ingress_block_set/get or in egress that support
>egress_block_set/get.
Tell the codebase what to do, be imperative. Please read again:
https://www.kernel.org/doc/html/v6.6/process/submitting-patches.html#describe-your-changes
>
>Fixes: 913b47d3424e ("net/sched: Introduce tc block netdev tracking infra")
>Signed-off-by: Victor Nogueira <victor@mojatatu.com>
>Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
>Reported-by: Ido Schimmel <idosch@nvidia.com>
>Closes: https://lore.kernel.org/all/ZY1hBb8GFwycfgvd@shredder/
>Tested-by: Ido Schimmel <idosch@nvidia.com>
>Reported-and-tested-by: syzbot+84339b9e7330daae4d66@syzkaller.appspotmail.com
>Closes: https://lore.kernel.org/all/0000000000007c85f5060dcc3a28@google.com/
>Reported-and-tested-by: syzbot+806b0572c8d06b66b234@syzkaller.appspotmail.com
>Closes: https://lore.kernel.org/all/00000000000082f2f2060dcc3a92@google.com/
>Reported-and-tested-by: syzbot+0039110f932d438130f9@syzkaller.appspotmail.com
>Closes: https://lore.kernel.org/all/0000000000007fbc8c060dcc3a5c@google.com/
>---
>v1 -> v2:
>
>- Remove newline between fixes tag and Signed-off-by tag
>- Add Ido's Reported-by and Tested-by tags
>- Add syzbot's Reported-and-tested-by tags
>
> net/sched/sch_api.c | 34 ++++++++++++++++++++--------------
> 1 file changed, 20 insertions(+), 14 deletions(-)
>
>diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>index 299086bb6205..426be81276f1 100644
>--- a/net/sched/sch_api.c
>+++ b/net/sched/sch_api.c
>@@ -1187,23 +1187,29 @@ static int qdisc_block_add_dev(struct Qdisc *sch, struct net_device *dev,
> struct tcf_block *block;
> int err;
>
Why don't you just check cl_ops->tcf_block ?
In fact, there could be a helper to do it for you either call the op or
return NULL in case it is not defined.
>- block = cl_ops->tcf_block(sch, TC_H_MIN_INGRESS, NULL);
>- if (block) {
>- err = xa_insert(&block->ports, dev->ifindex, dev, GFP_KERNEL);
>- if (err) {
>- NL_SET_ERR_MSG(extack,
>- "ingress block dev insert failed");
>- return err;
>+ if (sch->ops->ingress_block_get) {
>+ block = cl_ops->tcf_block(sch, TC_H_MIN_INGRESS, NULL);
>+ if (block) {
>+ err = xa_insert(&block->ports, dev->ifindex, dev,
>+ GFP_KERNEL);
>+ if (err) {
>+ NL_SET_ERR_MSG(extack,
>+ "ingress block dev insert failed");
>+ return err;
>+ }
> }
> }
>
>- block = cl_ops->tcf_block(sch, TC_H_MIN_EGRESS, NULL);
>- if (block) {
>- err = xa_insert(&block->ports, dev->ifindex, dev, GFP_KERNEL);
>- if (err) {
>- NL_SET_ERR_MSG(extack,
>- "Egress block dev insert failed");
>- goto err_out;
>+ if (sch->ops->egress_block_get) {
>+ block = cl_ops->tcf_block(sch, TC_H_MIN_EGRESS, NULL);
>+ if (block) {
>+ err = xa_insert(&block->ports, dev->ifindex, dev,
>+ GFP_KERNEL);
>+ if (err) {
>+ NL_SET_ERR_MSG(extack,
>+ "Egress block dev insert failed");
>+ goto err_out;
>+ }
> }
> }
>
>--
>2.25.1
>
next prev parent reply other threads:[~2024-01-02 9:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 17:23 [PATCH net-next v2 1/1] net/sched: We should only add appropriate qdiscs blocks to ports' xarray Victor Nogueira
2024-01-02 9:59 ` Jiri Pirko [this message]
2024-01-02 14:06 ` Jamal Hadi Salim
2024-01-02 14:29 ` Jiri Pirko
2024-01-02 14:52 ` Jamal Hadi Salim
2024-01-02 15:54 ` Jiri Pirko
2024-01-02 17:06 ` Jamal Hadi Salim
2024-01-03 12:59 ` Jiri Pirko
2024-01-03 14:09 ` Jamal Hadi Salim
2024-01-03 14:26 ` Jiri Pirko
2024-01-03 14:43 ` Jamal Hadi Salim
2024-01-03 16:09 ` Jiri Pirko
2024-01-03 17:08 ` Jamal Hadi Salim
2024-01-03 18:02 ` Jiri Pirko
2024-01-04 18:06 ` Kui-Feng Lee
2024-01-04 18:49 ` Kui-Feng Lee
2024-01-04 19:40 ` Victor Nogueira
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=ZZPekLXICu2AUxlX@nanopsycho \
--to=jiri@resnulli.us \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@idosch.org \
--cc=jhs@mojatatu.com \
--cc=kernel@mojatatu.com \
--cc=kuba@kernel.org \
--cc=mleitner@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paulb@nvidia.com \
--cc=pctammela@mojatatu.com \
--cc=syzbot+0039110f932d438130f9@syzkaller.appspotmail.com \
--cc=syzbot+806b0572c8d06b66b234@syzkaller.appspotmail.com \
--cc=syzbot+84339b9e7330daae4d66@syzkaller.appspotmail.com \
--cc=victor@mojatatu.com \
--cc=vladbu@nvidia.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 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).