[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whHbXMF142EGVu4=8bi8=JdexBL--d5FK4gx=x+SUgyaQ@mail.gmail.com>
Date: Thu, 27 Apr 2023 08:21:34 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Christian Brauner <brauner@...nel.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] pidfd updates
On Thu, Apr 27, 2023 at 12:39 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> int delayed_dup(struct file *file, unsigned flags)
Ok, this is strange. Let me think about it.
But even without thinking about it, this part I hate:
> struct delayed_dup *p = kmalloc(sizeof(struct delayed_dup), GFP_KERNEL);
Sure, if this is only used in unimportant code where performance
doesn't matter, doing a kmalloc is fine.
But if that is the only use, I think this is too subtle an interface.
Could we instead limit it to "we only have one pending delayed dup",
and make this all be more like the restart-block thing, and be part of
struct task_struct?
I think it's conceptually quite similar to restart_block, ie a "some
pending system call state" thing.
(Obviously it's entirely different in details).
Linus
Powered by blists - more mailing lists