Re: [PATCH v2] btrfs: reject refs=0 subvolume without DEAD in SUBVOL_SYNC_WAIT
From: Qu Wenruo
Date: Sun Nov 01 2026 - 03:29:56 EST
在 2026/11/1 18:03, Cheng Yongkang 写道:
Hi Qu,
Thanks for taking the time to list these.
To be upfront about where this came from: I work on automated bug
finding for the kernel, and this ASSERT was one of its findings; the
analysis and the patch were LLM-assisted. I sent a fix rather than a
bare report because I had the impression that reports without a fix
get little attention, but I'm not the right person to rework
SUBVOL_SYNC_WAIT and add the btrfs-progs support and test cases you
describe.
One data point on the return value: in my testing on for-next, waiting
for a subvolume that was being deleted returned -ENOENT once the
cleaner had removed it, with and without this patch, so the success
path is never reached.
Since the tool keeps finding issues like this, I'd like to ask how you
would prefer to receive them:
- Would a [BUG] report with a reproducer, the tree and config, the
trace and a short analysis be more useful to you than a patch I
can't take further?
Yes, that would be preferred.
If you want, you can attach your LLM generated fix as a reference.
If it's really some simple fix, one of the co-developers will push your patch with your fix.
If not, we will address it with your reported-by tags.
- For low-priority cases like this one (a debug-only ASSERT in an
ioctl with no real users), would you rather I batch them, or not
send them at all?
If you have hit more than 10 of such ASSERT()s, report them in a batch.
Otherwise one by one is fine.
If the ASSERT fix alone is still useful, I can send a v3 that only
replaces it with -EUCLEAN.
I'll merge the v2 fix with modified commit message. You have no need to resend.
Otherwise I'm fine with dropping the patch
and leaving this as a report.
Thanks,
Cheng Yongkang