From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Hunter Subject: Re: [PATCH v2] mmc: core: Remove redundant rescan_disable flag Date: Tue, 10 May 2016 12:07:52 +0300 Message-ID: <5731A4E8.5080608@intel.com> References: <1461868156-5734-1-git-send-email-ulf.hansson@linaro.org> <5723AAAB.60109@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com ([134.134.136.65]:49943 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751036AbcEJJSq (ORCPT ); Tue, 10 May 2016 05:18:46 -0400 In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Ulf Hansson Cc: linux-mmc , Jaehoon Chung On 10/05/16 12:01, Ulf Hansson wrote: > On 29 April 2016 at 20:40, Adrian Hunter wrote: >> On 28/04/2016 9:29 p.m., Ulf Hansson wrote: >>> >>> For the reasons explained below, it's safe to remove the rescan_disable >>> flag. >>> >>> 1) >>> cancel_delayed_work_sync() prevents an executing work from re-scheduling >>> itself. >>> >>> 2) >>> We are using the system_freezable_wq for the rescan works. As that queue >>> becomes frozen when userspace becomes frozen during system PM, we don't >>> need to disable the rescan works in the PM_SUSPEND_PREPARE phase. >> >> >> What about the case when a SDIO card has to be removed? Seems like a rescan >> could theoretically get scheduled and run before the workqueue is frozen. > > When the queue gets frozen, it means currently running works will be > synced. Works that are scheduled (or becomes scheduled) will be put on > hold and not allowed to run before the workqueue becomes un-frozen. In the pm_notifier the workqueue is not frozen, so new work could be queued and run, which would potentially race with the "host->bus_ops->remove(host)" a few lines further on.