On Thu, Jul 16, 2020 at 12:14 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Thu, Jul 16, 2020 at 09:57:18AM +0200, Peter Zijlstra wrote: > > On Wed, Jul 15, 2020 at 08:08:44PM -0700, Kees Cook wrote: > > > Hi, > > > > > > 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. > > > > I would _MUCH_ rather see tasklets go the way of the dodo, esp. given > > that: > > > > > drivers/input/keyboard/omap-keypad.c | 2 +- > > > drivers/input/serio/hil_mlc.c | 2 +- > > > drivers/net/wan/farsync.c | 4 +-- > > > drivers/s390/crypto/ap_bus.c | 2 +- > > > drivers/staging/most/dim2/dim2.c | 2 +- > > > drivers/staging/octeon/ethernet-tx.c | 2 +- > > > drivers/tty/vt/keyboard.c | 2 +- > > > drivers/usb/gadget/udc/snps_udc_core.c | 6 ++--- > > > drivers/usb/host/fhci-sched.c | 2 +- > > > include/linux/interrupt.h | 37 ++++++++++++++++++++++---- > > > kernel/backtracetest.c | 2 +- > > > kernel/debug/debug_core.c | 2 +- > > > kernel/irq/resend.c | 2 +- > > > kernel/softirq.c | 18 ++++++++++++- > > > net/atm/pppoatm.c | 2 +- > > > net/iucv/iucv.c | 2 +- > > > sound/drivers/pcsp/pcsp_lib.c | 2 +- > > > 17 files changed, 66 insertions(+), 25 deletions(-) > > > > there appear to be hardly any users left.. Can't we stage an extinction > > event here instead? > > Oh, I wish, but no. That's just the ones using DECLARE_TASKLET. There > are hundred(s?) more (see the referenced tree). Still, do we really need tasklets? Can we substitute timers executing immediately in their place? Thanks. -- Dmitry _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
