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 BD741C433E0 for ; Fri, 31 Jul 2020 17:42:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9EA5F2083B for ; Fri, 31 Jul 2020 17:42:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596217329; bh=BJ6AJiaX7Nzu5eZgUJYXd369reLLS6gyuy9w1TfkhV4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=BgS+MVEgylO4VcjN4Dszy4FFJRpSsfZRcRXDhlpGdTGpMcvHCCs3uPwEaxsQQ30i6 WzVB6S0NofjFF/B6Y60NnYtFvsSW7ewNz7K4UdqcjvJ0/kIeGrASxm9xxlB44/cTsr ChKhXQsvzQzZKD2R/pFMFBgyfO767JWRku3LwXKU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387455AbgGaRmJ (ORCPT ); Fri, 31 Jul 2020 13:42:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733153AbgGaRmI (ORCPT ); Fri, 31 Jul 2020 13:42:08 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40C6BC061574 for ; Fri, 31 Jul 2020 10:42:08 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id g6so20621002ljn.11 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=qpn5VcNFG8/FpjoV1LJ+GWmIJ54z3HrElWck7HDSClZ/DXEBfu/RXxIlYfTF/JYRsn c7OCDqwLGMyJfjXSgTef6N5mwMIOlhABjNrvF3UzRw/TzqQXR4/Kot9UH6yjslhXKxbV Xe1zVl6Q42dE3Bap+ge7R+vYeaseguZCbM7NqvoEN8cB//uRU+5s8sR1gxo/i/oZDiHv slYtXgXkJyEwszGwjwBlg+bLYlCiJVFdDyvae5T1+lK6k0aS9dbt4CYN7o10zLF2JWTc d4j7JUf/lansFtSN0YLjMomAcPgVieHZe8i5D6J9++kj3IaLOY1rt8fztOJKK7Jv+0WP cRvw== X-Gm-Message-State: AOAM533Dyrq+fZCcyU6QinE4eC+8SKKkK686hBrJ9aW72BOQE7iiOoHH QPgPlaO5gCLqLtpk4Mmj6crU5D9jNYE= X-Google-Smtp-Source: ABdhPJwmus+HN5J83+Bwo6DXoL2gO3uv6/rIXCuCJA+2B9jzoYTCiSXT5+3F3jvRjZGaRuq94EKBxQ== X-Received: by 2002:a2e:a373:: with SMTP id i19mr2304810ljn.206.1596217326374; Fri, 31 Jul 2020 10:42:06 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id b26sm2155740lji.36.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-f175.google.com with SMTP id z4so2827964ljj.6 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-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@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