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:   Wed, 5 Jul 2017 09:01:33 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Robert McCabe <robert.mccabe@...kwellcollins.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] net sched: Added the TC_LINKLAYER_CUSTOM linklayer
 type

Tue, Jul 04, 2017 at 07:12:47PM CEST, robert.mccabe@...kwellcollins.com wrote:
>>>Even so, the kernel patch you sent does not make any sense. Introduces
>>>TC_LINKLAYER_CUSTOM but does not use it.
>
>I needed to add this to the tc_link_layer enum in my iproute2 patch
>(https://patchwork.ozlabs.org/patch/784165/)
>
>enum tc_link_layer {
>      TC_LINKLAYER_UNAWARE, /* Indicate unaware old iproute2 util */
>      TC_LINKLAYER_ETHERNET,
>      TC_LINKLAYER_ATM,
>   + TC_LINKLAYER_CUSTOM,
> };
>
>I originally wasn't aware that this file was shared with the kernel --
>my original patch received the comment from Eric Dumazet
>
>    You can not do this : This file is coming from the kernel
>     ( include/uapi/linux/pkt_sched.h )

Correct.


>
>So I opted to make the corresponding change to the pkt_sched.h file in
>the kernel.

I'm not sure how should I put this, but you are adding enum value and
you are not using it in kernel! That is wrong. Whenever you add new
value to UAPI, it has to have a point. Please see:

$ git grep TC_LINKLAYER_


>But looking at it further, I am confused as to why this tc_link_layer even needs
>to exist in the kernel anyway,  It is only used in net/sched for calculating the
>size (via stab) and rate (via rtab) translations; however, these
>translations are
>already specified with in the form of the stab and rtab themselves (these are
>calculated in userspace).
>
>I think -- in a perfect world -- the tc_link_layer (and the associated
>tc_ratespec.linklayer and  tc_sizespec.linklayer) should be removed
>from the kernel,
>but I'm not sure of the compatibility implications of this ...
>Do you have any suggestions?
>
>>
>> Also, please make you email working. Says to me:
>>
>> ** Address not found **
>>
>> Your message wasn't delivered to McCabe@...kwellcollins.com because the address couldn't be found. Check for typos or unnecessary spaces and try again.
>>
>> This is annoying.
>
>I think I fixed it -- was mis-configuration in my .gitconfig (sorry,
>I'm still new at this).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ