Received: by 10.192.165.148 with SMTP id m20csp5348743imm; Wed, 9 May 2018 03:40:39 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqynLteImB68T/WtO59biJq/iOL98KK4PZ22rN0321PhNpgTAWqEISFtjO4kn/SrfnIVCw5 X-Received: by 2002:a63:91c4:: with SMTP id l187-v6mr35379167pge.261.1525862439737; Wed, 09 May 2018 03:40:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525862439; cv=none; d=google.com; s=arc-20160816; b=ATImMCviVb7W0P98fCQX/zDXzRrsJDMVj49VXktwecUJJBDxPErDZFdzODXOTQOkNA ma4wDMsxgmNDiFTC0yWixnd0RLquzn52tuTUJhwzfJYN5vvUnMDoiAi5vK4kOVtBAArz 9ocVRVmfs+nzJhGk4Uhc/GQdJ23wKpw20dB0pldtxRuyoVxeT8Njif+OxxmZDw223Get 5+oidhKlHiGnDTEIQfIAoD4R37vBYLY7gOdfWfBSQbb0CuGuoZmi3/j+EYYLV/ntZYCl At3fyN3hngkzRKtnUdwwriJdPRvc6IGp5woQCB91kucTb28HlmT0Hqio9GXsXwyxR99q ypTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=kPHHFKvBzk4l/Bmgofs7DhvyZ+zUOY/f2IGD2sCNkWs=; b=PEq9zRQ3NCQ8P5ub6tVo7BfeNcShrFgLXwpgHSKBp6u4CLiugmRqOH1fntvY7c/8le H+9SYU1mrMPZ+QpMtl9PG/w1bGvma4Em40+u2sYoyo5+4TJCg8TJ1J22KoVX06Wim4C0 WioiB3aWai2qI59C9t7cFtNBpLVPd6E/loqw7FBV/rEZp33Zb4okmBtUDhjCw4aBR0+B X+N/qtIDDrXh0VUzE/ztA2lLFL1IJaW+oP4iSy6YqbhgqLhzXuB7zrzIPB9CKfiB6L7H CoivUIKPvW7ITGjwTMYdQ4BdgplLJ5+WT8k6VBwsI9J8Zty0IpydI45WQuPWXHTsZZIR /biQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=LU5SowOr; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n1-v6si14694212pga.543.2018.05.09.03.40.24; Wed, 09 May 2018 03:40:39 -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; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=LU5SowOr; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934598AbeEIKkO (ORCPT + 99 others); Wed, 9 May 2018 06:40:14 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:39030 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934246AbeEIKkN (ORCPT ); Wed, 9 May 2018 06:40:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kPHHFKvBzk4l/Bmgofs7DhvyZ+zUOY/f2IGD2sCNkWs=; b=LU5SowOr4aU95T+FecK+Nx9U1 7ZVo8E0xSKQPzzc46yTAwT8ns/8xIeka6SwJLNSAl/BNgmFUfGLbDewrj/3UzQW6s/I4k3oDX/jaQ Oc9HKzYBp4Ug9fbhzl86SntMib1itlIX+SWQ4fOTETyZSmNA69huT4vIO+05FxplakfT0=; Received: from n2100.armlinux.org.uk ([2002:4e20:1eda:1:214:fdff:fe10:4f86]:46936) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fGMVq-0003z3-Uy; Wed, 09 May 2018 11:39:59 +0100 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1fGMVn-0003b5-JC; Wed, 09 May 2018 11:39:55 +0100 Date: Wed, 9 May 2018 11:39:54 +0100 From: Russell King - ARM Linux To: Geert Uytterhoeven Cc: Greg Kroah-Hartman , Geert Uytterhoeven , Adrian Salido , Nicolai Stange , Sasha Levin , Todd Kjos , Linux Kernel Mailing List Subject: Re: [PATCH v2 2/4] ARM: amba: Fix race condition with driver_override Message-ID: <20180509103954.GR16141@n2100.armlinux.org.uk> References: <1523366506-19832-1-git-send-email-geert+renesas@glider.be> <1523366506-19832-3-git-send-email-geert+renesas@glider.be> <20180425160645.GA16732@kroah.com> <20180426070410.GM14025@kroah.com> <20180426083542.GA31073@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26, 2018 at 10:45:49AM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > On Thu, Apr 26, 2018 at 10:35 AM, Greg Kroah-Hartman > wrote: > > On Thu, Apr 26, 2018 at 09:40:08AM +0200, Geert Uytterhoeven wrote: > >> On Thu, Apr 26, 2018 at 9:04 AM, Greg Kroah-Hartman > >> wrote: > >> > On Wed, Apr 25, 2018 at 07:53:06PM +0200, Geert Uytterhoeven wrote: > >> >> On Wed, Apr 25, 2018 at 6:06 PM, Greg Kroah-Hartman > >> >> wrote: > >> >> > On Tue, Apr 10, 2018 at 03:21:44PM +0200, Geert Uytterhoeven wrote: > >> >> >> The driver_override implementation is susceptible to a race condition > >> >> >> when different threads are reading vs storing a different driver > >> >> >> override. Add locking to avoid this race condition. > >> >> >> > >> >> >> Cfr. commits 6265539776a0810b ("driver core: platform: fix race > >> >> >> condition with driver_override") and 9561475db680f714 ("PCI: Fix race > >> >> >> condition with driver_override"). > >> >> >> > >> >> >> Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") > >> >> >> Signed-off-by: Geert Uytterhoeven > >> >> >> Reviewed-by: Todd Kjos > >> >> >> Cc: stable > >> >> > >> >> > As this should go to stable kernels, I've fixed it up to apply without > >> >> > patch 1 as that's not a real "fix" that anyone needs... > >> >> > > >> >> > Please try to remember to put fixes first, and then "trivial" things > >> >> > later on in a series. > >> >> > >> >> I did it on purpose, as the fix is much more ugly without patch 1 applied. > >> >> Can't you just take patch 1, too? More consistency is always nice, even for > >> >> stable ;-) > >> > > >> > Consistency is nice, but when you have bug fixes that rely on "trivial" > >> > patches, it's usually not nice :( > >> > > >> > I already committed patch 2 to my tree without 1, so let's leave it > >> > as-is for now. > >> > >> Unfortunately the version you committed is buggy: the race condition > >> also covers the NULL check removed by the trivial patch you skipped, > >> so now you can get inconsistent behavior (no output or "(null)") on the > >> same running kernel version... > >> > >> Please revert and apply both. Thanks! > > > > Ugh, you are right, sorry about that. > > > > I've reverted the offending patch, and added them in the correct order > > now, I should have listened to you :) > > Np, issue detected and fixed. > Thanks! So what about the patches you submitted to the patch system - should I pick those up or not? Please don't ask other maintainers to take patches that have been submitted to the patch system without first changing their status, they're liable to get applied anyway. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up