From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Dexuan Cui <decui@microsoft.com>
Cc: "gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"Stephen Hemminger" <sthemmin@microsoft.com>,
KY Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
"driverdev-devel\@linuxdriverproject.org"
<driverdev-devel@linuxdriverproject.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vmbus: remove hv_event_tasklet_disable/enable
Date: Fri, 03 Mar 2017 17:40:47 +0100 [thread overview]
Message-ID: <874lzal3e8.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <MWHPR03MB26699FBC9D517E40155C202FBF280@MWHPR03MB2669.namprd03.prod.outlook.com> (Dexuan Cui's message of "Thu, 2 Mar 2017 12:32:55 +0000")
Dexuan Cui <decui@microsoft.com> writes:
> With the recent introduction of per-channel tasklet, we need to update
> the way we handle the 3 concurrency issues:
>
> 1. hv_process_channel_removal -> percpu_channel_deq vs.
> vmbus_chan_sched -> list_for_each_entry(..., percpu_list);
>
> 2. vmbus_process_offer -> percpu_channel_enq/deq vs. vmbus_chan_sched.
>
> 3. vmbus_close_internal vs. the per-channel tasklet vmbus_on_event;
>
> The first 2 issues can be handled by Stephen's recent patch
> "vmbus: use rcu for per-cpu channel list", and the third issue
> can be handled by calling tasklet_disable in vmbus_close_internal here.
>
> We don't need the original hv_event_tasklet_disable/enable since we
> now use per-channel tasklet instead of the previous per-CPU tasklet,
> and actually we must remove them due to the side effect now:
> vmbus_process_offer -> hv_event_tasklet_enable -> tasklet_schedule will
> start the per-channel callback prematurely, cauing NULL dereferencing
> (the channel may haven't been properly configured to run the callback yet).
>
> Fixes: 631e63a9f346 ("vmbus: change to per channel tasklet")
>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Cc: "K. Y. Srinivasan" <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
This patch fixes the following crash on boot:
[ 1.451648] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
[ 1.452255] IP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
[ 1.452255] PGD 0
[ 1.452255]
[ 1.452255] Oops: 0000 [#1] SMP
[ 1.452255] Modules linked in: hv_storvsc hv_netvsc(+) scsi_transport_fc hyperv_fb hyperv_keyboard hid_hyperv hv_vmbus
[ 1.452255] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 4.10.0_test+ #911
[ 1.452255] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
[ 1.452255] task: ffff880007fd2b00 task.stack: ffffc90000e34000
[ 1.452255] RIP: 0010:netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
...
[ 1.452255] Call Trace:
[ 1.452255] vmbus_on_event+0x22/0x90 [hv_vmbus]
[ 1.452255] tasklet_action+0x5e/0x110
[ 1.452255] __do_softirq+0x104/0x2af
[ 1.452255] run_ksoftirqd+0x29/0x40
...
[ 1.548068] RIP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc] RSP: ffffc90000e37d88
[ 1.548068] CR2: 0000000000000004
[ 1.548068] ---[ end trace 601fd9d6588b21e5 ]---
[ 1.548068] Kernel panic - not syncing: Fatal exception in interrupt
[ 1.548068] Kernel Offset: disabled
[ 1.548068] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
[ 1.572155] ------------[ cut here ]------------
The crash is not imminent but it happens pretty often on boot, I think
we need to push it to 4.11.
--
Vitaly
next prev parent reply other threads:[~2017-03-03 16:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 12:32 [PATCH] vmbus: remove hv_event_tasklet_disable/enable Dexuan Cui
2017-03-03 16:40 ` Vitaly Kuznetsov [this message]
2017-03-03 17:12 ` Stephen Hemminger
2017-03-17 23:15 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874lzal3e8.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=decui@microsoft.com \
--cc=driverdev-devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sthemmin@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.