netdev - Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name in seq_printf of rt6_info

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:	Tue, 27 Nov 2012 11:17:09 +0800
From:	Shan Wei <shanwei88@...il.com>
To:	Chen Gang <gang.chen@...anux.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: Fwd: Re: [PATCH] net: ipv6: change %8s to %s for rt->dst.dev->name
 in seq_printf of rt6_info_route

Chen Gang said, at 2012/11/23 11:35:
> 2) about %*s:
>  since kernel is an open system, IFNAMSIZ is belong to OS API level for outside
>    it has effect both on individual kernel modules and user mode system call
>    we need obey this rule, and %8s is not match this rule.
>    so %8s is not suitable. (and now we have to choose %16s or %s).

Your patch will change the format of /proc/net/ipv6_route.
Why we need to keep be consistent with user mode?
However user operates device name, no effect on the showing of /proc/net/ipv6_route.

> 
>  for the format of information which seq_printf output:
>    it is not belong to OS API level for outside (at least, for current case, it is true). 
>    so we need not keep 'compatible' of it, so %16s is not necessary.

Can you explain If we don't change to %s, what will happen?

> 
>  for keeping source code simple and clearly:
>    %s is better than %16s.
> 
>  so for result, we should choose %s only (neither %16s nor %8s).

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html