netdev - Re: [PATCH iproute2-next] devlink: Increase column size for larger shared buffers

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, 23 Apr 2019 20:27:36 -0600
From:   David Ahern <dsahern@...il.com>
To:     Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org
Cc:     dsahern@...il.com, jiri@...lanox.com, alexanderk@...lanox.com,
        mlxsw@...lanox.com, Ido Schimmel <idosch@...lanox.com>
Subject: Re: [PATCH iproute2-next] devlink: Increase column size for larger
 shared buffers

On 4/23/19 12:36 AM, Ido Schimmel wrote:
> From: Ido Schimmel <idosch@...lanox.com>
> 
> With current number of spaces the output is mangled if the shared buffer
> is congested.
> 
> Before:
> 
> # devlink sb occupancy show swp32
> swp32:
>   pool: 0:    10220112/10222128 1:          0/0       2:          0/0       3:          0/0
>         4:    10221120/10222128 5:          0/0       6:          0/0       7:          0/0
>         8:      41328/46368   9:          0/0      10:          0/0
>   itc:  0(0): 10220112/10222128 1(0):       0/0       2(0):       0/0       3(0):       0/0
>         4(0):       0/0       5(0):       0/0       6(0):       0/0       7(0):       0/0
>   etc:  0(4): 10221120/10222128 1(4):       0/0       2(4):       0/0       3(4):       0/0
>         4(4):       0/0       5(4):       0/0       6(4):       0/0       7(4):       0/0
>         8(8):   43344/46368   9(8):       0/0      10(8):       0/0      11(8):       0/0
>        12(8):       0/0      13(8):       0/0      14(8):       0/0      15(8):       0/0
> 
> After:
> 
> # devlink sb occupancy show swp32
> swp32:
>   pool: 0:    10220112/10222128 1:          0/0         2:          0/0         3:          0/0
>         4:    10221120/10222128 5:          0/0         6:          0/0         7:          0/0
>         8:      41328/46368     9:          0/0        10:          0/0
>   itc:  0(0): 10220112/10222128 1(0):       0/0         2(0):       0/0         3(0):       0/0
>         4(0):       0/0         5(0):       0/0         6(0):       0/0         7(0):       0/0
>   etc:  0(4): 10221120/10222128 1(4):       0/0         2(4):       0/0         3(4):       0/0
>         4(4):       0/0         5(4):       0/0         6(4):       0/0         7(4):       0/0
>         8(8):   43344/46368     9(8):       0/0        10(8):       0/0        11(8):       0/0
>        12(8):       0/0        13(8):       0/0        14(8):       0/0        15(8):       0/0
> 
> Signed-off-by: Ido Schimmel <idosch@...lanox.com>
> Reported-by: Alex Kushnarov <alexanderk@...lanox.com>
> Tested-by: Alex Kushnarov <alexanderk@...lanox.com>
> ---
>  devlink/devlink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/devlink/devlink.c b/devlink/devlink.c
> index dc6e73fec20c..1306c4c126ad 100644
> --- a/devlink/devlink.c
> +++ b/devlink/devlink.c
> @@ -3422,7 +3422,7 @@ static void pr_out_occ_show_item_list(const char *label, struct list_head *list,
>  				  occ_item->bound_pool_index);
>  		else
>  			pr_out_sp(7, "%2u:", occ_item->index);
> -		pr_out_sp(15, "%7u/%u", occ_item->cur, occ_item->max);
> +		pr_out_sp(17, "%7u/%u", occ_item->cur, occ_item->max);
>  		if (i++ % 4 == 0)
>  			pr_out("\n");
>  	}
> 

2 more columns fixes the current problem, what assurances are there that
the occupancy levels and max won't reach 100 million in the next few years?