On Thu, May 19, 2016 at 11:06 PM, David Ahern wrote:
> got it. Google does not care about users; don't un-suppress failures.
The users I was trying to care about are the ones that have correctly
configured kernels. It did not seem useful to those users to litter
the dumps with error messages sayi
On Thu, 2016-05-19 at 08:06 -0600, David Ahern wrote:
> On 5/18/16 10:12 PM, Eric Dumazet wrote:
> > On Wed, 2016-05-18 at 22:05 -0600, David Ahern wrote:
> >
> >> You think it is ok to send a request to the kernel, the kernel says "I
> >> can't do it" and the command says nothing to the user? That
On 5/18/16 10:12 PM, Eric Dumazet wrote:
On Wed, 2016-05-18 at 22:05 -0600, David Ahern wrote:
You think it is ok to send a request to the kernel, the kernel says "I
can't do it" and the command says nothing to the user? That is current
behavior. How on Earth is that acceptable?
I don't know.
On Wed, 2016-05-18 at 22:05 -0600, David Ahern wrote:
> You think it is ok to send a request to the kernel, the kernel says "I
> can't do it" and the command says nothing to the user? That is current
> behavior. How on Earth is that acceptable?
I don't know. Tell me what is acceptable on a 'dum
On 5/18/16 9:47 PM, Eric Dumazet wrote:
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, wrote:
Would it be acceptable to have a separate column which displays the result of
the sock destroy operation per socket
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, wrote:
> >> Would it be acceptable to have a separate column which displays the result
> >> of the sock destroy operation per socket.
> >> State... Killed
>
On 5/18/16 6:55 PM, Lorenzo Colitti wrote:
On Wed, May 18, 2016 at 3:35 AM, 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 t
On Wed, May 18, 2016 at 3:35 AM, 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
On Tue, 17 May 2016 12:35:53 -0600
subas...@codeaurora.org wrote:
> On 2016-05-16 20:29, Lorenzo Colitti wrote:
> > On Tue, May 17, 2016 at 11:24 AM, David Ahern
> > wrote:
> >> As I mentioned we can print the unsupported once or per socket matched
> >> and
> >> with the socket params. e.g.,
>
On 2016-05-16 20:29, Lorenzo Colitti wrote:
On Tue, May 17, 2016 at 11:24 AM, David Ahern
wrote:
As I mentioned we can print the unsupported once or per socket matched
and
with the socket params. e.g.,
+ } else if (errno == EOPNOTSUPP) {
+ printf("Operation
On Tue, May 17, 2016 at 11:24 AM, David Ahern wrote:
> As I mentioned we can print the unsupported once or per socket matched and
> with the socket params. e.g.,
>
> + } else if (errno == EOPNOTSUPP) {
> + printf("Operation not supported for:\n");
> +
On 5/16/16 8:04 PM, Lorenzo Colitti wrote:
Given that the filter can specify a number of sockets, some of which
can and some of which can't be closed, and that whether a given socket
can be closed is only known at the time we attempt to close it, there
is a choice between two bad outcomes:
1. Us
On Tue, May 17, 2016 at 10:52 AM, David Ahern wrote:
> code is not setup to handle that. Only option seems to be at least dump an
> error message, but the message can not relate any of the specifics about the
> filter. So something like this though it dumps the message per socket
> matched by the
On 5/16/16 7:20 PM, Lorenzo Colitti wrote:
On Tue, May 17, 2016 at 10:14 AM, David Ahern wrote:
For example, EOPNOTSUPP can just mean "this socket can't be closed
because it's a timewait or NEW_SYN_RECV socket". In hindsight it might
have been better to return EBADFD in those cases, but that s
On Tue, May 17, 2016 at 10:14 AM, David Ahern wrote:
>>
>> For example, EOPNOTSUPP can just mean "this socket can't be closed
>> because it's a timewait or NEW_SYN_RECV socket". In hindsight it might
>> have been better to return EBADFD in those cases, but that still
>> doesn't solve the UI proble
On 5/16/16 7:01 PM, Lorenzo Colitti wrote:
On Tue, May 17, 2016 at 8:53 AM, David Ahern wrote:
@@ -2264,7 +2264,7 @@ static int show_one_inet_sock(const struct sockaddr_nl
*addr,
if (!(diag_arg->f->families & (1 << r->idiag_family)))
return 0;
if (diag_arg->f->k
On Tue, May 17, 2016 at 8:53 AM, David Ahern wrote:
> @@ -2264,7 +2264,7 @@ static int show_one_inet_sock(const struct sockaddr_nl
> *addr,
> if (!(diag_arg->f->families & (1 << r->idiag_family)))
> return 0;
> if (diag_arg->f->kill && kill_inet_sock(h, arg) != 0)
Silent failures are not friendly to the user. If a command is
not supported tell the user about it.
Signed-off-by: David Ahern
---
misc/ss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/misc/ss.c b/misc/ss.c
index 23fff19d9199..bd7214c85938 100644
--- a/misc/ss.c
+++ b/mis
18 matches
Mail list logo
