Merge tag 'pidfd.v5.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner...
authorLinus Torvalds <torvalds@linux-foundation.org>
Sun, 20 Feb 2022 18:55:05 +0000 (10:55 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sun, 20 Feb 2022 18:55:05 +0000 (10:55 -0800)
commitc1034d249d1453b0f4c11582515a418a5d45b570
tree3560dbf24b6d436b07bf8ed3e1074c3001eb1f03
parent2d3409ebc87f4bc4ed23bd39e78db9ffc29eec44
parentddc204b517e60ae64db34f9832dc41dafa77c751
Merge tag 'pidfd.v5.17-rc4' of git://git./linux/kernel/git/brauner/linux

Pull pidfd fix from Christian Brauner:
 "This fixes a problem reported by lockdep when installing a pidfd via
  fd_install() with siglock and the tasklisk write lock held in
  copy_process() when calling clone()/clone3() with CLONE_PIDFD.

  Originally a pidfd was created prior to holding any of these locks but
  this required a call to ksys_close(). So quite some time ago in
  6fd2fe494b17 ("copy_process(): don't use ksys_close() on cleanups") we
  switched to a get_unused_fd_flags() + fd_install() model.

  As part of that we moved fd_install() as late as possible. This was
  done for two main reasons. First, because we needed to ensure that we
  call fd_install() past the point of no return as once that's called
  the fd is live in the task's file table. Second, because we tried to
  ensure that the fd is visible in /proc/<pid>/fd/<pidfd> right when the
  task is visible.

  This fix moves the fd_install() to an even later point which means
  that a task will be visible in proc while the pidfd isn't yet under
  /proc/<pid>/fd/<pidfd>.

  While this is a user visible change it's very unlikely that this will
  have any impact. Nobody should be relying on that and if they do we
  need to come up with something better but again, it's doubtful this is
  relevant"

* tag 'pidfd.v5.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
  copy_process(): Move fd_install() out of sighand->siglock critical section
kernel/fork.c