From: Jakub Kicinski <kuba@kernel.org>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: netdev@vger.kernel.org, jiri@resnulli.us,
xiyou.wangcong@gmail.com, davem@davemloft.net,
edumazet@google.com, security@kernel.org, nnamrec@gmail.com
Subject: Re: [PATCH net 1/1 v3] net: sched: Disallow replacing of child qdisc from one parent to another
Date: Wed, 15 Jan 2025 06:36:55 -0800 [thread overview]
Message-ID: <20250115063655.21be5c74@kernel.org> (raw)
In-Reply-To: <CAM0EoMnYi3JBPS7KyPoW5-St-xAaJ8Xa1tEp8JH9483Z5k8cLg@mail.gmail.com>
On Wed, 15 Jan 2025 09:15:31 -0500 Jamal Hadi Salim wrote:
> > On Sat, 11 Jan 2025 10:14:55 -0500 Jamal Hadi Salim wrote:
> > > The semantics of "replace" is for a del/add _on the same node_ and not
> > > a delete from one node(3:1) and add to another node (1:3) as in step10.
> > > While we could "fix" with a more complex approach there could be
> > > consequences to expectations so the patch takes the preventive approach of
> > > "disallow such config".
> >
> > Your explanation reads like you want to prevent a qdisc changing
> > from one parent to another.
>
> Yes.
In the selftest with mq Victor updated I'd say we're not changing
the parent. We replace one child of mq with another.
TC noobs would say mq is the parent.
> > > + if (leaf_q && leaf_q->parent != q->parent) {
> > > + NL_SET_ERR_MSG(extack, "Invalid Parent for operation");
> > > + return -EINVAL;
> > > + }
> >
> > But this test looks at the full parent path, not the major.
> > So the only case you allow is replacing the node.. with itself?
> >
>
> Yes.
>
> > Did you mean to wrap these in TC_H_MAJ() || the parent comparison
> > is redundant || I misunderstand?
>
> I may be missing something - what does TC_H_MAJ() provide?
> The 3:1 and 1:3 in that example are both descendants of the same
> parent. It could have been 1:3 vs 1:2 and the same rules would apply.
Let me flip the question. What qdisc movement / grafts are you intending
to still support?
From the report it sounds like we don't want to support _any_ movement
of existing qdiscs within the hierarchy. Only purpose of graft would
be to install a new / fresh qdisc as a child.
next prev parent reply other threads:[~2025-01-15 14:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-11 15:14 [PATCH net 1/1 v3] net: sched: Disallow replacing of child qdisc from one parent to another Jamal Hadi Salim
2025-01-15 1:26 ` Jakub Kicinski
2025-01-15 14:15 ` Jamal Hadi Salim
2025-01-15 14:36 ` Jakub Kicinski [this message]
2025-01-15 14:53 ` Jamal Hadi Salim
2025-01-15 15:51 ` Jakub Kicinski
2025-01-15 20:39 ` Jamal Hadi Salim
2025-01-16 1:33 ` Jakub Kicinski
2025-01-16 13:34 ` Jamal Hadi Salim
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=20250115063655.21be5c74@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=nnamrec@gmail.com \
--cc=security@kernel.org \
--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.