Re: [RFC][PATCH v2 04/31] timers: block: Use del_timer_shutdown() before freeing timer
From: Steven Rostedt
Date: Fri Oct 28 2022 - 10:06:49 EST
On Fri, 28 Oct 2022 07:56:50 -0600
Jens Axboe <axboe@xxxxxxxxx> wrote:
> On 10/28/22 4:24 AM, Steven Rostedt wrote:
> > On Fri, 28 Oct 2022 01:26:03 -0700
> > Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> >
> >> This is just a single patch out of apparently 31, which claims that
> >> something that doesn't even exist in mainline must be used without any
> >> explanation. How do you expect anyone to be able to review it?
> >
> > https://lore.kernel.org/all/20221027150525.753064657@xxxxxxxxxxx/
> >
> > Only the first patch is relevant to you. I guess the Cc list would have
> > been too big to Cc everyone that was Cc'd in the series.
>
> No it's not, because how on earth would anyone know what the change does
> if you only see the simple s/name/newname change? The patch is useless
> by itself.
>
I meant this as the first patch:
https://lore.kernel.org/all/20221027150925.248421571@xxxxxxxxxxx/
Which was what the link above was suppose to point to.
It's the only patch relevant to the rest of the series, as the rest is just
converting over to the shutdown API, and the last patch changes
DEBUG_OBJECTS_TIMERS to catch if this was done properly.
That is, patch 01/31 and the patch you were Cc'd on is relevant, and for
those that want to look deeper, see patch 31 as well.
But if I included the Cc list for patch 01 for all those Cc'd in the
entire series, it would be a huge Cc list, so I avoided doing so.
Also, this is still RFC as the changes may still change. That is, this
patch set is a heads up to what is to come. Ideally, I'd like to get just
the API possibly in the kernel before the merge window without anyone using
it. Then I can ask all the sub systems to pull in these individual patches
as well.
-- Steve