pkg/report: consistent parsing of possible circular locking dependency detected reports

[a-nogikh]

Initially inspired by the following case:

• https://syzkaller.appspot.com/bug?extid=e088be3c2d5c05aaac35
• https://syzkaller.appspot.com/bug?extid=78f4eb354f5ca6c1e6eb

The stack traces are mostly the same, yet the reports differ in their top parts:

[   64.555204][ T5115] ======================================================
[   64.557845][ T5115] WARNING: possible circular locking dependency detected
[   64.560702][ T5115] 6.12.0-rc3-syzkaller-00389-g3d5ad2d4eca3 #0 Not tainted
[   64.564250][ T5115] ------------------------------------------------------
[   64.566538][ T5115] syz-executor733/5115 is trying to acquire lock:
[   64.568960][ T5115] ffff888038550128 (bcachefs_btree){+.+.}-{0:0}, at: __bch2_trans_relock+0x382/0x5f0
[   64.572656][ T5115] 
[   64.572656][ T5115] but task is already holding lock:
[   64.575583][ T5115] ffff8880424e1548 (&c->fsck_error_msgs_lock){+.+.}-{3:3}, at: __bch2_fsck_err+0x3dc/0x15f0

[   35.622426][ T6432] ======================================================
[   35.623809][ T6432] WARNING: possible circular locking dependency detected
[   35.625134][ T6432] 6.12.0-syzkaller-g7b1d1d4cfac0 #0 Not tainted
[   35.626295][ T6432] ------------------------------------------------------
[   35.627606][ T6432] syz-executor203/6432 is trying to acquire lock:
[   35.628790][ T6432] ffff0000da100128 (bcachefs_btree){+.+.}-{0:0}, at: trans_set_locked+0x5c/0x21c
[   35.630538][ T6432] 
[   35.630538][ T6432] but task is already holding lock:
[   35.631959][ T6432] ffff0000dc661548 (&c->fsck_error_msgs_lock){+.+.}-{3:3}, at: __bch2_fsck_err+0x344/0x2544
[   35.633903][ T6432] 
[   35.633903][ T6432] which lock already depends on the new lock.

This is caused by the trans_set_locked function being inlined in the second case. We only see it appear after symbolization:

       lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825
       trans_set_locked fs/bcachefs/btree_locking.h:194 [inline]
       __bch2_trans_relock+0x397/0x5f0 fs/bcachefs/btree_locking.c:785

This leads syzkaller to generate to two different titles.

---

Adding trans_set_locked to the list of titles skipped during parsing is not very helpful -- it just shifts the title from the task trying to acquire the lock to the task holding the lock.

Hence the question: how do we actually want to parse such reports?

I think it would be more correct to be explicit w.r.t. whether we want to anchor to the task that was the first or the task that was the last one.

• But is it actually a stable ordering? Or does it just depend on what task was more lucky to be the first one?
• If it's stable, what stack trace is the most informative?
• If the ordering is unstable, I guess we want to parse both and use one in the normal TITLE: and one in the ALT: title.