netdev - Re: [PATCH -next 0/5] replace skb tc_verd member with 3 dedicated bit flags

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]

Date:	Tue, 05 May 2015 07:58:40 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Florian Westphal <fw@...len.de>
CC:	netdev@...r.kernel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH -next 0/5] replace skb tc_verd member with 3 dedicated
 bit flags

On 05/05/15 07:47, Florian Westphal wrote:
> Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> Initial feedback on the series:
>> - Can you keep the macros around? eg SET_TC_NCLS is more readable
>> than skb->tc_nocls = 1 also hides the bit details.
>
> I beg to differ, sorry :-/
>
> We use blah:1 everywhere else in sk_buff, only tc is different and
> its not obvious (to me) how tc_verd is being used and for what.
>
> Or are you saying that should redefine SET_TC_NCLS to something like
>
> #define SET_TC_NCLS(skb)	(skb)->tc_nocls = 1
>
> ?
>

It is borderline questionable for 1 bit but for consistency i
suggest you do what was there before. I pointed to nocls but
i meant the comment generically because previous code you are
changing intended to use the macros.
In any case I will leave it up to you.

>> I think the ones that are no longer needed should just be deleted
>> as opposed to what you and Alexei did earlier.
>
> Fair enough, I can do that.

Perhaps even as a first patch that move would be useful.

>
>> - We need two bits for the location (ingress, egress, from stack)
>> from stack being 0 i.e when it is not set implicitly it is from the
>> host stack then we can check for ingress or egress when we choose.
>
> Hmm, are you sure?  How is that used?
>

As example, when something like
if (!(at & AT_EGRESS))
implies it is either from ingress or the stack.
It does not only from ingress.

> In fact ifb will BUG() if neither AT_INGRESS or AT_EGRESS was set
> in G_TC_FROM().
>

Yes, because you cant send directly from the stack host to ifb. You
can only redirect to it. If we ever end there from the host we should
bug()

cheers,
jamal
--
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