Re: [PATCH 12/17] proc/fd: In fdinfo seq_show don't use get_files_struct

From: Linus Torvalds
Date: Mon Aug 17 2020 - 20:08:56 EST


On Mon, Aug 17, 2020 at 3:11 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>
> Instead hold task_lock for the duration that task->files needs to be
> stable in seq_show. The task_lock was already taken in
> get_files_struct, and so skipping get_files_struct performs less work
> overall, and avoids the problems with the files_struct reference
> count.

Hmm. Do we even need that task_lock() at all? Couldn't we do this all
with just the RCU lock held for reading?

As far as I can tell, we don't really need the task lock. We don't
even need the get/pid_task_struct().

Can't we just do

rcu_read_lock();
task = pid_task(proc_pid(inode), PIDTYPE_PID);
if (task) {
unsigned int fd = proc_fd(m->private);
struct file *file = fcheck_task(task, fd);
if (file)
.. do the seq_printf ..

and do it all with no refcount games or task locking at all?

Anyway, I don't dislike your patch per se, I just get the feeling that
you could go a bit further in that cleanup..

And it's quite possible that I'm wrong, and you can't just use the RCU
lock, but as far as I can tell, both the task lookup and the file
lookup *already* really both depend on the RCU lock anyway, so the
other locking and reference counting games really do seem superfluous.

Please just send me a belittling email telling me what a nincompoop I
am if I have missed something.

Linus