[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161026210212.09cd85f4@free-electrons.com>
Date: Wed, 26 Oct 2016 21:02:12 +0200
From: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: Antoine Tenart <antoine.tenart@...e-electrons.com>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
pantelis.antoniou@...sulko.com,
Mark Rutland <mark.rutland@....com>, sboyd@...eaurora.org,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC PATCH 1/5] of: introduce the overlay manager
Hello,
On Wed, 26 Oct 2016 10:29:59 -0600, Mathieu Poirier wrote:
> > + overlay = devm_kzalloc(dev, sizeof(*overlay), GFP_KERNEL);
>
> Function devm_kzalloc() can sleep but you're holding a spinlock - I'm
> surprised the kernel didn't complain here. Allocate the memory before
> holding the lock. If the overly is already loaded simply free it on
> the error path.
Actually, I'm not sure using a spinlock here is appropriate. Using a
mutex would probably be better.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Powered by blists - more mailing lists