Re: [PATCH] locking/csd-lock: Report how long a stuck CSD lock took to recover

On Fri, Aug 07, 2026 at 10:57:21AM +0000, Dmitry Ilvokhin wrote:
> On Wed, Aug 05, 2026 at 05:51:54AM -0700, Breno Leitao wrote:
> > -static bool csd_lock_wait_toolong(call_single_data_t *csd, u64 ts0, u64 *ts1, int *bug_id, unsigned long *nmessages)
> > +static bool csd_lock_wait_toolong(call_single_data_t *csd, u64 ts0, u64 *ts1, u64 *ts_resend,
> > +				  int *bug_id, unsigned long *nmessages)
> 
> nit: csd_lock_wait_toolong() has too many arguments now to my liking.
> This was already a bit awkward before, maybe it is time for a small
> clean up. Does it make sense to pack timestamps, bug_id and nmessages
> into a struct and pass it around instead?

I would say so. Also, those parameters (tsX) were a bit hard to
understand, and when I create the other function, I've tried to keep it
a bit more sane (ts_start, ts_unstuck, ts_resend) instead of tsX. 

> That could go in as a separate cleanup ahead of this one.

I am more than happy to do it. Let's see what Paul says.

> Other than that, it looks reasonable to me.
> 
> With or without that:
> 
> Reviewed-by: Dmitry Ilvokhin <[email protected]>

Thanks for the review,
--breno