Re: [PATCH v2] btrfs: reject refs=0 subvolume without DEAD in SUBVOL_SYNC_WAIT

[Qu Wenruo <wqu@suse.com>]

在 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