From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A88DC433E1 for ; Fri, 31 Jul 2020 17:42:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 20E7721744 for ; Fri, 31 Jul 2020 17:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596217330; bh=BJ6AJiaX7Nzu5eZgUJYXd369reLLS6gyuy9w1TfkhV4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=Xf4bDkjDK7Pdt4v9bWEjS74Tvdm3kNNSg+a7RsrTdQKfn4SE5jcuoNqcdZeGuBjkw xA/yEr2OI/Woci0v/lY4wGx4mEiFa10djvlpOEhma03QjPi56HvcYm7AhSCCstn7SA ndlDZ2eSvqEUtMwFmbuno0yFWHsWL2eASWWW+omg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387520AbgGaRmJ (ORCPT ); Fri, 31 Jul 2020 13:42:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733265AbgGaRmI (ORCPT ); Fri, 31 Jul 2020 13:42:08 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66796C06174A for ; Fri, 31 Jul 2020 10:42:08 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id s9so17292915lfs.4 for ; Fri, 31 Jul 2020 10:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=28cR6MxZbujlZ14NZ0HVtiSgAqlUlORhwpPRlaJnnaw=; b=ARF0tJgweiX8TuwD/1AuE8ihqF28A/0GG/2hOKEe5zsa5dn6IQ7vjuiCyXUDIEpTTu zkma0hSorXfSXFzP5ErNIzvSEoDve/Vh8jrM5DAnEExvyO5v/D6+sPEczzTrI1FPjJfl t4GEgq5BrOqFLTYFU8zRTlt69XfwnP6VESCBE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=28cR6MxZbujlZ14NZ0HVtiSgAqlUlORhwpPRlaJnnaw=; b=EhCkQonEdXTXzqiQrND2xmI5ipxRgudeWPIuJiddbnjGWKzfZhbwVczeitqbqmid/C KMfLBEwAAXEKHJM9Tf5MVmovzdJTYkvx2j8PwTQ81KrrGIJIC5kwg5j9QZ34b07ZDchJ bbjFWc3IcyK7tG0fyE4541ATua5GUX3O7gXdiK1dQ3Wh/eLtwUsH6KP3SritqyZA85lh C5588+6jYNi4vp2pmtsHJ33wJjVvbTihmqqoT68gtA2zY4t9tAvBCOMo9Z91B830ywZm j3/bKxgfRTEDXN97NhmOfUH+AdhisfmRYHd1qClqK8vu4rfY6QJNH7px5BwUp/VQ2qz5 XGJQ== X-Gm-Message-State: AOAM531S3f5lcVhv2C2xzv5fy5joU0EWpOTD3EPTqFYrA9Ixu7tQrxC2 3qwPGa31EhlrqfhK5QJHf9p8L/PIoAY= X-Google-Smtp-Source: ABdhPJzcNsKJZlDPPICzYnJA20wtyk8HwGAGJWFVcQQcq5rdnE3BTd5BDtaxdyEzBSK1odJT1soS9A== X-Received: by 2002:a05:6512:3583:: with SMTP id m3mr2492517lfr.146.1596217326422; Fri, 31 Jul 2020 10:42:06 -0700 (PDT) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com. [209.85.208.172]) by smtp.gmail.com with ESMTPSA id o68sm2074330lff.57.2020.07.31.10.42.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jul 2020 10:42:05 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id s16so18021463ljc.8 for ; Fri, 31 Jul 2020 10:42:04 -0700 (PDT) X-Received: by 2002:a2e:86c4:: with SMTP id n4mr2425348ljj.312.1596217324449; Fri, 31 Jul 2020 10:42:04 -0700 (PDT) MIME-Version: 1.0 References: <87h7tsllgw.fsf@x220.int.ebiederm.org> <87d04fhkyz.fsf@x220.int.ebiederm.org> <87h7trg4ie.fsf@x220.int.ebiederm.org> <878sf16t34.fsf@x220.int.ebiederm.org> <87pn8c1uj6.fsf_-_@x220.int.ebiederm.org> <87pn8by58y.fsf@x220.int.ebiederm.org> In-Reply-To: <87pn8by58y.fsf@x220.int.ebiederm.org> From: Linus Torvalds Date: Fri, 31 Jul 2020 10:41:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH] exec: Conceal the other threads from wakeups during exec To: "Eric W. Biederman" Cc: Linux Kernel Mailing List , Kees Cook , Pavel Machek , "Rafael J. Wysocki" , linux-fsdevel , Oleg Nesterov , Linux PM Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Jul 31, 2020 at 10:19 AM Eric W. Biederman wrote: > > Even limited to opt-in locations I think the trick of being able to > transform the wait-state may solve that composition problem. So the part I found intriguing was the "catch things in the signal handling path". Catching things there - and *only* there - would avoid a lot of the problems we had with the freezer. When you're about to return to user mode, there are no lock inversions etc. And it kind of makes conceptual sense to do, since what you're trying to capture is the signal group - so using the signal state to do so seems like a natural thing to do. No touching of any runqueues or scheduler data structures, do everything _purely_ with the signal handling pathways. So that "feels" ok to me. That said, I do wonder if there are nasty nasty latency issues with odd users. Normally, you'd expect that execve() with other threads in the group shouldn't be a performance issue, because people simply shouldn't do that. So it might be ok. And if you capture them all in the signal handling pathway, that ends up being a very convenient place to zap them all too, so maybe my latency worry is misguided. IOW, I think that you could try to do your "freese other threads" not at all like the freezer, but more like a "collect all threads in their signal handler parts as the first phase of zapping them". So maybe this approach is salvageable. I see where something like the above could work well. But I say that with a lot of handwaving, and maybe if I see the patch I'd go "Christ, I was a complete idiot for ever even suggesting that". Linus