All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, swarren@wwwdotorg.org,
	abrestic@chromium.org, Mark Brown <broonie@kernel.org>,
	linux-tegra@vger.kernel.org, Dylan Reid <dgreid@chromium.org>
Subject: Re: [PATCH] ASoC: tegra: Use flat regcache.
Date: Tue, 18 Mar 2014 11:39:30 +0100	[thread overview]
Message-ID: <53282262.2030300@metafoo.de> (raw)
In-Reply-To: <s5h4n2vssnu.wl%tiwai@suse.de>

On 03/18/2014 11:33 AM, Takashi Iwai wrote:
> 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.

We should still hold the log over the _regmap_write portion of 
regmap_register_patch(), but I think we should otherwise be fine if we make 
it a API requirement that the caller needs to make sure that 
regmap_register_patch() is not called concurrently to itself or to 
regcache_sync().

- Lars

  reply	other threads:[~2014-03-18 10:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18  3:58 [PATCH] ASoC: tegra: Use flat regcache Dylan Reid
     [not found] ` <1395115139-22243-1-git-send-email-dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2014-03-18  4:07   ` Andrew Bresticker
2014-03-18  5:04     ` Dylan Reid
2014-03-18  6:46   ` [alsa-devel] " Takashi Iwai
     [not found]     ` <s5hha6wdmxa.wl%tiwai-l3A5Bk7waGM@public.gmane.org>
2014-03-18 10:28       ` Mark Brown
     [not found]         ` <20140318102858.GE11706-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-03-18 10:33           ` Takashi Iwai
2014-03-18 10:39             ` Lars-Peter Clausen [this message]
     [not found]               ` <53282262.2030300-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2014-03-18 10:44                 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53282262.2030300@metafoo.de \
    --to=lars@metafoo.de \
    --cc=abrestic@chromium.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=dgreid@chromium.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.