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, 18 May 2016 20:47:47 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Ahern <dsa@...ulusnetworks.com>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>,
	Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	netdev-owner@...r.kernel.org, David Miller <davem@...emloft.net>,
	Maciej Żenczykowski <zenczykowski@...il.com>,
	Tom Herbert <tom@...bertland.com>
Subject: Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for
 SOCK_DESTROY

On Wed, 2016-05-18 at 21:02 -0600, David Ahern wrote:
> On 5/18/16 6:55 PM, Lorenzo Colitti wrote:
> > On Wed, May 18, 2016 at 3:35 AM, <subashab@...eaurora.org> wrote:
> >> Would it be acceptable to have a separate column which displays the result of the sock destroy operation per socket.
> >> State    ... Killed
> >> ESTAB         Y
> >> TIME_WAIT     N
> >
> > Fine by me, but... what problem are we trying to address? People who
> > compile their own kernels and don't turn CONFIG_INET_DIAG_DESTROY, and
> > then are confused why it doesn't work? Seems like we could fix that by
> > turning CONFIG_INET_DIAG_DESTROY on by default. CCing the people who
> > commented on the original SOCK_DESTROY patch to see if they have
> > opinions.
> 
> The problem is proper feedback to a user. If the kernel supports an 
> action but the action is not enabled the user should get some message to 
> that fact. Doing nothing and exiting 0 is just wrong.

So, lets say the filter found 123456 sockets matching the filter, and
12345 could be killed

What would be exit status of ss command ?

In this case, there is no black/white answer.

It looks like you have specific needs, you should probably add an option
to ss to have a specific behavior.

But saying current behavior is 'wrong' is subjective.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ