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] [day] [month] [year] [list]
Date:   Wed, 1 Nov 2017 15:15:07 +0300
From:   Kirill Smelkov <kirr@...edi.com>
To:     Francois Romieu <romieu@...zoreil.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: linux-next: Signed-off-by missing for commit in the net-next tree

Francois,

On Wed, Nov 01, 2017 at 11:55:24AM +0100, Francois Romieu wrote:
> Kirill Smelkov <kirr@...edi.com> :
> [...]
> > I was keeping you in To and Cc all the time but got no reply at all since my
> > first posting from ~ 1 month ago.
> 
> I thought it was longer than that. Sorry for the frustrating excess delay.
> 
> As Eric already said there is no problem and I am perfectly fine with
> the current attribution of this code.

Thanks for feedback.

> Use of errno.h::ELNRNG is really unusual but it's a different topic.

I wanted the error returned due to internal inconsistency to be different
from the error returned when there is error in provided parameters from
ethtool.

Your original patch was returning EINVAL for both cases which made it
hard to understand what is going on when the kernel was refusing to
accept something from user.

That's why I used ELNRNG (link number out of range) for situation when
lookup of timings vector by current link speed failed. A bit unusual,
yes, but this was the closest to the situation after studying `errno -l`
output.

Hope this clarifies a bit.

Please feel free to suggest a change here,
Kirill

Powered by blists - more mailing lists