Hello,
On (09/21/16 10:23), Santosh Shilimkar wrote:
Good that vt works now.Am assuming one of the driver in your test is using the DECLARE_TASKLET
to init the tasklet and killed by tasklet_kill() which leaves that
tasklet to be still scheduled by tasklet action.
yes, vt does something like this (kbd_bh).
Can you please try below patch and see if you still see the issue ?
Attaching the same, just in case mailer eat the tabs.
hm, didn't completely fix it. the vt is now happy, unlike usbnet.
and the usbnet case is rather alarming.Thats really bad that tasklet code is letting users call tasklet_schedule() even without any tasklet_init or DECLARE_TASKLET.
looking at usbnet_probe()
int
usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
{
....
skb_queue_head_init (&dev->done);
skb_queue_head_init(&dev->rxq_pause);
dev->bh.func = usbnet_bh;
dev->bh.data = (unsigned long) dev;
INIT_WORK (&dev->kevent, usbnet_deferred_kevent);
....
first, sometimes tasklet initialisation is performed directly, not via
tasklet_init().
second, that 't->count == 0' eq 'tasklet_init()' is assumed to be sort of
a contract. so a simple kzalloc() works fine, and the patch breaks it.
a simple grep in drivers/net/There are more :-(. Thanks for helping out Sergey.
_next$ git grep tasklet_sched drivers/net/ | awk '{print $1}' | uniq | wc -l
60
_next$ git grep tasklet_init drivers/net/ | awk '{print $1}' | uniq | wc -l
52
and I don't know how many call-sites outside of drivers/net/ do something
like this.