netdev - Re: [iproute PATCH] libnetlink: Double the dump buffer size

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]

Message-Id: <20160305005600.6D45B6020E@mail.nwl.cc>
Date:	Sat, 5 Mar 2016 01:57:46 +0100
From:	Phil Sutter <phil@....cc>
To:	Stephen Hemminger <shemming@...cade.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [iproute PATCH] libnetlink: Double the dump buffer size

On Fri, Mar 04, 2016 at 03:35:53PM -0800, Stephen Hemminger wrote:
> On Fri, 4 Mar 2016 18:57:28 +0000
> Phil Sutter <phil@....cc> wrote:
> 
> > There have been reports about 'ip addr' printing "Message truncated" on
> > systems with large numbers of VFs. Although I haven't been able to get
> > my hands on hardware suitable to reproduce this, increasing the dump
> > buffer has been reported to resolve the issue. For want of a better
> > idea, just double the buffer size to 32k.
> > 
> > Feels like this opportunistic buffer size selection is rather
> > workarounding a design flaw in libnetlink or maybe even the netlink
> > protocol itself.
> > 
> > Signed-off-by: Phil Sutter <phil@....cc>
> > ---
> >  lib/libnetlink.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/libnetlink.c b/lib/libnetlink.c
> > index d6b5fd3e8a493..245c4ca216753 100644
> > --- a/lib/libnetlink.c
> > +++ b/lib/libnetlink.c
> > @@ -223,7 +223,7 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
> >  		.msg_iov = &iov,
> >  		.msg_iovlen = 1,
> >  	};
> > -	char buf[16384];
> > +	char buf[32768];
> >  	int dump_intr = 0;
> >  
> >  	iov.iov_base = buf;
> 
> I thought this was addressed in kernel by making the VF info optional.
> The netlink protocol is showing some strain, this is one of them.

Oh, thanks for pointing this out. Testing was done with a RHEL7 kernel
only, so I can't tell whether this still applies to upstream.

What do you mean with 'optional'? Doesn't this imply that it is still
possible to request a dump which will exhaust buffer space in a single
message? Maybe just point me at the relevant kernel commit and I'll go
figure myself.

Thanks, Phil