[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190823154301.GT16384@42.do-not-panic.com>
Date: Fri, 23 Aug 2019 15:43:01 +0000
From: Luis Chamberlain <mcgrof@...nel.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Scott Branden <scott.branden@...adcom.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andy Gross <andy.gross@...aro.org>,
David Brown <david.brown@...aro.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Shuah Khan <shuah@...nel.org>, bjorn.andersson@...aro.org,
"Rafael J . Wysocki" <rafael@...nel.org>,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
Olof Johansson <olof@...om.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
Colin Ian King <colin.king@...onical.com>,
Kees Cook <keescook@...omium.org>,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 3/3] firmware: add mutex fw_lock_fallback for race
condition
On Fri, Aug 23, 2019 at 12:31:40PM +0200, Takashi Iwai wrote:
> So, if any, we'd need put a mutex around the fallback loader code.
> And, the mutex should be rather per device, not a global one.
>
> Or we may trick it by appending the second parallel caller into the
> same wait queue, but the code will be more complex, so I don't think
> worth for it.
For now I'm thinking of a new API with a devname prefix to the driver.
I'll have to test if that works, but not sure if I'll get to it today
before my vacation starts (today).
Luis
Powered by blists - more mailing lists