Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1790231ybb; Thu, 2 Apr 2020 07:26:19 -0700 (PDT) X-Google-Smtp-Source: APiQypKXoO4SZoJv++nObH1lIOyBUlng0J5I1IgkHWxAL1BkH6dHqxiWvsKeVlw5glv2fDJfv8gX X-Received: by 2002:a9d:b8c:: with SMTP id 12mr2574426oth.205.1585837578949; Thu, 02 Apr 2020 07:26:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585837578; cv=none; d=google.com; s=arc-20160816; b=LUXKeUzN1qHzZli2Faa6R8CORsuQx0euRig5f1EKYnlfaqHHwYSJDpZF2RwQSukmuq mITIuiupM2dBEwANwFhpZKMPEWNRFLdh+4Br+L5tf1DBpqNvrNSDi7kd9ttrzAsiNSAR dZjmJ9Q0S5j33D1omDqkRLd6VHmSpeyHh5dTVZAI0izkV221A0oFEuX8bNDFoVZKi1sM nAfcjja5jxrdCHLBV69LJHlvQtXHUPbszNDPktpnTL7yL8svV3yX8dutON0UhBWeiDkM bKIec2PiiEB9+RPxvrzYDQfMmG1XgqIAhAFWKnqbOtXCwQLMNzVg0j+vLBn6tmEBeqht FOsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=lshamTBJRySdW8fNLxBLKIv1ymWDH1p01qFdqB/M9ZE=; b=cA8RPVwK9IDBAr2W982T8vFyvZY/GJ0bMsp1nFNCBvpdqyY5lAi/5kp0xo7rq/LQfD LHi3aWVwg+3+3s1WdGHdMMUtEh3ika4vp9hjH60kPkyCcx1Q5EpYe+cHM4riVo10KgT9 k6ws89tgl/MEjY+7IPabDCnWrHCZunFhPHxqZHLtedwHF2SV02HoRP6lz6S0AVwsCKau WdVddSlYWOeU5+iPCwb/SWjwJXwiym5ply1370oUlhV26mZqhanwp6GDoRKIOkubk/rQ gkPbr/j1dLu8D4auuXb9IofopegM303d9wslp9AVcR4FUDchmpWabvVtir/5BpBggKH0 4GBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h192si2396084oib.166.2020.04.02.07.26.06; Thu, 02 Apr 2020 07:26:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731823AbgDBOZl (ORCPT + 99 others); Thu, 2 Apr 2020 10:25:41 -0400 Received: from netrider.rowland.org ([192.131.102.5]:44551 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1729166AbgDBOZl (ORCPT ); Thu, 2 Apr 2020 10:25:41 -0400 Received: (qmail 12507 invoked by uid 500); 2 Apr 2020 10:18:58 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Apr 2020 10:18:58 -0400 Date: Thu, 2 Apr 2020 10:18:58 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Madhuparna Bhowmik cc: gregkh@linuxfoundation.org, , , , , , Subject: Re: [PATCH] usb: host: u132-hcd: Traverse u132_static_list under mutex lock in u132_hcd_exit In-Reply-To: <20200401191735.10809-1-madhuparnabhowmik10@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2 Apr 2020 madhuparnabhowmik10@gmail.com wrote: > From: Madhuparna Bhowmik > > The global list u132_static_list is protected by u132_module_lock. > Elements are added to this list in the probe function and this list is > traversed in u132_hcd_exit() to unregister devices. > > If probe and exit execute simultaneously there can be a race condition > between writing to this list in probe and reading the list in exit as > u132_module_lock is not held in exit function. > > Even though u132_exiting variable is used in probe to detect if the module is > exiting, it is ineffective as the probe function may read the value > before it is updated in exit and thus leading to a race condition. > > Therefore, hold u132_module_lock while traversing u132_static_list in > exit function. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Madhuparna Bhowmik > --- > drivers/usb/host/u132-hcd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c > index e9209e3e6248..1cadc4e0c9b2 100644 > --- a/drivers/usb/host/u132-hcd.c > +++ b/drivers/usb/host/u132-hcd.c > @@ -3217,10 +3217,10 @@ static void __exit u132_hcd_exit(void) > struct u132 *temp; > mutex_lock(&u132_module_lock); > u132_exiting += 1; > - mutex_unlock(&u132_module_lock); > list_for_each_entry_safe(u132, temp, &u132_static_list, u132_list) { > platform_device_unregister(u132->platform_dev); > } > + mutex_unlock(&u132_module_lock); How about just getting rid of this loop entirely, along with the u132_static_list? As far as I can see, that list doesn't do anything. Not to mention that this driver has no business calling platform_device_unregister() here, since it didn't call platform_device_register() in the first place. The call to platform_driver_unregister() below should do all the necessary work. Alan Stern > platform_driver_unregister(&u132_platform_driver); > printk(KERN_INFO "u132-hcd driver deregistered\n"); > wait_event(u132_hcd_wait, u132_instances == 0);