Re: [PATCH 1/3] rpdfs: Use write_seqlock_bh() for balloc info

On Thu, Mar 19, 2026 at 10:37:25AM +0100, Valerie Aurora wrote:
> The balloc info seqlock is taken from bh context due to
> rpdfs_balloc_publish_region() being called from an RCU callback, so it
> needs to use write_seqlock_bh() instead of write_seqlock(). Found via
> lockdep.

I'll admit, I was being a bit lazy and not running with debug kernels as
consistently as I should :).  I'll work on that.

> @@ -192,12 +192,12 @@ struct rpdfs_balloc_region *rpdfs_balloc_take_region(struct rpdfs_fs_info *rfi)
>  		while_read_seqretry(&balinf->seqlock)
>  			empty = list_empty(&balinf->region_list);
>  		if (!empty) {
> -			write_seqlock(&balinf->seqlock);
> +			write_seqlock_bh(&balinf->seqlock);

But let's do this another way.  Let's not punish all the users of the
region for the single weirdly implemented publish.

While the builder is protected by RCU, the region isn't.  It was just
bad reasoning to think that we needed to publish from call_rcu.  We only
need to free the builder there.

For publishing, first we can move the use of the region up above the
decrements of in_flight.  Then we save the result of the last in_flight
decrement for each case (initial trying to send, other responses
arriving).  Whoever won and got in_flight down to 0 can take exclusive
ownership of the region and publish it.  (The spin_unlock _release
semantics ensures that everyone's done with the region by the time they
start meessing with in_flight).

I'll that assume you want to take a swing at this but let me know if
you'd rather I clean up the mess I made.

- z