netdev - Re: [PATCH net-next v1 6/6] doc/netlink/specs: Add a spec for tc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 04 Dec 2023 22:38:23 +0000
From: Donald Hunter <donald.hunter@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org,  "David S. Miller" <davem@...emloft.net>,  Eric
 Dumazet <edumazet@...gle.com>,  Paolo Abeni <pabeni@...hat.com>,  Jonathan
 Corbet <corbet@....net>,  linux-doc@...r.kernel.org,  Jacob Keller
 <jacob.e.keller@...el.com>,  donald.hunter@...hat.com
Subject: Re: [PATCH net-next v1 6/6] doc/netlink/specs: Add a spec for tc

Jakub Kicinski <kuba@...nel.org> writes:

> On Mon, 04 Dec 2023 16:27:24 +0000 Donald Hunter wrote:
>> > Ugh. Meaning the selector is at a "previous" level of nesting?
>>
>> That's right. I wonder if we should use a relative syntax like "../kind"
>> for the selector. Will either need to pass the known attrs to nest
>> parsing, or pass a resolver instead?
>
> ../kind is my first thought, too.
>
> But on reflection I reckon it may make the codegen and Python parser
> quite a bit more complex. :S

That was my main concern with it too.

Another thought I had was to explicitly mark attrs that get used as
selector keys, but I don't think that actually buys us anything.

> Passing in known selector attrs to nests sounds good. Assuming we never
> have to do something like: "../other-nest/attr".
> Or perhaps in that case we can support passing in nested attrs, just
> not backtracking? Backtracking is the hard part, really. Yeah, that
> sounds simplest, at least at the "thought exercise level" :)
>
> What would "resolver" look like?

I was thinking a resolver would be a class with a single lookup method
that internally holds attributes from the current scope and has a parent
it can delegate to. It would try to resolve e.g. "kind" in current scope
then, on failure, delegate to its parent. When recursing to decode a
submsg, create a new resolver with the current one as its parent.

If we did it this way, there'd be no need for "../kind".

> BTW how do we deal with ordering. Do we require that selector attr
> must be present in the message before the submsg? I think in practice
> is should always be the case, but we should document that.

The selector attr is de-facto present in the message before it is
needed, both at the same level and for sub messages. So, yeah, I think
we require this and agreed we should document it. I will do that in
the next revision.

>From what I have seen so far, selector attrs are at same level or at
root level, but I'm not confident that will hold true for all of the raw
families.