NLM_F_MATCH? #2

New Issue

2023-02-14T03:30:23Z

dtaht commented

2023-02-14 03:30:23 +00:00

(Migrated from github.com)

I keep wondering if it was possible to dump just the queue tree for

tc -s qdisc show dev whatever parent 5:1.

Presently your code, and tc, dump the whole thing, then parse it out... There must be a better way....

I keep wondering if it was possible to dump just the queue tree for tc -s qdisc show dev whatever parent 5:1. Presently your code, and tc, dump the whole thing, then parse it out... There must be a better way....

Lochnair commented

2023-02-19 22:56:49 +00:00

(Migrated from github.com)

Yeah I used strace on tc to help me figure out what I needed to send to get what I needed,
so the similar behavior is to be expected.

Although looking at a tc show strace again, if I call tc qdisc show dev eth0, tc will set the ifindex in the request,
but the kernel will still return all qdiscs. Tried to set NLM_F_MATCH in my code to test as well, but it didn't make any difference

Yeah I used strace on tc to help me figure out what I needed to send to get what I needed, so the similar behavior is to be expected. Although looking at a tc show strace again, if I call `tc qdisc show dev eth0`, tc will set the ifindex in the request, but the kernel will still return all qdiscs. Tried to set NLM_F_MATCH in my code to test as well, but it didn't make any difference

dtaht commented

2023-02-20 22:43:43 +00:00

(Migrated from github.com)

yea. Seems like a bug to me...

dtaht commented

2023-02-20 23:29:28 +00:00

(Migrated from github.com)

maybe if it set the ifindex separately?

Lochnair commented

2023-02-22 16:21:29 +00:00

(Migrated from github.com)

not sure. guess I'll have to dig into the kernel a bit to see how this is supposed to work

dtaht commented

2023-02-22 16:27:50 +00:00

(Migrated from github.com)

I'm rooting for you. netlink makes my head hurt. So does rust.

Lochnair commented

2023-02-22 16:51:19 +00:00

(Migrated from github.com)

Mine too. Albeit with Rust there's at least usually someone else that's run into the same problem,
with Netlink you're often on your own

At a first glance I should avoid setting NLM_F_DUMP, that will cause it to dump all qdiscs,
but just having NLM_F_REQUEST and NLM_F_MATCH flags set still causes a full dump cue confusion

Will need to dig some more

Mine too. Albeit with Rust there's at least usually someone else that's run into the same problem, with Netlink you're often on your own At a first glance I should avoid setting NLM_F_DUMP, that will cause it to dump all qdiscs, but just having NLM_F_REQUEST and NLM_F_MATCH flags set still causes a full dump *cue confusion* Will need to dig some more

dtaht commented

2023-02-22 22:24:01 +00:00

(Migrated from github.com)

Yea. Even with ifindex directly specified?

Moving to containers would fix some of my problem in LibreQos, but introduce others.

Yea. Even with ifindex directly specified? Moving to containers would fix some of my problem in LibreQos, but introduce others.

Lochnair commented

2023-02-24 14:11:28 +00:00

(Migrated from github.com)

Yep.

Some printk's later, I at least understand what's going on.
NLM_F_REQUEST and NLM_F_MATCH becomes 0x201.

So in this check: https://github.com/torvalds/linux/blob/master/net/core/rtnetlink.c#L6098

if (kind == RTNL_KIND_GET && (nlh->nlmsg_flags & NLM_F_DUMP)) {

nlh->nlmsg_flags & NLM_F_DUMP will evaluate to 0x1 and pass.

Here: https://www.kernel.org/doc/html/latest/userspace-api/netlink/intro.html#other-request-type-specific-flags, it says that

For GET - NLM_F_ROOT and NLM_F_MATCH are combined into NLM_F_DUMP, and not used separately. NLM_F_ATOMIC is never used.
I originally thought that was specific to generic netlink, and didn't apply to rtnetlink, but evidently not.

However running with only NLM_F_REQUEST gives me an Unknown error -2 (os error -2) error message.
I can see from the printk's I added that it now ends up in tc_get_qdisc, but is unhappy.

That error should be coming from here, indicating that it can't find the qdisc. I don't set the qdisc handle in the request, so I believe it bails early here in qdisc_lookup: https://github.com/torvalds/linux/blob/master/net/sched/sch_api.c#L304

That being the case, I'm not sure if there's actually a reasonable way to do this without dumping the whole thing

Yep. Some printk's later, I at least understand what's going on. NLM_F_REQUEST and NLM_F_MATCH becomes 0x201. So in this check: https://github.com/torvalds/linux/blob/master/net/core/rtnetlink.c#L6098 ```c if (kind == RTNL_KIND_GET && (nlh->nlmsg_flags & NLM_F_DUMP)) { ``` nlh->nlmsg_flags & NLM_F_DUMP will evaluate to 0x1 and pass. Here: https://www.kernel.org/doc/html/latest/userspace-api/netlink/intro.html#other-request-type-specific-flags, it says that > For GET - NLM_F_ROOT and NLM_F_MATCH are combined into NLM_F_DUMP, and not used separately. NLM_F_ATOMIC is never used. I originally thought that was specific to generic netlink, and didn't apply to rtnetlink, but evidently not. However running with only NLM_F_REQUEST gives me an `Unknown error -2 (os error -2)` error message. I can see from the printk's I added that it now ends up in tc_get_qdisc, but is unhappy. That error should be coming from [here](https://github.com/torvalds/linux/blob/master/net/sched/sch_api.c#L1491), indicating that it can't find the qdisc. I don't set the qdisc handle in the request, so I believe it bails early here in qdisc_lookup: https://github.com/torvalds/linux/blob/master/net/sched/sch_api.c#L304 That being the case, I'm not sure if there's actually a reasonable way to do this without dumping the whole thing

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Lochnair-Labs/sqm-autorate-rust#2