drivers/media/pci/ivtv/ivtv-driver.c | 14 ++++---- drivers/media/pci/ivtv/ivtv-driver.h | 3 +- drivers/net/ethernet/microchip/encx24j600.c | 20 +++++------ drivers/tty/serial/sc16is7xx.c | 39 ++++++++++----------- kernel/kthread.c | 8 ++--- kernel/sched/cpufreq_schedutil.c | 33 ++++++++--------- 6 files changed, 50 insertions(+), 67 deletions(-)
kthread_worker_fn() has carried a FIXME for a decade: it assigns worker->task = current because the old kthread_run(kthread_worker_fn) callers never told the worker what task it was. The new kthread_create_worker*() API sets worker->task before the worker starts, so the self assignment is dead code. This series converts the four remaining users of the old pattern (ivtv, encx24j600, sc16is7xx, cpufreq_schedutil) to the new API, then removes the self assignment from kthread_worker_fn() while keeping a WARN_ON() as a sanity check for any out-of-tree users. v1 -> v2: - Keep WARN_ON() as a bare sanity check (Frederic, Peter) - Add comment explaining why the WARN_ON() is there - Fix subject and changelog wording Bradley Morgan (5): media: ivtv: convert to kthread_run_worker net: encx24j600: convert to kthread_run_worker tty: sc16is7xx: convert to kthread_run_worker cpufreq: schedutil: convert to kthread_create_worker kthread: remove worker->task self assignment drivers/media/pci/ivtv/ivtv-driver.c | 14 ++++---- drivers/media/pci/ivtv/ivtv-driver.h | 3 +- drivers/net/ethernet/microchip/encx24j600.c | 20 +++++------ drivers/tty/serial/sc16is7xx.c | 39 ++++++++++----------- kernel/kthread.c | 8 ++--- kernel/sched/cpufreq_schedutil.c | 33 ++++++++--------- 6 files changed, 50 insertions(+), 67 deletions(-) -- 2.47.3
On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: > media: ivtv: convert to kthread_run_worker > net: encx24j600: convert to kthread_run_worker > tty: sc16is7xx: convert to kthread_run_worker > cpufreq: schedutil: convert to kthread_create_worker Please send these 4 to appropriate subsystems > kthread: remove worker->task self assignment Then after the next merge window when trees converge send this one out
On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org> wrote: >On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: >> media: ivtv: convert to kthread_run_worker >> net: encx24j600: convert to kthread_run_worker >> tty: sc16is7xx: convert to kthread_run_worker >> cpufreq: schedutil: convert to kthread_create_worker > >Please send these 4 to appropriate subsystems > >> kthread: remove worker->task self assignment > >Then after the next merge window when trees converge send this one out hi, I was hoping one person could merge it with acks from all subsystems --- Thanks! https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote: > On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org> wrote: > >On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: > >> media: ivtv: convert to kthread_run_worker > >> net: encx24j600: convert to kthread_run_worker > >> tty: sc16is7xx: convert to kthread_run_worker > >> cpufreq: schedutil: convert to kthread_create_worker > > > >Please send these 4 to appropriate subsystems > > > >> kthread: remove worker->task self assignment > > > >Then after the next merge window when trees converge send this one out > > hi, I was hoping one person could merge it with acks from all subsystems Not how this works.
On 4 September 2026 22:10:32 BST, Jakub Kicinski <kuba@kernel.org> wrote: >On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote: >> On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org> >wrote: >> >On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: >> >> media: ivtv: convert to kthread_run_worker >> >> net: encx24j600: convert to kthread_run_worker >> >> tty: sc16is7xx: convert to kthread_run_worker >> >> cpufreq: schedutil: convert to kthread_create_worker >> > >> >Please send these 4 to appropriate subsystems >> > >> >> kthread: remove worker->task self assignment >> > >> >Then after the next merge window when trees converge send this one out >> >> hi, I was hoping one person could merge it with acks from all subsystems > >Not how this works. Ugh, I've seen it before happen. Look, fine, I'll do a V3 soon, WITH ONLY the subsystem changes, all separate, all sent over to their respective maintainers, then when all thathas been merged and there's the next merge window, then whatever, I'll send then the kthread removal IMHO this is a massive annoyance though.. because what if one of the driverfolks doesn't wanna respond to me!?! --- Thanks! https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
On Fri, Sep 04, 2026 at 10:13:32PM +0100, Bradley Morgan wrote: > On 4 September 2026 22:10:32 BST, Jakub Kicinski <kuba@kernel.org> wrote: > >On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote: > >> On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org> > >wrote: > >> >On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: > >> >> media: ivtv: convert to kthread_run_worker > >> >> net: encx24j600: convert to kthread_run_worker > >> >> tty: sc16is7xx: convert to kthread_run_worker > >> >> cpufreq: schedutil: convert to kthread_create_worker > >> > > >> >Please send these 4 to appropriate subsystems > >> > > >> >> kthread: remove worker->task self assignment > >> > > >> >Then after the next merge window when trees converge send this one out > >> > >> hi, I was hoping one person could merge it with acks from all subsystems > > > >Not how this works. > Ugh, I've seen it before happen. > > Look, fine, I'll do a V3 soon, WITH ONLY the subsystem changes, all > separate, all sent over to their respective maintainers, then when all > thathas been merged and there's the next merge window, then whatever, I'll > send then the kthread removal > > IMHO this is a massive annoyance though.. because what if one of the > driverfolks doesn't wanna respond to me!?! Then, after trying for the normal way, you can make the driver change at the same time. But to circumvent the "normal way" thinking it might not work, is not the best thing to do. thanks, greg k-h
On 5 September 2026 12:19:54 BST, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: >On Fri, Sep 04, 2026 at 10:13:32PM +0100, Bradley Morgan wrote: >> On 4 September 2026 22:10:32 BST, Jakub Kicinski <kuba@kernel.org> >wrote: >> >On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote: >> >> On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org> >> >wrote: >> >> >On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: >> >> >> media: ivtv: convert to kthread_run_worker >> >> >> net: encx24j600: convert to kthread_run_worker >> >> >> tty: sc16is7xx: convert to kthread_run_worker >> >> >> cpufreq: schedutil: convert to kthread_create_worker >> >> > >> >> >Please send these 4 to appropriate subsystems >> >> > >> >> >> kthread: remove worker->task self assignment >> >> > >> >> >Then after the next merge window when trees converge send this one >out >> >> >> >> hi, I was hoping one person could merge it with acks from all >subsystems >> > >> >Not how this works. >> Ugh, I've seen it before happen. >> >> Look, fine, I'll do a V3 soon, WITH ONLY the subsystem changes, all >> separate, all sent over to their respective maintainers, then when all >> thathas been merged and there's the next merge window, then whatever, >I'll >> send then the kthread removal >> >> IMHO this is a massive annoyance though.. because what if one of the >> driverfolks doesn't wanna respond to me!?! > >Then, after trying for the normal way, you can make the driver change at >the same time. But to circumvent the "normal way" thinking it might not >work, is not the best thing to do. > Greg! Right, okay, Ill tell you more. For features being added, where many drivers from different subsystems get covered at once, what they tend to do is: A: send all patches, rely on all maintainers to merge their own crap, which is a mess B: Have a designated merger, who merges all the changes at once, no chance of regression because it's all bundled up. C: send drivers first, then send the feature. So then driver maintainers can merge their crap, then the main feature gets merged in merge window I prefer B, because it's easier that way, akpm is usually des merger hence I CCed him. Or tip tree? Honestly, if I had to be honest, C is a very annoying way, because of what I said above, if driver maintainer thinks I'm some newbie idiot or something, then what will I do? He won't merge it! >thanks, > >greg k-h --- Thanks! https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
On Sat, Sep 05, 2026 at 01:55:35PM +0100, Bradley Morgan wrote: > On 5 September 2026 12:19:54 BST, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > >On Fri, Sep 04, 2026 at 10:13:32PM +0100, Bradley Morgan wrote: > >> On 4 September 2026 22:10:32 BST, Jakub Kicinski <kuba@kernel.org> > >wrote: > >> >On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote: > >> >> On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org> > >> >wrote: > >> >> >On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: > >> >> >> media: ivtv: convert to kthread_run_worker > >> >> >> net: encx24j600: convert to kthread_run_worker > >> >> >> tty: sc16is7xx: convert to kthread_run_worker > >> >> >> cpufreq: schedutil: convert to kthread_create_worker > >> >> > > >> >> >Please send these 4 to appropriate subsystems > >> >> > > >> >> >> kthread: remove worker->task self assignment > >> >> > > >> >> >Then after the next merge window when trees converge send this one > >out > >> >> > >> >> hi, I was hoping one person could merge it with acks from all > >subsystems > >> > > >> >Not how this works. > >> Ugh, I've seen it before happen. > >> > >> Look, fine, I'll do a V3 soon, WITH ONLY the subsystem changes, all > >> separate, all sent over to their respective maintainers, then when all > >> thathas been merged and there's the next merge window, then whatever, > >I'll > >> send then the kthread removal > >> > >> IMHO this is a massive annoyance though.. because what if one of the > >> driverfolks doesn't wanna respond to me!?! > > > >Then, after trying for the normal way, you can make the driver change at > >the same time. But to circumvent the "normal way" thinking it might not > >work, is not the best thing to do. > > > > Greg! > > Right, okay, Ill tell you more. > > For features being added, where many drivers from different subsystems get > covered at once, what they tend to do is: > > A: send all patches, rely on all maintainers to merge their own crap, which is a mess > > B: Have a designated merger, who merges all the changes at once, no chance of regression because it's all bundled up. > > > C: send drivers first, then send the feature. So then driver maintainers can merge their crap, then the main feature gets merged in merge window > > I prefer B, because it's easier that way, akpm is usually des merger hence > I CCed him. > > Or tip tree? > > Honestly, if I had to be honest, C is a very annoying way, because of what > I said above, if driver maintainer thinks I'm some newbie idiot or > something, then what will I do? He won't merge it! To quote a longtime kernel developer years ago, "Kernel development is hard, let's go shopping." Sorry, but yes, it can be difficult to touch cross-subsystem stuff like this, always has been. Just be patient. good luck! greg k-h
On 5 September 2026 18:10:56 BST, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: >On Sat, Sep 05, 2026 at 01:55:35PM +0100, Bradley Morgan wrote: >> On 5 September 2026 12:19:54 BST, Greg Kroah-Hartman >> <gregkh@linuxfoundation.org> wrote: >> >On Fri, Sep 04, 2026 at 10:13:32PM +0100, Bradley Morgan wrote: >> >> On 4 September 2026 22:10:32 BST, Jakub Kicinski <kuba@kernel.org> >> >wrote: >> >> >On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote: >> >> >> On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org> >> >> >wrote: >> >> >> >On Fri, 4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote: >> >> >> >> media: ivtv: convert to kthread_run_worker >> >> >> >> net: encx24j600: convert to kthread_run_worker >> >> >> >> tty: sc16is7xx: convert to kthread_run_worker >> >> >> >> cpufreq: schedutil: convert to kthread_create_worker >> >> >> > >> >> >> >Please send these 4 to appropriate subsystems >> >> >> > >> >> >> >> kthread: remove worker->task self assignment >> >> >> > >> >> >> >Then after the next merge window when trees converge send this >one >> >out >> >> >> >> >> >> hi, I was hoping one person could merge it with acks from all >> >subsystems >> >> > >> >> >Not how this works. >> >> Ugh, I've seen it before happen. >> >> >> >> Look, fine, I'll do a V3 soon, WITH ONLY the subsystem changes, all >> >> separate, all sent over to their respective maintainers, then when >all >> >> thathas been merged and there's the next merge window, then whatever, >> >I'll >> >> send then the kthread removal >> >> >> >> IMHO this is a massive annoyance though.. because what if one of the >> >> driverfolks doesn't wanna respond to me!?! >> > >> >Then, after trying for the normal way, you can make the driver change >at >> >the same time. But to circumvent the "normal way" thinking it might >not >> >work, is not the best thing to do. >> > >> >> Greg! >> >> Right, okay, Ill tell you more. >> >> For features being added, where many drivers from different subsystems >get >> covered at once, what they tend to do is: >> >> A: send all patches, rely on all maintainers to merge their own crap, >which is a mess >> >> B: Have a designated merger, who merges all the changes at once, no >chance of regression because it's all bundled up. >> >> >> C: send drivers first, then send the feature. So then driver maintainers >can merge their crap, then the main feature gets merged in merge window >> >> I prefer B, because it's easier that way, akpm is usually des merger >hence >> I CCed him. >> >> Or tip tree? >> >> Honestly, if I had to be honest, C is a very annoying way, because of >what >> I said above, if driver maintainer thinks I'm some newbie idiot or >> something, then what will I do? He won't merge it! > >To quote a longtime kernel developer years ago, "Kernel development is >hard, let's go shopping." > >Sorry, but yes, it can be difficult to touch cross-subsystem stuff like >this, always has been. Just be patient. > >good luck! Yes. Ack. I feel this is convoluted. (I do mean sashiko did start crying! , sigh) But tbh, B is the best option. For me atleast. Is C a requirement? > >greg k-h --- Thanks! https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
© 2016 - 2026 Red Hat, Inc.