[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiTtYMia0FR4h7_nV2RZ5pq=wR-7oMMK3o8o=EgAxMsmg@mail.gmail.com>
Date: Wed, 1 Jun 2022 12:23:06 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Alexey Gladkov <legion@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Christian Brauner <brauner@...nel.org>,
Iurii Zaikin <yzaikin@...gle.com>,
Kees Cook <keescook@...omium.org>,
Linux Containers <containers@...ts.linux.dev>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Vasily Averin <vvs@...tuozzo.com>
Subject: Re: [RFC PATCH 1/4] sysctl: API extension for handling sysctl
On Wed, Jun 1, 2022 at 12:19 PM Matthew Wilcox <willy@...radead.org> 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
Powered by blists - more mailing lists