From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754694AbcBHDfS (ORCPT ); Sun, 7 Feb 2016 22:35:18 -0500 Received: from mail-wm0-f43.google.com ([74.125.82.43]:35708 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751414AbcBHDfO (ORCPT ); Sun, 7 Feb 2016 22:35:14 -0500 Message-ID: <1454902502.7627.360.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code From: Eric Dumazet To: Rainer Weikusat Cc: 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 Date: Sun, 07 Feb 2016 19:35:02 -0800 In-Reply-To: <87io20upk9.fsf@doppelsaurus.mobileactivedefense.com> 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> <87io20upk9.fsf@doppelsaurus.mobileactivedefense.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2016-02-07 at 22:24 +0000, Rainer Weikusat wrote: > 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). This is exactly the needed information for stable teams. Goal is here is not to blame someone (you, me ... it does not matter) , but give to stable teams the point the problem showed up. See the 'Fixes' tag as a time saver for people like me. It is incredibly useful when hutting bugs, because each commit can easily point to the 'bug origin'. Having spent time lately in af_unix code insanity, I really can tell. At the time someone fixes a bug, he/she has a clear view of what is happening, but months later, he/she often has to start again the commits analysis. Thanks a lot.