Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5948867ybi; Tue, 4 Jun 2019 15:26:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqwylWRdPZbPYgaHbybPdV0H6TQ0c4wCvbY+jnWgVSQc7Tzqw2xmyVkFJcJgTfvYj0TqXMW/ X-Received: by 2002:a62:6d47:: with SMTP id i68mr41767247pfc.189.1559687164000; Tue, 04 Jun 2019 15:26:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559687163; cv=none; d=google.com; s=arc-20160816; b=hYzu5gfDFhDqx1J4CNTxhvA8X7KOqKwz+YHOUlgiZ9GJtqtBids0x+KKZW01JYQzhO B7xfx3QKRQCC1zaCsbU5XCrZt8g/fmS+WdL30dkL3YUv0BbGTYZTIpWRn8XNCLuCSwnb xnhPFlKps0Ue+JA8tMrzG0gg506rJTjNyekJvyV/935TEklJapy0powA6f9phSl+k1oJ X7/d1Vna3vyGWuUcfTXFMa4KrQXUt3ErRigcZk3jQbiABnfmnmS6Cc8ln8lcD8JleZ3H bB9n6smF1Oj+Rr0eP1kfvRT06kKZzYmIIEtHehBiDSIaqdRwKbaNXZf5UbbQb1dEdq03 xIfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ufeXCyF132bQYib9hWr/cNNBFTVTTZY6AMCNTG7maXs=; b=0CIFQxeu1awl/AffUsFbT0LNeuaR57samcuRcc4gZsBDwt0+yw+yIkKLWVvl9HEFni jgbu76CvaVOIc31C7XD9dFxmKszBuVBYd5HhNgxHK2a+kFh0EoByPdLND9ToQ+0QWS1L PApAABa9sT13i5yMfO5sIo9L9g5pL7rgHefLluIr7E8o0YlEVd2mBYizch8MFZEUBv0h l+lRaeIX8m8FzoDijx5Tb9F8kX6W07LFGkHiV9Wh6unEPQJoMcWU019HLv74M9hajSQi UD12D6xgDilWHrtueha1OgWpXU2sFEsMPplieRfvVhg8OU1K9zftQh4FNu8xgbJ7Swvf 2VRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3si24741790plv.102.2019.06.04.15.25.47; Tue, 04 Jun 2019 15:26:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726454AbfFDWYm (ORCPT + 99 others); Tue, 4 Jun 2019 18:24:42 -0400 Received: from dcvr.yhbt.net ([64.71.152.64]:38310 "EHLO dcvr.yhbt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726293AbfFDWYm (ORCPT ); Tue, 4 Jun 2019 18:24:42 -0400 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 907961F462; Tue, 4 Jun 2019 22:24:41 +0000 (UTC) Date: Tue, 4 Jun 2019 22:24:41 +0000 From: Eric Wong To: Linus Torvalds Cc: Oleg Nesterov , Andrew Morton , Deepa Dinamani , Linux List Kernel Mailing , Arnd Bergmann , Davidlohr Bueso , Jens Axboe , Davidlohr Bueso , Jason Baron , linux-fsdevel , linux-aio@kvack.org, omar.kilani@gmail.com, Thomas Gleixner , stable , Al Viro , "Eric W. Biederman" , David Laight Subject: Re: [PATCH] signal: remove the wrong signal_pending() check in restore_user_sigmask() Message-ID: <20190604222441.tndh2rljrfoaytkr@dcvr> References: <20190522032144.10995-1-deepa.kernel@gmail.com> <20190529161157.GA27659@redhat.com> <20190604134117.GA29963@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote: > On Tue, Jun 4, 2019 at 6:41 AM Oleg Nesterov wrote: > > > > This is the minimal fix for stable, I'll send cleanups later. > > Ugh. I htink this is correct, but I wish we had a better and more > intuitive interface. I had the same thoughts, but am not a regular kernel hacker, so I didn't say anything earlier. > In particular, since restore_user_sigmask() basically wants to check > for "signal_pending()" anyway (to decide if the mask should be > restored by signal handling or by that function), I really get the > feeling that a lot of these patterns like > > > - restore_user_sigmask(ksig.sigmask, &sigsaved); > > - if (signal_pending(current) && !ret) > > + > > + interrupted = signal_pending(current); > > + restore_user_sigmask(ksig.sigmask, &sigsaved, interrupted); > > + if (interrupted && !ret) > > ret = -ERESTARTNOHAND; > > are wrong to begin with, and we really should aim for an interface > which says "tell me whether you completed the system call, and I'll > give you an error return if not". > > How about we make restore_user_sigmask() take two return codes: the > 'ret' we already have, and the return we would get if there is a > signal pending and w're currently returning zero. > > IOW, I think the above could become > > ret = restore_user_sigmask(ksig.sigmask, &sigsaved, ret, -ERESTARTHAND); > > instead if we just made the right interface decision. But that falls down if ret were ever expected to match several similar error codes (not sure if it happens) When I was considering fixing this on my own a few weeks ago, I was looking for an inline that could quickly tell if `ret' was any of the EINTR-like error codes; but couldn't find one... It'd probably end up being switch/case statement so I'm not sure if it'd be too big and slow or not... The caller would just do: ret = restore_user_sigmask(ksig.sigmask, &sigsaved, ret); And restore_user_sigmask would call some "was_interrupted(ret)" inline which could return true if `ret' matched any of the too-many-to-keep-track-of EINTR-like codes. But I figured there's probably a good reason it did not exist, already *shrug* /me goes back to the wonderful world of userspace...