Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp258104ybm; Thu, 28 May 2020 01:55:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpT+bbRP7AZQA/4ipx9CZ05WTqOd6xtifpKBs4eNfKaOuDsOojQXe+Ce22DxSbSAt8g8b8 X-Received: by 2002:a50:b082:: with SMTP id j2mr1997773edd.201.1590656114117; Thu, 28 May 2020 01:55:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590656114; cv=none; d=google.com; s=arc-20160816; b=t+1MKS8Q1uJo7Y0nICm4Hb0C/cRFc02M1GZtFSkVhA4BmIUWzZ0pbX+TjwsXxwF5Hk ab60YSW5uiGOvQHBMhqPFUyyBxAMvoVd+ygDR+ik2PEYdWypai9gLMhl+8CkpuwVg7L5 fNbme0AcEIkXW96vk0KJgSrfEAGRulXBjPpZtPCE6dgcMRKQL8lfxGXj4Zr2B8ex+e6a jtf0G8sCJToJ1Z5GAtoIcmmHTSNQJiQ0c0NxDg9mUodyVkWRJhxx3BlGu2GXl0fgnIDv AXBveWg7soq00+42yGa24DU//hMQ59QtUUINX2Xw5Kmz3rNiZ4h4seqAmIRoAbibADJa wM+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=KPDkuu8yxOtB4HGO5e5sZAA5TDz4hCUiNh69Xo1Spek=; b=drSc0ORQCHX8BS1pZ8i8FvHTMN4T8VNmGRqY13SeIDawKpc62kTBClGX+ef6lZuWBN podtqVQ0go6u+IpUQ9PaAS0Ks/KXl4YwEtiz8afB3h1GFHaK05TMzoEZDBKdKa/O5D0R vBND+yUoRof0reOJ6DnynkC46rgDS22gWnV84QcA6hoPx+SBQIqOWaJAcSsSlQxQp35d 2cGaoJ7L8g/6lJQwgXd9JMEKIe0z8uALxRNhOY2ElQLqAJESGu2ptiJd1GBxTTGLH2hf clSLntBCPFbxSvm/4wk92wJDIHfP1JR6rzdmXNoeHkuHJDo3S+1rd9BCK0XfAQYk6VSb F2Ew== 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 cw7si2967069edb.2.2020.05.28.01.54.51; Thu, 28 May 2020 01:55:14 -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 S1727885AbgE1Iuy (ORCPT + 99 others); Thu, 28 May 2020 04:50:54 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:5361 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727088AbgE1Iux (ORCPT ); Thu, 28 May 2020 04:50:53 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7E43DB575D419CF2EC2B; Thu, 28 May 2020 16:50:51 +0800 (CST) Received: from [127.0.0.1] (10.67.102.197) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.487.0; Thu, 28 May 2020 16:50:49 +0800 Subject: Re: [PATCH v2 1/1] userfaultfd/sysctl: add vm.unprivileged_userfaultfd To: Peter Xu CC: , , , , , , , , , , , , , , , , , , , References: <3b64de85-beb4-5a07-0093-cad6e8f2a8d8@huawei.com> <20200527142143.GC1194141@xz-x1> From: Xiaoming Ni Message-ID: Date: Thu, 28 May 2020 16:50:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20200527142143.GC1194141@xz-x1> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.102.197] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/5/27 22:21, Peter Xu wrote: > On Wed, May 27, 2020 at 02:54:13PM +0800, Xiaoming Ni wrote: >> >> On Tue, Mar 19, 2019 at 11:07:22AM +0800, Peter Xu wrote: >>> Add a global sysctl knob "vm.unprivileged_userfaultfd" to control >>> whether userfaultfd is allowed by unprivileged users. When this is >>> set to zero, only privileged users (root user, or users with the >>> CAP_SYS_PTRACE capability) will be able to use the userfaultfd >>> syscalls. >> >> Hello > > Hi, Xiaoming, > >> I am a bit confused about this patch, can you help to answer it. >> >> Why the sysctl interface of fs/userfaultfd.c belongs to vm_table instead of >> fs_table ? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cefdca0a86be517bc390fc4541e3674b8e7803b0 > > Because I think it makes more sense to put the new key into where it suites > better, irrelevant to which directory the variable is declared. To me, > unprivileged_userfaultfd is definitely more suitable for vm rather than fs, > because userfaultfd is really about memory management rather than file system. > > Thanks, > Thank you for your answer Since userfaultfd and vm are more closely related, will there be consideration to move fs/userfaultfd.c to the mm directory in the future? Thanks Xiaoming Ni