[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220613145540.1c9f7750092911bae1332b92@linux-foundation.org>
Date: Mon, 13 Jun 2022 14:55:40 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Axel Rasmussen <axelrasmussen@...gle.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Charan Teja Reddy <charante@...eaurora.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"Dmitry V . Levin" <ldv@...linux.org>,
Gleb Fotengauer-Malinovskiy <glebfm@...linux.org>,
Hugh Dickins <hughd@...gle.com>, Jan Kara <jack@...e.cz>,
Jonathan Corbet <corbet@....net>,
Mel Gorman <mgorman@...hsingularity.net>,
Mike Kravetz <mike.kravetz@...cle.com>,
Mike Rapoport <rppt@...nel.org>, Nadav Amit <namit@...are.com>,
Peter Xu <peterx@...hat.com>, Shuah Khan <shuah@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
zhangyi <yi.zhang@...wei.com>, linux-doc@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v3 2/6] userfaultfd: add /dev/userfaultfd for fine
grained access control
On Wed, 1 Jun 2022 14:09:47 -0700 Axel Rasmussen <axelrasmussen@...gle.com> wrote:
> To achieve this, add a /dev/userfaultfd misc device. This device
> provides an alternative to the userfaultfd(2) syscall for the creation
> of new userfaultfds. The idea is, any userfaultfds created this way will
> be able to handle kernel faults, without the caller having any special
> capabilities. Access to this mechanism is instead restricted using e.g.
> standard filesystem permissions.
The use of a /dev node isn't pretty. Why can't this be done by
tweaking sys_userfaultfd() or by adding a sys_userfaultfd2()?
Peter, will you be completing review of this patchset?
Powered by blists - more mailing lists