[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87io20upk9.fsf@doppelsaurus.mobileactivedefense.com>
Date: Sun, 07 Feb 2016 22:24:22 +0000
From: Rainer Weikusat <rweikusat@...ileactivedefense.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Rainer Weikusat <rweikusat@...ileactivedefense.com>,
davem@...emloft.net, hannes@...essinduktion.org,
edumazet@...gle.com, dhowells@...hat.com, ying.xue@...driver.com,
"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
"stable\@vger.kernel.org" <stable@...r.kernel.org>,
Joseph Salisbury <joseph.salisbury@...onical.com>
Subject: Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code
Rainer Weikusat <rw@...pelsaurus.mobileactivedefense.com> writes:
[...]
> The start uses that to record an error which might need to be
> reported, the return statement uses it to indicate that an error has
> occurred. Hence, some kind of in-between translation must occur. The
> mutex_lock_interruptible happened to do that but that was never it's
> intended purpose.
Additional information: The 'trick' of using recvmsg w/o a receive
buffer in order to retrieve control messages in fact wouldn't have
worked with the unix_stream_recvmsg prior to introduction of the
interruptible lock as that (judging from the git source) would have
triggered all the same issues,
- -EOPNOTSUP if a msg was available
- -EAGAIN if the code had to wait
- not receiving the creds if the -EAGAIN hadn't happened because
of the continue (that's the other patch)
IOW, that's a feature inadvertendly added by an otherwise useless code
change (mea culpa).
Powered by blists - more mailing lists