In the Linux kernel, the following vulnerability has been resolved:

bcachefs: grab sumount only if snapshotting

When I was testing mongodb over bcachefs with compression, there is a lockdep warning when snapshotting mongodb data volume.

$ cat test.sh prog=bcachefs

$prog subvolume create /mnt/data $prog subvolume create /mnt/data/snapshots

while true;do $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s) sleep 1s done

$ cat /etc/mongodb.conf systemLog: destination: file logAppend: true path: /mnt/data/mongod.log

storage: dbPath: /mnt/data/

lockdep reports: [ 3437.452330] ====================================================== [ 3437.452750] WARNING: possible circular locking dependency detected [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E [ 3437.453562] ------------------------------------------------------ [ 3437.453981] bcachefs/35533 is trying to acquire lock: [ 3437.454325] ffffa0a02b2b1418 (sbwriters#10){.+.+}-{0:0}, at: filenamecreate+0x62/0x190 [ 3437.454875] but task is already holding lock: [ 3437.455268] ffffa0a02b2b10e0 (&type->sumountkey#48){.+.+}-{3:3}, at: bch2fsfileioctl+0x232/0xc90 [bcachefs] [ 3437.456009] which lock already depends on the new lock.

[ 3437.456553] the existing dependency chain (in reverse order) is: [ 3437.457054] -> #3 (&type->sumountkey#48){.+.+}-{3:3}: [ 3437.457507] downread+0x3e/0x170 [ 3437.457772] bch2fsfileioctl+0x232/0xc90 [bcachefs] [ 3437.458206] x64sysioctl+0x93/0xd0 [ 3437.458498] dosyscall64+0x42/0xf0 [ 3437.458779] entrySYSCALL64afterhwframe+0x6e/0x76 [ 3437.459155] -> #2 (&c->snapshotcreatelock){++++}-{3:3}: [ 3437.459615] downread+0x3e/0x170 [ 3437.459878] bch2truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfstruncate+0x254/0x3c0 [bcachefs] [ 3437.460686] notifychange+0x1f1/0x4a0 [ 3437.461283] dotruncate+0x7f/0xd0 [ 3437.461555] pathopenat+0xa57/0xce0 [ 3437.461836] dofilpopen+0xb4/0x160 [ 3437.462116] dosysopenat2+0x91/0xc0 [ 3437.462402] x64sysopenat+0x53/0xa0 [ 3437.462701] dosyscall64+0x42/0xf0 [ 3437.462982] entrySYSCALL64afterhwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->stype->imutexkey#15){+.+.}-{3:3}: [ 3437.463843] downwrite+0x3b/0xc0 [ 3437.464223] bch2writeiter+0x5b/0xcc0 [bcachefs] [ 3437.464493] vfswrite+0x21b/0x4c0 [ 3437.464653] ksyswrite+0x69/0xf0 [ 3437.464839] dosyscall64+0x42/0xf0 [ 3437.465009] entrySYSCALL64afterhwframe+0x6e/0x76 [ 3437.465231] -> #0 (sbwriters#10){.+.+}-{0:0}: [ 3437.465471] lockacquire+0x1455/0x21b0 [ 3437.465656] lockacquire+0xc6/0x2b0 [ 3437.465822] mntwantwrite+0x46/0x1a0 [ 3437.465996] filenamecreate+0x62/0x190 [ 3437.466175] userpathcreate+0x2d/0x50 [ 3437.466352] bch2fsfileioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] x64sysioctl+0x93/0xd0 [ 3437.466791] dosyscall64+0x42/0xf0 [ 3437.466957] entrySYSCALL64afterhwframe+0x6e/0x76 [ 3437.467180] other info that might help us debug this:

[ 3437.469670] 2 locks held by bcachefs/35533: other info that might help us debug this:

[ 3437.467507] Chain exists of: sbwriters#10 --> &c->snapshotcreatelock --> &type->sumountkey#48

[ 3437.467979] Possible unsafe locking scenario:

[ 3437.468223] CPU0 CPU1 [ 3437.468405] ---- ---- [ 3437.468585] rlock(&type->sumountkey#48); [ 3437.468758] lock(&c->snapshotcreatelock); [ 3437.469030] lock(&type->sumountkey#48); [ 3437.469291] rlock(sbwriters#10); [ 3437.469434] DEADLOCK

[ 3437.469 ---truncated---