Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2004718ybz; Sun, 26 Apr 2020 09:02:01 -0700 (PDT) X-Google-Smtp-Source: APiQypITDFw7wUwAFC0xGOBsQYcxRLOSZQAQMMferei18Vyr9rBo1jtavfjMnOQeidieZqLKubTp X-Received: by 2002:a05:6402:4ce:: with SMTP id n14mr16567467edw.32.1587916921553; Sun, 26 Apr 2020 09:02:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587916921; cv=none; d=google.com; s=arc-20160816; b=tEKnJONCce4eSN4N6Me1AuB8yZb6mzAl85fa+r5OBdTgqa1Guy9ye8q8WdVcgunUi9 VZu7qaUA0r8csWLNrhGRfaKHkfhyeFthZDLgcWabOFfGNwrf0X2IQeKaUh7Skl3VN5jQ ovblHiukagV06kpBeqRmp5RUKv58bRh74j3dLcCv0JdlEfjzhekd6rFRBzUHBmlCYCa4 s98CmvdfurxO0CikqTK8WWcJhZ6ReJ4JPxCFaC30SY0dsrRA3Cftxl02X1PDFdiEAxz7 Qd2HVfB28SH7X47AeGFgUi+uuOdn9x+VQ8GqcyXBHhfdqhdmtBKG5rv5txTFiYtskYia 8mmA== 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=MOruVO9tw9imppVR2/TKU2TXdiURME8p1h+I6afKks4=; b=N+wTVi0VUZbhJ+A0FEykZB1h3KdAAbaeohJQ4bSbbLX7pw5nVCqLGTVlcis1Um1m1r jCoeVZ8EeIOaTCeXr9mFNONInDBZwGngBTYGJi54IZ6jKrTPwsCGdWj9/+PO7FDuZB+P PYseFH23zWm98eYuROoQtMoZH0/cf+EyYQBFOj7XWsGXrIYxmr6UC8V9Str9UADYGmGQ SiSF/+zzjojZzDPeJU2fHAyEx238WSpf0kcEERVh10Tanz4tfdpByC5JGxst0g9vNTIO 3oVMv3Wvw3J1lXDcc2dLzJ1bxBc6yZLqTPLHl37ssV5VVX75q/xzH48bxRBCfYAN+o4P VGtw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g11si6442991eje.262.2020.04.26.09.01.37; Sun, 26 Apr 2020 09:02:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726213AbgDZQAL (ORCPT + 99 others); Sun, 26 Apr 2020 12:00:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725778AbgDZQAL (ORCPT ); Sun, 26 Apr 2020 12:00:11 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D66BC061A0F; Sun, 26 Apr 2020 09:00:11 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jSjhG-00C1Jz-QW; Sun, 26 Apr 2020 15:59:58 +0000 Date: Sun, 26 Apr 2020 16:59:58 +0100 From: Al Viro To: Christoph Hellwig Cc: Kees Cook , Iurii Zaikin , Alexei Starovoitov , Daniel Borkmann , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org Subject: Re: pass kernel pointers to the sysctl ->proc_handler method v3 Message-ID: <20200426155958.GS23230@ZenIV.linux.org.uk> References: <20200424064338.538313-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200424064338.538313-1-hch@lst.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 24, 2020 at 08:43:33AM +0200, Christoph Hellwig wrote: > Hi all, > > this series changes the sysctl ->proc_handler methods to take kernel > pointers. This simplifies some of the pointer handling in the methods > (which could probably be further simplified now), and gets rid of the > set_fs address space overrides used by bpf. > > Changes since v2: > - free the buffer modified by BPF > - move pid_max and friends to pid.h > > Changes since v1: > - drop a patch merged by Greg > - don't copy data out on a write > - fix buffer allocation in bpf OK, I can live with that; further work can live on top of that, anyway. How are we going to handle that? I can put it into never-rebased branch in vfs.git (#work.sysctl), so that people could pull that. FWIW, I'm putting together more uaccess stuff (will probably hit -next tonight or tomorrow); this would fit well there...