Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1461199iob; Fri, 29 Apr 2022 06:00:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1ONX2vMX857La+BcCJLkzLQohi5UiqsyUwMO5JzNII0QiMJ80unvdw8r9OjiX2/CI0eKL X-Received: by 2002:a17:90b:1e4e:b0:1da:3931:951 with SMTP id pi14-20020a17090b1e4e00b001da39310951mr3766229pjb.231.1651237208074; Fri, 29 Apr 2022 06:00:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651237208; cv=none; d=google.com; s=arc-20160816; b=E+EieXQOiZ7tG/exFdRxiPhTMENs5gE3K0hSy5RmAHQcSmjlhh6gdRBuKEcXQbYyXT QyVkob0Fl+09fS+riOnxghg/ouDJaq2CEm8OJ+Rgsyfy107Jq2Xnb7Hc9Pcg8TCQa3f+ YWcJMzbOPWBisplXr40wq7sSlbgElfEC9J4k07zJjA9vLRrq8qV/hF5LhC0cKfoCnsod KCO+9lQsNqo+0SSvEeuPbXcyEHRg66QK8Yysjd9Bksv4bRYR5Qc2n9LoxfZ9vKFB5feW kiytFJkWNFFR0QDIkfp/AIqIQxteOnOQG7shqRJVyrkghpNvAIrgWJzMyWp0KMny771z MPzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=jkxpW3EdVAmqaoDM04pa7Fls99UHVBaNQniA0KfeFwg=; b=wn8pJHsPWXXgUDtP231KBU1w565MjeN8hc9BPb5AjY9lBuedNvXutQOrSq4uFFU1K8 xr33QULIORwNDTe2N47VF7XyTHYGuYe80i5zznlIRy/QhKXPBq8YhNaTHivQS9e2xlvo oJ4xJGySD+DoZnq96xidWG/CokR4dW0Hv/kKyG5NyJrovHOa3UDJuUzaR527tbER5vfn YVy35OPuvLYw7Do50P0KPfzUjYyTEho4Spq9HCd/gA42LuwTrjqOC3VMtMayYDC4cDqx xFuzolUEzbin39x+PqV8UvkUxeO6F9xN+lBBHZz4AsiFHsmQBHddyDmYA+KXkxvXlSd3 qnSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kinvolk.io header.s=google header.b=LlNxkv2E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kinvolk.io Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pc14-20020a17090b3b8e00b001d03c3aae68si12303824pjb.83.2022.04.29.05.59.50; Fri, 29 Apr 2022 06:00:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kinvolk.io header.s=google header.b=LlNxkv2E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kinvolk.io Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356675AbiD2JqL (ORCPT + 99 others); Fri, 29 Apr 2022 05:46:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238887AbiD2JqK (ORCPT ); Fri, 29 Apr 2022 05:46:10 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4877ABF303 for ; Fri, 29 Apr 2022 02:42:53 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id p10so13005976lfa.12 for ; Fri, 29 Apr 2022 02:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kinvolk.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jkxpW3EdVAmqaoDM04pa7Fls99UHVBaNQniA0KfeFwg=; b=LlNxkv2Et2hjxXNddYh87SBmC5hYSOujjgg24Uo8lcr4G+sb7/dJtUOoles0kZrGtr nb+1We3zvwO7gmwGN0D5xrq8VJVqtBIC8L6/JYzNUU++KuCuJzvLinR9X2QRsmFy9Cpo 4gSeXZnpNTK4JqphnpzYG1u0wxJSprbIH/ouE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jkxpW3EdVAmqaoDM04pa7Fls99UHVBaNQniA0KfeFwg=; b=EchGxGmfZcWabLTJYHUsDxLvqOqvRzgAGID/tBTFuoqT3hc0jc843/XKOc+Jz0KCy8 q3pNjI+ynEjudkPl0EgoFs/6jXdJPuiwMub55XoSnIFs4AW1WIIDld54Gwwf2krxVU54 XMuta0K7QkK4bLiMeWR7hdhwoLUKCJL4osxjtVLViC08FRBpftTwmXr02fTEQMDorjtV C/VpuWZeNw/KZvROd5+Oa//ewC4sN6Ectq+xXYmwc8bB1a1iS1lr6Pt/q7C9Zp2BNnR3 7VWDrC7bdv6hiag2Tqx1g2CC7xeISdgCC/CIMipBQAz6YGQPn37aVcmseFoLLfjh8Pqu I1Pw== X-Gm-Message-State: AOAM531Pk4G/ZtXL5GrHcgkwx1JfiJL/lKzpVqW9px8jedA+KYhypyAo pIX9RmR9cFTcEDKxqUlo4YN/362YKbfh4wODZei2r3d1TTF1W37a X-Received: by 2002:a05:6512:108e:b0:472:2f9:ecae with SMTP id j14-20020a056512108e00b0047202f9ecaemr18910638lfg.618.1651225371669; Fri, 29 Apr 2022 02:42:51 -0700 (PDT) MIME-Version: 1.0 References: <20220429023113.74993-1-sargun@sargun.me> <20220429023113.74993-2-sargun@sargun.me> In-Reply-To: <20220429023113.74993-2-sargun@sargun.me> From: Rodrigo Campos Date: Fri, 29 Apr 2022 11:42:15 +0200 Message-ID: Subject: Re: [PATCH v3 1/2] seccomp: Add wait_killable semantic to seccomp user notifier To: Sargun Dhillon Cc: Kees Cook , LKML , Linux Containers , Christian Brauner , Giuseppe Scrivano , Will Drewry , Andy Lutomirski , Alban Crequy Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 29, 2022 at 4:32 AM Sargun Dhillon wrote: > the concept is searchable. If the notifying process is signaled prior > to the notification being received by the userspace agent, it will > be handled as normal. Why is that? Why not always handle in the same way (if wait killable is set, wait like that) > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > index db10e73d06e0..9291b0843cb2 100644 > --- a/kernel/seccomp.c > +++ b/kernel/seccomp.c > @@ -1081,6 +1088,12 @@ static void seccomp_handle_addfd(struct seccomp_kaddfd *addfd, struct seccomp_kn > complete(&addfd->completion); > } > > +static bool should_sleep_killable(struct seccomp_filter *match, > + struct seccomp_knotif *n) > +{ > + return match->wait_killable_recv && n->state == SECCOMP_NOTIFY_SENT; Here for some reason we check the notification state to be SENT. > +} > + > static int seccomp_do_user_notification(int this_syscall, > struct seccomp_filter *match, > const struct seccomp_data *sd) > @@ -1111,11 +1124,25 @@ static int seccomp_do_user_notification(int this_syscall, > * This is where we wait for a reply from userspace. > */ > do { > + bool wait_killable = should_sleep_killable(match, &n); > + So here, the first time this runs this will be false even if the wait_killable flag was used in the filter (because that function checks the notification state to be sent, that is not true the first time) Why not just do wait_for_completion_killable if match->wait_killable and wait_for_completion_interruptible otherwise? Am I missing something? Best, Rodrigo