netdev - Re: Problem with patch "make nlmsg_end() and genlmsg

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] [day] [month] [year] [list]

Message-ID: <1434609536.4100.78.camel@infradead.org>
Date:	Thu, 18 Jun 2015 07:38:56 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	David Miller <davem@...emloft.net>,
	torvalds@...ux-foundation.org, marcel@...tmann.org,
	sfeldma@...il.com, netdev@...r.kernel.org, teg@...m.no
Subject: Re: Problem with patch "make nlmsg_end() and genlmsg_end() void"

On Thu, 2015-06-11 at 23:03 +0100, David Woodhouse wrote:
> On Thu, 2015-06-11 at 01:31 +0100, David Woodhouse wrote:
> > On Tue, 2015-06-09 at 17:49 -0700, Eric Dumazet wrote:
> > > > I've added some debugging, and it seems that when it deadlocks, 
> > > > glibc
> > > > doesn't get *any* response to its RTM_GETADDR request. I know 
> > > > we'd get
> > > > ENOBUFS is a *response* was dropped... but what about when the 
> > > > request
> > > > itself is dropped? ... 
> > > 
> > > Please check that this patch fixes your issue :
> > > 
> > > http://patchwork.ozlabs.org/patch/473041/
> > 
> > Looks likely; thanks. I'm running with that patch now. I haven't 
> > been
> > able to quickly reproduce the problem on demand, but it usually 
> > happens
> > within a day or two. So it'll be a few days at least before I call 
> > it a
> > success.
> 
> I just saw the same deadlock happen again; glibc's __check_pf() stuck
> in recvmsg() waiting for a response that never comes.
> 
> This is the Fedora 22 4.0.5 kernel with the above patch applied.

It did at least manage to survive a single night (which it often
doesn't) if I also apply a version of this patch:
https://patchwork.ozlabs.org/patch/473049/

Even on the known problematic kernels, I have been unable to reproduce
this on demand using either my own threaded getaddrinfo() test program,
or the one you posted here.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)