From: Rainer Weikusat <rweikusat@mobileactivedefense•com>
To: David Laight <David.Laight@ACULAB•COM>
Cc: "'Eric Dumazet'" <eric.dumazet@gmail•com>,
David Miller <davem@davemloft•net>,
netdev <netdev@vger•kernel.org>
Subject: Re: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR
Date: Wed, 26 Mar 2014 15:13:30 +0000 [thread overview]
Message-ID: <87zjkd802t.fsf@sable.mobileactivedefense.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6E9790@AcuExch.aculab.com> (David Laight's message of "Wed, 26 Mar 2014 15:00:27 +0000")
David Laight <David.Laight@ACULAB•COM> writes:
> From: Eric Dumazet
>> From: Eric Dumazet <edumazet@google•com>
>>
>> Some applications didn't expect recvmsg() on a non blocking socket
>> could return -EINTR. This possibility was added as a side effect
>> of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
>> unix recv routines").
>>
>> To hit this bug, you need to be a bit unlucky, as the u->readlock
>> mutex is usually held for very small periods.
>
> The commit message for b3ca9b02b00704 looks very strange.
> Maybe something else is wrong.
>
> If we assume that u->readlock is only held for a short period
> why should it matter than the kernel decided to give the
> signal to that thread?
(This is from memory) If there's a thread blocked in recv and another
blocked on the lock and the kernel selects the thread blocked on the lock
for handling the signal, the signal won't be handled until some data is
received on the socket, ie, possibly never.
next prev parent reply other threads:[~2014-03-26 15:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 1:42 [PATCH] net: unix: non blocking recvmsg() should not return -EINTR Eric Dumazet
2014-03-26 13:17 ` Rainer Weikusat
2014-03-26 13:57 ` Rainer Weikusat
2014-03-26 14:09 ` Eric Dumazet
2014-03-26 14:25 ` Rainer Weikusat
2014-03-26 15:00 ` David Laight
2014-03-26 15:13 ` Rainer Weikusat [this message]
2014-03-26 15:25 ` Eric Dumazet
2014-03-26 15:33 ` Eric Dumazet
2014-03-26 19:46 ` Rainer Weikusat
2014-03-26 21:04 ` Rainer Weikusat
2014-03-27 9:36 ` David Laight
2014-03-27 12:40 ` Rainer Weikusat
2014-03-27 12:49 ` Jamal Hadi Salim
2014-03-27 13:02 ` Rainer Weikusat
2014-03-27 12:53 ` David Laight
2014-03-27 13:29 ` Rainer Weikusat
2014-03-26 21:05 ` David Miller
2014-03-26 21:21 ` Rainer Weikusat
2014-03-26 21:44 ` Eric Dumazet
2014-03-26 22:06 ` Rainer Weikusat
2014-03-26 22:35 ` Eric Dumazet
2014-03-26 22:51 ` Rainer Weikusat
2014-03-26 22:58 ` Eric Dumazet
2014-03-28 20:35 ` Rainer Weikusat
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=87zjkd802t.fsf@sable.mobileactivedefense.com \
--to=rweikusat@mobileactivedefense$(echo .)com \
--cc=David.Laight@ACULAB$(echo .)COM \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox