Re: deadlock bug related to bpf,audit subsystems

On Thu, Mar 18, 2021 at 12:57 PM Serhei Makarov <smakarov(a)redhat.com&gt; wrote: > On Thu, Mar 18, 2021 at 10:43 AM Serhei Makarov <smakarov(a)redhat.com&gt; wrote: > > Jiri Olsa also reports seeing a similar deadlock at v5.10. I'm in the > > middle of double-checking my bisection which ended up at a > > seemingly-unrelated commit [2] > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1938312 > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit... > > I've confirmed that my first bisection was incorrect by testing > @1c2f67308af4 mm: thp: fix MADV_REMOVE deadlock on shmem THP > and reproducing the deadlock. Previously this commit was marked as > good, so it seems a kernel with the bug can sometimes pass the test. > > I'll double check rc6 next since I have the kernel handy. If > 5.11.0-rc6 can also be made to fail, with Jiri Olsa's report it'd be > necessary to do a wider search. > There may be commits with intent similar to > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit... > which tightened some of the behaviour of kernel reads, but affecting > the audit subsystem? > The actual stack trace that leads to deadlock goes through > security_locked_down() which was present since the original patch > reworking probe_read into separate probe_read_{user,kernel} helpers > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit... Added thee SELinux list to the To/CC line; they should really be involved. I'm also CC'ing the LSM list for good measure as there may be other people that care about this.

FYI, the first instance of this thread that I saw can be found here via the linux-audit list: https://lore.kernel.org/linux-audit/CANYvDQN7H5tVp47fbYcRasv4XF07eUbsDwT_...