On Thu, Oct 10, 2024 at 09:21:50PM GMT, Alan Huang wrote: > If the transaction chose itself as a victim before and restarted, it > might request a no fail lock request this time. But it might be added to > others' lock graph and be chose as the victim again, it's no longer safe > without additional check. We can also convert the cycle detector to be > fully RCU-based to solve that unsoundness, but the latency added to trans_put > and additional memory required may not worth it.
This is going to need ascii art diagrams... I would expect the lock waitlist locks and sequence numbers to protect against this kind of race, do they not? > > Signed-off-by: Alan Huang <[email protected]> > --- > fs/bcachefs/btree_locking.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/bcachefs/btree_locking.c b/fs/bcachefs/btree_locking.c > index bf25fd0a1cca..fff176382e30 100644 > --- a/fs/bcachefs/btree_locking.c > +++ b/fs/bcachefs/btree_locking.c > @@ -293,7 +293,7 @@ int bch2_check_for_deadlock(struct btree_trans *trans, > struct printbuf *cycle) > > g.nr = 0; > > - if (trans->lock_must_abort) { > + if (trans->lock_must_abort && !trans->lock_may_not_fail) { > if (cycle) > return -1; > > -- > 2.45.2 >
