From: Johannes Berg <johannes@sipsolutions.net>
To: David Woodhouse <dwmw2@infradead.org>
Cc: David Miller <davem@davemloft.net>,
torvalds@linux-foundation.org, marcel@holtmann.org,
sfeldma@gmail.com, netdev@vger.kernel.org, teg@jklm.no
Subject: Re: Problem with patch "make nlmsg_end() and genlmsg_end() void"
Date: Wed, 08 Apr 2015 15:08:02 +0200 [thread overview]
Message-ID: <1428498482.2809.10.camel@sipsolutions.net> (raw)
In-Reply-To: <1428494602.9010.11.camel@infradead.org>
On Wed, 2015-04-08 at 13:03 +0100, David Woodhouse wrote:
> I'm not sure if this is entirely fixed. In Fedora 22 (4.0.0-rc5-git4)
> I'm occasionally seeing glibc deadlock in __check_pf() on a netlink
> recvmsg(), here:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/check_pf.c;h=162606d7;hb=glibc-2.21#l166
>
> As I understand it, this shouldn't happen. Even if messages are
> dropped (which surely shouldn't happen as often as I'm seeing this),
> glibc should get ENOBUFS from the recvmsg() call.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1209433
>
> I haven't bisected and proved that it *was* this commit which
> introduced the problem, as it only happens after a day or two of
> running Evolution and I haven't managed to trigger it more reliably.
I don't see the connection to this change.
The issue with my patch was that some code for NLM_F_DUMP would have
this pattern:
int fill_function(...)
{
...
return nlmsg_end(...);
}
loop (...) {
if (fill_function() <= 0)
break; /* continue in next dump */
}
and that all had to be converted to be just "< 0" now.
Additionally, the failure mode of this was the process running out of
memory due to receiving the same results over and over again - does that
happen for you? It seems it was stuck in recvmsg(), but that may just be
a side effect of happening to interrupt at that point?
johannes
next prev parent reply other threads:[~2015-04-08 13:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-18 11:44 Problem with patch "make nlmsg_end() and genlmsg_end() void" Marcel Holtmann
2015-01-18 23:44 ` Marcel Holtmann
2015-01-19 1:53 ` Scott Feldman
2015-01-19 2:10 ` Marcel Holtmann
2015-01-19 4:37 ` David Miller
2015-01-19 9:31 ` Scott Feldman
2015-04-08 12:03 ` David Woodhouse
2015-04-08 13:08 ` Johannes Berg [this message]
2015-04-08 14:12 ` David Woodhouse
2015-04-20 14:30 ` David Woodhouse
2015-06-09 13:34 ` David Woodhouse
2015-06-10 0:49 ` Eric Dumazet
2015-06-11 0:31 ` David Woodhouse
2015-06-11 7:16 ` David Miller
2015-06-11 22:03 ` David Woodhouse
2015-06-18 6:38 ` David Woodhouse
2015-01-19 8:53 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1428498482.2809.10.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@gmail.com \
--cc=teg@jklm.no \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.