Netdev List
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Victor Nogueira <victor@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 16:54:02 +0100	[thread overview]
Message-ID: <ZZQxmg3QOxzXcrW0@nanopsycho> (raw)
In-Reply-To: <CAM0EoMkUQzxtiaB9r=Tz5Wc3KfEDCfyy5ENSeb8M+iK9fs_HVQ@mail.gmail.com>

Tue, Jan 02, 2024 at 03:52:01PM CET, jhs@mojatatu.com wrote:
>On Tue, Jan 2, 2024 at 9:29 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Tue, Jan 02, 2024 at 03:06:28PM CET, jhs@mojatatu.com wrote:
>> >On Tue, Jan 2, 2024 at 4:59 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >>
>> >> 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
>> >>
>> >
>> >We need another rule in the doc on nit-picking which states that we
>> >need to make progress at some point. We made many changes to this
>> >patchset based on your suggestions for no other reason other that we
>> >can progress the discussion. This is a patch that fixes a bug of which
>> >there are multiple syzbot reports and consumers of the API(last one
>> >just reported from the MTCP people). There's some sense of urgency to
>> >apply this patch before the original goes into net. More importantly:
>> >This patch fixes the issue and follows the same common check which was
>> >already being done in the committed patchset to check if the qdisc
>> >supports the block set/get operations.
>> >
>> >There are about 3 ways to do this check, you objected to the original,
>> >we picked something that works fine,  and now you are picking a
>> >different way with tcf_block. I dont see how tcf_block check would
>> >help or solve this problem at all given this is a qdisc issue not a
>> >class issue. What am I missing?
>>
>> Perhaps I got something wrong, but I thought that the issue is
>> cl_ops->tcf_block being null for some qdiscs, isn't it?
>>
>
>We attach these ports/netdevs only on capable qdiscs i.e ones that
>have  in/egress_block_set/get() - which happen to be ingress and
>clsact only.
>The problem was we were blindly assuming that presence of
>cl->tcf_block() implies presence of in/egress_block_set/get(). The
>earlier patches surrounded this code with attribute checks and so it
>worked there.

Syskaller report says:

KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f]
CPU: 1 PID: 5061 Comm: syz-executor323 Not tainted 6.7.0-rc6-syzkaller-01658-gc2b2ee36250d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
RIP: 0010:qdisc_block_add_dev net/sched/sch_api.c:1190 [inline]

Line 1190 is:
block = cl_ops->tcf_block(sch, TC_H_MIN_INGRESS, NULL);

So the cl_ops->tcf_block == NULL

Why can't you just check it? Why do you want to check in/egress_block_set/get()
instead? I don't follow :/

Btw, the checks in __qdisc_destroy() do also look wrong.



>
>BTW: Do you have an example of a test case where we can test the class
>grafting (eg using htb with tcf_block)? It doesnt have any impact on
>this patcheset here but we want to add it as a regression checker on
>tdc in the future if someone makes a change.
>
>cheers,
>jamal
>
>> >
>> >cheers,
>> >jamal
>> >
>> >> >
>> >> >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
>> >> >

  reply	other threads:[~2024-01-02 15:54 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
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 [this message]
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=ZZQxmg3QOxzXcrW0@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