netdev - Re: [RFC PATCH] qos: Limit a filter's priority to a 16 bit value

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20090501.191854.218400455.davem@davemloft.net>
Date:	Fri, 01 May 2009 19:18:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	robert.w.love@...el.com
Cc:	hadi@...erus.ca, netdev@...r.kernel.org,
	jeffrey.t.kirsher@...el.com
Subject: Re: [RFC PATCH] qos: Limit a filter's priority to a 16 bit value

From: "Love, Robert W" <robert.w.love@...el.com>
Date: Fri, 1 May 2009 19:10:36 -0700

> jamal wrote:
>> On Fri, 2009-05-01 at 16:30 -0700, Love, Robert W wrote:
>> 
>>> I should be more clear by saying that this should only
>>> fail with filter priorities assigned by the kernel.
>>> I think if the user passes down the priority when
>>> creating the filter it should always be 16bits and it's fine.
>>> 
>>> However, when the kernel is assigning priorities, the
>>> first assigned priority for a filter is 0xC0000000,
>>> the second is "the lowest priority - 1" so 0xBFFFFFFF.
>>> 
>>> It will assign this value in tcf_auto_prio() which will
>>> directly assign the 32bit value to to tp->prio with-
>>> 
>>> tp->prio = nprio ? : tcf_auto_prio(*back);
>> 
>> I think the above should read:
>> tp->prio = nprio ? : TC_H_MAJ(tcf_auto_prio(*back));
>> 
> I think you might be right, although, I don't see why
> we use a u32 when we're always storing a u16.

That's irrelevant.

You've essentially found what turned out to be a one-line bug, and
fixed it by changing and rearranging a lot of things.

So could I just get that one-liner fix patch from somebody?

Thanks :-)

Meanwhile, on the issue of how this value is stored, perhaps someone
intended to support "classful" filter priorities, just as we support
classful qdiscs.  Or perhaps someone had the idea to store the
protocol in there as well, who knows :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html