From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:59230 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753104AbeDJJJ7 (ORCPT ); Tue, 10 Apr 2018 05:09:59 -0400 Subject: Patch "vmxnet3: ensure that adapter is in proper state during force_close" has been added to the 4.4-stable tree To: nhorman@tuxdriver.com, alexander.levin@microsoft.com, davem@davemloft.net, gregkh@linuxfoundation.org, pv-drivers@vmware.com, skhare@vmware.com Cc: , From: Date: Tue, 10 Apr 2018 11:07:11 +0200 Message-ID: <152335123122782@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled vmxnet3: ensure that adapter is in proper state during force_close to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: vmxnet3-ensure-that-adapter-is-in-proper-state-during-force_close.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Neil Horman Date: Fri, 12 May 2017 12:00:01 -0400 Subject: vmxnet3: ensure that adapter is in proper state during force_close From: Neil Horman [ Upstream commit 1c4d5f51a812a82de97beee24f48ed05c65ebda5 ] There are several paths in vmxnet3, where settings changes cause the adapter to be brought down and back up (vmxnet3_set_ringparam among them). Should part of the reset operation fail, these paths call vmxnet3_force_close, which enables all napi instances prior to calling dev_close (with the expectation that vmxnet3_close will then properly disable them again). However, vmxnet3_force_close neglects to clear VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and leaves all the napi instances in a enabled state while the device itself is closed. If a device in this state is activated again, napi_enable will be called on already enabled napi_instances, leading to a BUG halt. The fix is to simply enausre that the QUIESCED bit is cleared in vmxnet3_force_close to allow quesence to be completed properly on close. Signed-off-by: Neil Horman CC: Shrikrishna Khare CC: "VMware, Inc." CC: "David S. Miller" Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/net/vmxnet3/vmxnet3_drv.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/vmxnet3/vmxnet3_drv.c +++ b/drivers/net/vmxnet3/vmxnet3_drv.c @@ -2789,6 +2789,11 @@ vmxnet3_force_close(struct vmxnet3_adapt /* we need to enable NAPI, otherwise dev_close will deadlock */ for (i = 0; i < adapter->num_rx_queues; i++) napi_enable(&adapter->rx_queue[i].napi); + /* + * Need to clear the quiesce bit to ensure that vmxnet3_close + * can quiesce the device properly + */ + clear_bit(VMXNET3_STATE_BIT_QUIESCED, &adapter->state); dev_close(adapter->netdev); } Patches currently in stable-queue which might be from nhorman@tuxdriver.com are queue-4.4/x86-asm-don-t-use-rbp-as-a-temporary-register-in-csum_partial_copy_generic.patch queue-4.4/vmxnet3-ensure-that-adapter-is-in-proper-state-during-force_close.patch