[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190215015431.GK69686@sasha-vm>
Date: Thu, 14 Feb 2019 20:54:31 -0500
From: Sasha Levin <sashal@...nel.org>
To: Kimberly Brown <kimbrownkd@...il.com>
Cc: Dexuan Cui <decui@...rosoft.com>,
Michael Kelley <mikelley@...rosoft.com>,
Long Li <longli@...rosoft.com>,
Sasha Levin <Alexander.Levin@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show
functions
On Sat, Feb 02, 2019 at 03:07:35PM -0500, Kimberly Brown wrote:
>On Fri, Feb 01, 2019 at 06:24:24PM +0000, Dexuan Cui wrote:
>> > From: Kimberly Brown <kimbrownkd@...il.com>
>> > Sent: Thursday, January 31, 2019 9:47 AM
>> > ...
>> > 2) Prevent a deadlock that can occur between the proposed mutex_lock()
>> > call in the vmbus_chan_attr_show() function and the sysfs/kernfs functions.
>> Hi Kim,
>> Can you please share more details about the deadlock?
>> It's unclear to me how the deadlock happens.
>>
>
>Hi Dexuan,
>
>I encountered the deadlock by:
>1) Adding a call to msleep() before acquiring the mutex in
>vmbus_chan_attr_show()
>2) Opening a hv_netvsc subchannel's sysfs file
>3) Removing hv_netvsc while the sysfs file is opening
Dexuan, any objections to pulling this fix in?
--
Thanks,
Sasha
Powered by blists - more mailing lists