[heavily trimmed CC list because I think lkml is ignoring this thread...] On Thu, Jul 30, 2020 at 09:03:55AM +0200, Thomas Gleixner wrote: > Kees, > > Kees Cook <keescook@chromium.org> writes: > > This is the infrastructure changes to prepare the tasklet API for > > conversion to passing the tasklet struct as the callback argument instead > > of an arbitrary unsigned long. The first patch details why this is useful > > (it's the same rationale as the timer_struct changes from a bit ago: > > less abuse during memory corruption attacks, more in line with existing > > ways of doing things in the kernel, save a little space in struct, > > etc). Notably, the existing tasklet API use is much less messy, so there > > is less to clean up. > > > > It's not clear to me which tree this should go through... Greg since it > > starts with a USB clean-up, -tip for timer or interrupt, or if I should > > just carry it. I'm open to suggestions, but if I don't hear otherwise, > > I'll just carry it. > > > > My goal is to have this merged for v5.9-rc1 so that during the v5.10 > > development cycle the new API will be available. The entire tree of > > changes is here[1] currently, but to split it up by maintainer the > > infrastructure changes need to be landed first. > > > > Review and Acks appreciated! :) > > I'd rather see tasklets vanish from the planet completely, but that's > going to be a daring feat. So, grudgingly: Understood! I will update the comments near the tasklet API. > Acked-by: Thomas Gleixner <tglx@linutronix.de> Thanks! -- Kees Cook
Kees, > > [heavily trimmed CC list because I think lkml is ignoring this > thread...] > > On Thu, Jul 30, 2020 at 09:03:55AM +0200, Thomas Gleixner wrote: > > Kees, > > > > Kees Cook <keescook@chromium.org> writes: > > > This is the infrastructure changes to prepare the tasklet API for > > > conversion to passing the tasklet struct as the callback argument instead > > > of an arbitrary unsigned long. The first patch details why this is useful > > > (it's the same rationale as the timer_struct changes from a bit ago: > > > less abuse during memory corruption attacks, more in line with existing > > > ways of doing things in the kernel, save a little space in struct, > > > etc). Notably, the existing tasklet API use is much less messy, so there > > > is less to clean up. > > > > > > It's not clear to me which tree this should go through... Greg since it > > > starts with a USB clean-up, -tip for timer or interrupt, or if I should > > > just carry it. I'm open to suggestions, but if I don't hear otherwise, > > > I'll just carry it. > > > > > > My goal is to have this merged for v5.9-rc1 so that during the v5.10 > > > development cycle the new API will be available. The entire tree of > > > changes is here[1] currently, but to split it up by maintainer the > > > infrastructure changes need to be landed first. > > > > > > Review and Acks appreciated! :) > > > > I'd rather see tasklets vanish from the planet completely, but that's > > going to be a daring feat. So, grudgingly: > > Understood! I will update the comments near the tasklet API. > > > Acked-by: Thomas Gleixner <tglx@linutronix.de> > Here's the series re-based on top of 5.8 https://github.com/allenpais/tasklets/tree/V3 Let me know how you would want these to be reviewed. Also, I was thinking if removing tasklets completely could be a task on KSPP wiki. If yes, I did like to take ownership of that task. I have a couple of ideas in mind, which could be discussed in a separate email. Thanks. -- - Allen
Kees,
> >
>
> Here's the series re-based on top of 5.8
> https://github.com/allenpais/tasklets/tree/V3
>
> Let me know how you would want these to be reviewed.
>
I see the first set of infrastructure patches for tasklets have
landed in Linus's tree. Good time to send out the ~200 patches?
- Allen
On Mon, Aug 03, 2020 at 02:16:15PM +0530, Allen wrote: > Here's the series re-based on top of 5.8 > https://github.com/allenpais/tasklets/tree/V3 Great! > Let me know how you would want these to be reviewed. Was a Coccinelle script used for any of these conversions? I wonder if it'd be easier to do a single treewide patch for the more mechanical changes. And, actually, I still think the "prepare" patches should just be collapsed into the actual "covert" patches -- there are only a few. After those, yeah, I think getting these sent to their respective maintainers is the next step. > Also, I was thinking if removing tasklets completely could be a task > on KSPP wiki. If yes, I did like to take ownership of that task. I have a > couple of ideas in mind, which could be discussed in a separate email. Sure! I will add it to the tracker. Here's for the refactoring: https://github.com/KSPP/linux/issues/30 and here's for the removal: https://github.com/KSPP/linux/issues/94 if you can added details/examples of how they should be removed, that'd help other folks too, if they wanted to jump in. :) -Kees -- Kees Cook
On Tue, 11 Aug 2020 23:33:13 +0200,
Kees Cook wrote:
>
> On Mon, Aug 03, 2020 at 02:16:15PM +0530, Allen wrote:
> > Here's the series re-based on top of 5.8
> > https://github.com/allenpais/tasklets/tree/V3
>
> Great!
>
> > Let me know how you would want these to be reviewed.
>
> Was a Coccinelle script used for any of these conversions? I wonder if
> it'd be easier to do a single treewide patch for the more mechanical
> changes.
>
> And, actually, I still think the "prepare" patches should just be
> collapsed into the actual "covert" patches -- there are only a few.
>
> After those, yeah, I think getting these sent to their respective
> maintainers is the next step.
>
> > Also, I was thinking if removing tasklets completely could be a task
> > on KSPP wiki. If yes, I did like to take ownership of that task. I have a
> > couple of ideas in mind, which could be discussed in a separate email.
>
> Sure! I will add it to the tracker. Here's for the refactoring:
> https://github.com/KSPP/linux/issues/30
>
> and here's for the removal:
> https://github.com/KSPP/linux/issues/94
>
> if you can added details/examples of how they should be removed, that'd
> help other folks too, if they wanted to jump in. :)
I have a patch set to convert the remaining tasklet usage in sound
drivers to either the threaded IRQ or the work, but it wasn't
submitted / merged for 5.8 due to the obvious conflict with your API
changes.
Each conversion is rather simple, but it's always a question of the
nature of each tasklet usage which alternative is the best fit.
FWIW, the current version is found in test/kill-tasklet branch of
sound git tree
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
thanks,
Takashi
>
> I have a patch set to convert the remaining tasklet usage in sound
> drivers to either the threaded IRQ or the work, but it wasn't
> submitted / merged for 5.8 due to the obvious conflict with your API
> changes.
> Each conversion is rather simple, but it's always a question of the
> nature of each tasklet usage which alternative is the best fit.
>
> FWIW, the current version is found in test/kill-tasklet branch of
> sound git tree
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
Great. Currently my tree has these converted to use the new
tasklet_setup() api. I will add these to my threaded IRQ/work tree
(which is still wip).
Thanks.
--
- Allen
Kees, > Was a Coccinelle script used for any of these conversions? I wonder if > it'd be easier to do a single treewide patch for the more mechanical > changes. No, I should have written one. Will do it. > And, actually, I still think the "prepare" patches should just be > collapsed into the actual "covert" patches -- there are only a few. Okay. It's been done and pushed to: https://github.com/allenpais/tasklets/tree/V4 > After those, yeah, I think getting these sent to their respective > maintainers is the next step. Please look at the above branch, if it looks fine, let me know if I can add your ACK on the patches. > > Sure! I will add it to the tracker. Here's for the refactoring: > https://github.com/KSPP/linux/issues/30 > > and here's for the removal: > https://github.com/KSPP/linux/issues/94 > > if you can added details/examples of how they should be removed, that'd > help other folks too, if they wanted to jump in. :) Sure, Thank you. - Allen