Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5873429ioo; Wed, 1 Jun 2022 14:38:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyBb4CF+r7ZeJ+1BHsZHK4L3zsXJfK35PKluKm71a/EOPgHtHbwMfJLDs0QLe4tJhGRblf X-Received: by 2002:a05:6a02:105:b0:381:fd01:330f with SMTP id bg5-20020a056a02010500b00381fd01330fmr1168246pgb.483.1654119486789; Wed, 01 Jun 2022 14:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654119486; cv=none; d=google.com; s=arc-20160816; b=fiqAb+Sg/v70IoUvvlAh7dFPnSd+dO7ayLoQBrxsH33yI3Rmg5qYWYOph3+f7MDyoH Y99yWiIFCCrdcewxAhZWH4Kejf1efmwZCOiOorBQToziFhzohiecGchxATBFLMw/T0hh fXr7BR/jAWGd8KmwbbrYOdjX0Lyg9pl1dtrnp+m4BNLHJP+Zt50PGA+RE86bJTUIJ4vD MhiJ4IzWjBnCeQIt94eOrgq32SwNONnRSeomBX4CLcrWzSojgVK5oFsb/rpBTerV7nDd gyotgnvExDI65x24YW1ETtl8HfyMRFio9M/6kGaBYiB2k4e0Z1UQJWuX+Ti80wKfalEF sCPA== 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=XQjh59P+YL657/ugkQgJkelCDXFl1T1Vs2NaT8wJJmg=; b=Yg8WW06nySXU1qJhd/8HktpdMHQnLrkqtjWSF9q0T9OWwzP6/XPcmtM4N9XyHXR+48 BoMpUza7trugCjyKj6hPc3vxM7qWw79ld9wSDpzfBlM1lN1VDHhuP7aRyr/qHwrk4Qqq u6x4AeoaFsBs6Jvh7CR53+OHR+dywwbBCrhWp8Ly+lUgcTNR/z3ucW59pr5hbpHVnnqh c8Fy240OUyXnyipBHL3lMMM1XBMZ7cmM/frVb4kyePlT1i/Cln/LxvXmKk8cW1wDmzOD /TshfZDYGLUvVpzVLa2xPhhmZcIJ7sN412W/f8EmCI+tg4kl/ENGiLL1q5K/aagScrSM G6PA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ZZSpwU9h; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id f5-20020a63f105000000b003f25d48f129si3424213pgi.196.2022.06.01.14.38.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 14:38:06 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ZZSpwU9h; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A80B22629F8; Wed, 1 Jun 2022 13:45:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229608AbiFAUpd (ORCPT + 99 others); Wed, 1 Jun 2022 16:45:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230062AbiFAUpR (ORCPT ); Wed, 1 Jun 2022 16:45:17 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF7891842DB for ; Wed, 1 Jun 2022 13:31:08 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id t25so4613794lfg.7 for ; Wed, 01 Jun 2022 13:31: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=XQjh59P+YL657/ugkQgJkelCDXFl1T1Vs2NaT8wJJmg=; b=ZZSpwU9hNx1vIgT23ZqORpMaSlb67mK71XYRdg7+sMMlwAstjUOjkA0TEXRoOiSjBx 1jZ+YVX1Q02lET6yIsH0PSBUu0oWXEAM0SWXWzAqwObT9JFumL5b5q+9KN6/0sp3uyvB Pok3GJX3EYSYz40c743Gtv1qk9/v1YKTSe4Gk= 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=XQjh59P+YL657/ugkQgJkelCDXFl1T1Vs2NaT8wJJmg=; b=Aq36YJOkbvQ6rWH0ckGQfBKoh5wYM82EIKl8jdSd7GiuREjrzOiW9boWCmy9o7YwRk nW9ivShbIplBxa5V9yyvCyxq3Yzd3M2xItnIE8tqFKQHgbOmg79WHmoujVyHJXqwwIBj I8hmkN2ZOMHmgsKwXfxuDNpe56o0CowXFG8FHrlHszy25qvHJ5sU+CbFLFmcU+7MRlgL Uv2h0ihZxtEDlqy2y2xpuOTyewbebug1JVXw4e6ccIiMpiA7KwPslgYqPfCFuaUMW/r5 LXDOiSo/BBtQMP1TJhPntnJd67kWZOdhSZvBws5bbRUResSZ6G4d0u7LAwH7G9t1c0VD Hzcg== X-Gm-Message-State: AOAM532idqESG2E7vo52WDHTYBGyaU4bt4qNk3rSr18ryM4V0xq9j3Cg 1hiNZZTot4/WhtkKReE/3dlm5J3wW9BaEWpo X-Received: by 2002:a17:906:4784:b0:6ff:34ea:d824 with SMTP id cw4-20020a170906478400b006ff34ead824mr999873ejc.526.1654111404095; Wed, 01 Jun 2022 12:23:24 -0700 (PDT) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com. [209.85.221.44]) by smtp.gmail.com with ESMTPSA id dc15-20020a170906c7cf00b006ff045d7c9bsm1013243ejb.173.2022.06.01.12.23.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jun 2022 12:23:23 -0700 (PDT) Received: by mail-wr1-f44.google.com with SMTP id k16so3661982wrg.7 for ; Wed, 01 Jun 2022 12:23:23 -0700 (PDT) X-Received: by 2002:a05:6000:1605:b0:210:307a:a94a with SMTP id u5-20020a056000160500b00210307aa94amr744700wrb.97.1654111402828; Wed, 01 Jun 2022 12:23:22 -0700 (PDT) MIME-Version: 1.0 References: <5ec6759ab3b617f9c12449a9606b6f0b5a7582d0.1654086665.git.legion@kernel.org> In-Reply-To: From: Linus Torvalds Date: Wed, 1 Jun 2022 12:23:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/4] sysctl: API extension for handling sysctl To: Matthew Wilcox Cc: Alexey Gladkov , LKML , "Eric W . Biederman" , Andrew Morton , Christian Brauner , Iurii Zaikin , Kees Cook , Linux Containers , linux-fsdevel , Luis Chamberlain , Vasily Averin Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Wed, Jun 1, 2022 at 12:19 PM Matthew Wilcox wrote: > > Why not pass the iocb in ->read and ->write? We're still regretting not > doing that with file_operations. No, all the actual "io" is done by the caller. There is no way in hell I want the sysctl callbacks to actually possibly do user space accesses etc. They get a kernel buffer that has already been set up. There is no iocb or iovec left for them. (That also means that they can take whatever locks they need, including spinlocks, because there's not going to be any random user accesses or complex pipe buffer lookups or whatever). Linus