From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [alsa-devel] [PATCH] ASoC: tegra: Use flat regcache. Date: Tue, 18 Mar 2014 11:33:09 +0100 Message-ID: References: <1395115139-22243-1-git-send-email-dgreid@chromium.org> <20140318102858.GE11706@sirena.org.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20140318102858.GE11706-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mark Brown Cc: Dylan Reid , alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org List-Id: alsa-devel@alsa-project.org At Tue, 18 Mar 2014 10:28:58 +0000, Mark Brown wrote: > > On Tue, Mar 18, 2014 at 07:46:09AM +0100, Takashi Iwai wrote: > > > kmemdup() with GFP_KERNEL in the lock context. Ditto in > > regmap_register_patch(), which calls krealloc() with GFP_KERNEL. > > So send a patch... Yeah, yeah, don't rush :) > > The former could be fixed by moving the lock like below. The fix for > > the latter depends on whether we need to protect map->patch_regs > > growth from races or not. If not, krealloc() can be moved out of the > > lock. > > It should only be happening on init so probably not. On the other hand > doing it without any sort of locking isn't great. Right. OTOH, it's still better than papering over with GFP_ATOMIC, I think. We can just give a proper note in the function description, for example. Takashi