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

[Eric W. Biederman]

Linus Torvalds <torvalds at linux-foundation.org> writes:

> On Mon, Aug 17, 2020 at 3:11 PM Eric W. Biederman <ebiederm at xmission.com> 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?

task_lock is needed to protect task->files.

files->fd_array is rcu protected.

We could change task->files to be rcu protected but today we do
an immediate free of task files.

> 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?

If we want to change how task->files is freed in exit_files.
Well freed in put_files_struct really.

Rereading it I am having a hard time convincing myself that the
__free_fdtable in put_files_struct is fine.  I will have a look
tommorrow after I have slept.

> 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.

I hope this email isn't belittling.  But yes you did miss a thing or
two, and now I am not certain I haven't missed anything.

Eric