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

[Paul E. McKenney]

On Fri, Aug 07, 2026 at 06:16:33AM -0700, Breno Leitao wrote:
> 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.

When I split that function out, I was thinking of it strictly as an
internal interface.  But with the continued evolution, it would not
hurt to make it easier to deal with.  I have no objection to packing
them into a struct.

							Thanx, Paul

> > Other than that, it looks reasonable to me.
> > 
> > With or without that:
> > 
> > Reviewed-by: Dmitry Ilvokhin <d@xxxxxxxxxxxx>
> 
> Thanks for the review,
> --breno