ASoC: tegra: Use flat regcache.

Commit Message

Takashi Iwai March 18, 2014, 6:46 a.m. UTC

At Mon, 17 Mar 2014 20:58:59 -0700,
Dylan Reid wrote:
> 
> When using an rbtree cache, there can be allocations the first time a
> register is accessed.  This can cause an attempt to schedule while
> atomic in the case that the regmap is using a spinlock.  This could be
> fixed by either initializing all the registers or using a flat cache.
> The register maps for tegra30_ahub and tegra30_i2s are dense and don't
> save much from using a tree so convert them to flat.
> 
> Signed-off-by: Dylan Reid <[e-mail]>

Looking through regmap code, the fast_io lock seems broken in more
places, not only via rbtree cache access.  regmap_bulk_write() calls
kmemdup() with GFP_KERNEL in the lock context.  Ditto in
regmap_register_patch(), which calls krealloc() with GFP_KERNEL.

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.


Takashi

Comments

Mark Brown March 18, 2014, 10:28 a.m. UTC | #1

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...

> 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.

Takashi Iwai March 18, 2014, 10:33 a.m. UTC | #2

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

Lars-Peter Clausen March 18, 2014, 10:39 a.m. UTC | #3

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

Mark Brown March 18, 2014, 10:44 a.m. UTC | #4

On Tue, Mar 18, 2014 at 11:39:30AM +0100, Lars-Peter Clausen wrote:
> On 03/18/2014 11:33 AM, Takashi Iwai wrote:

> >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().

Yes, it's just the (re)alloc I was talking about there.

Patch

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 4b2ed0c9e80d..2a1d43e23f1f 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1520,12 +1520,12 @@  int regmap_bulk_write(struct regmap *map, unsigned int reg, const void *val,
 	if (reg % map->reg_stride)
 		return -EINVAL;
 
-	map->lock(map->lock_arg);
 	/*
 	 * Some devices don't support bulk write, for
 	 * them we have a series of single write operations.
 	 */
 	if (!map->bus || map->use_single_rw) {
+		map->lock(map->lock_arg);
 		for (i = 0; i < val_count; i++) {
 			unsigned int ival;
 
@@ -1554,24 +1554,25 @@  int regmap_bulk_write(struct regmap *map, unsigned int reg, const void *val,
 			if (ret != 0)
 				goto out;
 		}
+	out:
+		map->unlock(map->lock_arg);
 	} else {
 		void *wval;
 
 		wval = kmemdup(val, val_count * val_bytes, GFP_KERNEL);
 		if (!wval) {
-			ret = -ENOMEM;
 			dev_err(map->dev, "Error in memory allocation\n");
-			goto out;
+			return -ENOMEM;
 		}
+		map->lock(map->lock_arg);
 		for (i = 0; i < val_count * val_bytes; i += val_bytes)
 			map->format.parse_inplace(wval + i);
 
 		ret = _regmap_raw_write(map, reg, wval, val_bytes * val_count);
 
+		map->unlock(map->lock_arg);
 		kfree(wval);
 	}
-out:
-	map->unlock(map->lock_arg);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(regmap_bulk_write);