From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755155AbcBGWYp (ORCPT ); Sun, 7 Feb 2016 17:24:45 -0500 Received: from tiger.mobileactivedefense.com ([217.174.251.109]:39549 "EHLO tiger.mobileactivedefense.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754607AbcBGWYn (ORCPT ); Sun, 7 Feb 2016 17:24:43 -0500 From: Rainer Weikusat To: Eric Dumazet Cc: Rainer Weikusat , davem@davemloft.net, hannes@stressinduktion.org, edumazet@google.com, dhowells@redhat.com, ying.xue@windriver.com, "netdev\@vger.kernel.org" , LKML , "stable\@vger.kernel.org" , Joseph Salisbury Subject: Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code In-Reply-To: <8737t4jr99.fsf@doppelsaurus.mobileactivedefense.com> (Rainer Weikusat's message of "Sun, 07 Feb 2016 18:43:14 +0000") References: <56B4EF04.2060407@canonical.com> <87bn7ude8g.fsf@doppelsaurus.mobileactivedefense.com> <1454713398.7627.325.camel@edumazet-glaptop2.roam.corp.google.com> <8737t4jr99.fsf@doppelsaurus.mobileactivedefense.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Sun, 07 Feb 2016 22:24:22 +0000 Message-ID: <87io20upk9.fsf@doppelsaurus.mobileactivedefense.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (tiger.mobileactivedefense.com [217.174.251.109]); Sun, 07 Feb 2016 22:24:32 +0000 (GMT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rainer Weikusat 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).