linux-kernel - [PATCH 0/5] gfs2: debugfs PID reporting improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Jun 2022 22:46:06 +0200
From:   Andreas Gruenbacher <agruenba@...hat.com>
To:     cluster-devel@...hat.com
Cc:     Andreas Gruenbacher <agruenba@...hat.com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: [PATCH 0/5] gfs2: debugfs PID reporting improvements

Currently, all glock holders in the "glocks" dump file are reported as
being associated with the process that acquired them, even for holders
that are actually associated with the filesystem itself (like the
journal glock holder) or with cached inodes (like iopen and flock glock
holders).  This is confusing when those holders outlive the processes
that have acquired them, and it trips up utilities that analyze lock
dependencies.  For example, the following two glocks were acquired by
pid 10821 during the initial mount, which has since terminated:

  G:  s:EX n:9/0 f:qb t:EX d:EX/0 a:0 v:0 r:3 m:200 p:0
   H: s:EX f:ecH e:0 p:10821 [(ended)] init_inodes+0x5c2/0xb10 [gfs2]
  G:  s:EX n:2/805f f:qob t:EX d:EX/0 a:0 v:0 r:4 m:200 p:1
   H: s:EX f:H e:0 p:10821 [(ended)] gfs2_fill_super+0x92b/0xcc0 [gfs2]
   I: n:6/32863 t:8 f:0x00 d:0x00000201 s:24 p:0

This patch queue tries to fix this problem in two ways:

 * Glock holders which are not held by the process that acquired them
   are marked as GL_NOPID.  For those holders, the PID is reported as 0,
   and the process name is reported as "(none)".

 * With this change alone, we would have a much harder time detecting
   locking cycles involving iopen or flock glocks: in both cases, a
   process which has a file descriptor open depends on the iopen and
   flock glock of the corresponding inode / file.  To keep track of
   these dependencies, we introduce a new "glockfd" dump file that
   reports which file descriptors of which processes are holding which
   glocks.

A utility that checks for locking problems using this additional
information is forthcoming, but hasn't been completed so far.

NEW EXPORTS

This patch queue requires iterating through all file descriptors of all
processes, which is made easier by exporting find_ge_pid() and
task_lookup_next_fd_rcu(); copying Eric W. Biederman and the
linux-kernel and linux-fsdevel lists to make sure that's okay.

Thanks,
Andreas

Andreas Gruenbacher (5):
  gfs2: Add glockfd debugfs file
  gfs2: Add flocks to glockfd debugfs file
  gfs2: Add GL_NOPID flag for process-independent glock holders
  gfs2: Mark flock glock holders as GL_NOPID
  gfs2: Mark the remaining process-independent glock holders as GL_NOPID

 fs/file.c            |   1 +
 fs/gfs2/file.c       |  29 +++++-
 fs/gfs2/glock.c      | 211 +++++++++++++++++++++++++++++++++++++++++--
 fs/gfs2/glock.h      |   1 +
 fs/gfs2/inode.c      |   6 +-
 fs/gfs2/ops_fstype.c |  14 +--
 fs/gfs2/super.c      |   3 +-
 fs/gfs2/util.c       |   6 +-
 kernel/pid.c         |   1 +
 9 files changed, 247 insertions(+), 25 deletions(-)

-- 
2.35.1