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: <CAA0ESdojQfya_PTo=hJeCX1U6ReJ8L2sBra9wUW4LfGwzLYW_A@mail.gmail.com>
Date:   Tue, 4 Jul 2017 12:12:47 -0500
From:   Robert McCabe <robert.mccabe@...kwellcollins.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] net sched: Added the TC_LINKLAYER_CUSTOM linklayer type

>>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 )

So I opted to make the corresponding change to the pkt_sched.h file in
the kernel.
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