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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 21 Nov 2016 21:31:59 +0800
From:   Gao Feng <fgao@...ai8.com>
To:     Florian Westphal <fw@...len.de>
Cc:     mareklindner@...mailbox.ch,
        Simon Wunderlich <sw@...onwunderlich.de>, a@...table.cc,
        "David S. Miller" <davem@...emloft.net>,
        b.a.t.m.a.n@...ts.open-mesh.org,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net v2 1/1] net: batman-adv: Treat NET_XMIT_CN as transmit successfully

Hi Florian,


On Mon, Nov 21, 2016 at 9:24 PM, Gao Feng <fgao@...ai8.com> wrote:
> Hi Florian,
>
> On Mon, Nov 21, 2016 at 7:09 PM, Florian Westphal <fw@...len.de> wrote:
>> fgao@...ai8.com <fgao@...ai8.com> wrote:
>>> From: Gao Feng <fgao@...ai8.com>
>>>
>>> The tc could return NET_XMIT_CN as one congestion notification, but
>>> it does not mean the packet is lost. Other modules like ipvlan,
>>> macvlan, and others treat NET_XMIT_CN as success too.
>>>
>>> So batman-adv should add the NET_XMIT_CN check.
>>
>> "The tc could return NET_XMIT_CN as one congestion notification, but
>> it means another packet got dropped. Other modules like batman do not
>> treat NET_XMIT_CN as success, so modules like ipvlan, macvlan, ..
>> should ignore it as well."

I didn't get you in the last email

You mean the NET_XMIT_CN should be treated as one error?
But the comment of NET_XMIT_CN says "It indicates that the device will
soon be dropping packets, or already drops some packets of the same
priority". It is not sure another packet is dropped.

BTW, the macro "net_xmit_eval" does not treat NET_XMIT_CN as one error.

Regards
Feng

>>
>> What I am asking is:
>> Are you sure adding NET_XMIT_CN handling everywhere is the right way to
>> resolve the inconsistency?
>
> Or create one new macro to handle this case like net_xmit_eval.
> For example,
> #define net_xmit_ok(ret)    (ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)
>
> Is it ok? But it should be done for net-next.
>
> Best Regards
> Feng


Powered by blists - more mailing lists