regmap: Disable locking for RBTREE and MAPLE unit tests

PATCH In review Guenter Roeck 4 participants 15 messages Jul 20, 2023 – Jul 21, 2023

Subsystems (3)

Arm Rockchip Driver core Register map abstraction

lore

Share & tools

lore

Guenter Roeck

author

2023-07-20 03:28 UTC #0 lore raw

PATCH 1/2 regmap: Disable locking for RBTREE and MAPLE unit tests

REGCACHE_RBTREE and REGCACHE_MAPLE dynamically allocate memory for regmap operations. This is incompatible with spinlock based locking which is used for fast_io operations. Disable locking for the associated unit tests to avoid lockdep splashes.

Fixes f033c26de5a5 ("regmap: Add maple tree based register cache")

Fixes 2238959b6ad2 ("regmap: Add some basic kunit tests")

Signed-off-by Guenter Roeck <[email protected]>

---
 drivers/base/regmap/regmap-kunit.c | 5 +++++
 1 file changed, 5 insertions(+)

drivers/base/regmap/regmap-kunit.c +5 -0

index 24257aa9004d..9ff3018a46aa 100644
@@ -58,6 +58,9 @@ static struct regmap *gen_regmap(struct regmap_config *config,
 	int i;
 	struct reg_default *defaults;
 
+	config->disable_locking = config->cache_type == REGCACHE_RBTREE ||
+					config->cache_type == REGCACHE_MAPLE;
+
 	buf = kmalloc(size, GFP_KERNEL);
 	if (!buf)
 		return ERR_PTR(-ENOMEM);

@@ -889,6 +892,8 @@ static struct regmap *gen_raw_regmap(struct regmap_config *config,
 
 	config->cache_type = test_type->cache_type;
 	config->val_format_endian = test_type->val_endian;
+	config->disable_locking = config->cache_type == REGCACHE_RBTREE ||
+					config->cache_type == REGCACHE_MAPLE;
 
 	buf = kmalloc(size, GFP_KERNEL);
 	if (!buf)

Signature · 1 line

2.39.2

Guenter Roeck

author

2023-07-20 03:29 UTC #1 lore raw

RFC PATCH 2/2 regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Signed-off-by Guenter Roeck <[email protected]>

---
This seems prudent, given that accesses will be protected by spinlock but may allocate memory with GFP_KERNEL. Another option might be to use WARN_ON instead of rejecting the configuration to avoid hard regressions (and I think both drivers/net/ieee802154/mcr20a.c and sound/soc/codecs/sti-sas.c may be affected, though I can not test it).

 drivers/base/regmap/regmap.c | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/base/regmap/regmap.c +9 -0

index 89a7f1c459c1..b4640285c0b9 100644
@@ -777,6 +777,15 @@ struct regmap *__regmap_init(struct device *dev,
 	} else {
 		if ((bus && bus->fast_io) ||
 		    config->fast_io) {
+			/*
+			 * fast_io is incompatible with REGCACHE_RBTREE and REGCACHE_MAPLE
+			 * since both need to dynamically allocate memory.
+			 */
+			if (config->cache_type == REGCACHE_RBTREE ||
+			    config->cache_type == REGCACHE_MAPLE) {
+				ret = -EINVAL;
+				goto err_name;
+			}
 			if (config->use_raw_spinlock) {
 				raw_spin_lock_init(&map->raw_spinlock);
 				map->lock = regmap_lock_raw_spinlock;

Signature · 1 line

2.39.2

Marek Szyprowski

2023-07-21 14:53 UTC #2 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Hi,

Quoted 11 lines · Guenter Roeck

REGCACHE_RBTREE and REGCACHE_MAPLE dynamically allocate memory for regmap operations. This is incompatible with spinlock based locking which is used for fast_io operations. Reject affected configurations.
Signed-off-by Guenter Roeck <[email protected]>
---
This seems prudent, given that accesses will be protected by spinlock but may allocate memory with GFP_KERNEL. Another option might be to use WARN_ON instead of rejecting the configuration to avoid hard regressions (and I think both drivers/net/ieee802154/mcr20a.c and sound/soc/codecs/sti-sas.c may be affected, though I can not test it).

This patch, which landed in today's linux-next, breaks operation of the RockChip's VOP2 DRM driver (drivers/gpu/drm/rockchip/rockchip_drm_vop2.c). I'm not sure what is the proper fix in this case. Should one change the cache type to REGCACHE_FLAT?

Quoted 13 lines

  drivers/base/regmap/regmap.c | 9 +++++++++
  1 file changed, 9 insertions(+)

drivers/base/regmap/regmap.c +2 -0

index 89a7f1c459c1..b4640285c0b9 100644
@@ -777,6 +777,15 @@ struct regmap *__regmap_init(struct device *dev,
  	} else {
  		if ((bus && bus->fast_io) ||
  		    config->fast_io) {
+			/*
+			 * fast_io is incompatible with REGCACHE_RBTREE and REGCACHE_MAPLE

drivers/base/regmap/regmap.c struct regmap *__regmap_init(struct device *dev, · line 791

Quoted 10 lines

drivers/base/regmap/regmap.c +7 -0

+			 * since both need to dynamically allocate memory.
+			 */
+			if (config->cache_type == REGCACHE_RBTREE ||
+			    config->cache_type == REGCACHE_MAPLE) {
+				ret = -EINVAL;
+				goto err_name;
+			}
  			if (config->use_raw_spinlock) {
  				raw_spin_lock_init(&map->raw_spinlock);
  				map->lock = regmap_lock_raw_spinlock;

Best regards

Signature · 2 lines

Marek Szyprowski, PhD
Samsung R&D Institute Poland

Mark Brown

maintainer

2023-07-21 15:03 UTC #3 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Quoted 4 lines · Marek Szyprowski

This patch, which landed in today's linux-next, breaks operation of the RockChip's VOP2 DRM driver (drivers/gpu/drm/rockchip/rockchip_drm_vop2.c). I'm not sure what is the proper fix in this case. Should one change the cache type to REGCACHE_FLAT?

Actually Guenter and Dan have made the required updates to support this so the warning will be gone soon (hopefully Dan will send his patch properly shortly).

Guenter Roeck

author

2023-07-21 15:07 UTC #4 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Quoted 10 lines · Mark Brown

Quoted 4 lines · Marek Szyprowski
This patch, which landed in today's linux-next, breaks operation of the RockChip's VOP2 DRM driver (drivers/gpu/drm/rockchip/rockchip_drm_vop2.c). I'm not sure what is the proper fix in this case. Should one change the cache type to REGCACHE_FLAT?
Actually Guenter and Dan have made the required updates to support this so the warning will be gone soon (hopefully Dan will send his patch properly shortly).

Do you plan to revert this patch ? If not regmap_init() would still fail for the affected drivers, even after my and Dan's patches have been applied.

Thanks,
Guenter

Mark Brown

maintainer

2023-07-21 15:13 UTC #5 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Quoted 8 lines · Guenter Roeck

Quoted 3 lines · Mark Brown
Actually Guenter and Dan have made the required updates to support this so the warning will be gone soon (hopefully Dan will send his patch properly shortly).
Do you plan to revert this patch ? If not regmap_init() would still fail for the affected drivers, even after my and Dan's patches have been applied.

Yeah. You *can* use the dynamically allocating caches safely if you ensure that no new cache nodes are allocated during I/O. I'd not realised people were actually doing this.

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Guenter Roeck

author

2023-07-21 16:01 UTC #6 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Quoted 7 lines · Mark Brown

Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Mark Brown
Actually Guenter and Dan have made the required updates to support this so the warning will be gone soon (hopefully Dan will send his patch properly shortly).

Quoted 6 lines

Quoted 2 lines
Do you plan to revert this patch ? If not regmap_init() would still fail for the affected drivers, even after my and Dan's patches have been applied.
Yeah. You *can* use the dynamically allocating caches safely if you ensure that no new cache nodes are allocated during I/O. I'd not realised people were actually doing this.

Ok.

Dan, let me know if you don't have time to send a proper patch. I have one based on your suggestion prepared that I could send out if needed.

Thanks,
Guenter

Mark Brown

maintainer

2023-07-21 16:15 UTC #7 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Quoted 11 lines · Guenter Roeck

Quoted 3 lines · Mark Brown
Yeah. You *can* use the dynamically allocating caches safely if you ensure that no new cache nodes are allocated during I/O. I'd not realised people were actually doing this.
Ok.
Dan, let me know if you don't have time to send a proper patch. I have one based on your suggestion prepared that I could send out if needed.

Dan sent the patch already, assuming my CI doesn't blow up unexpectedly it should be applied tonight.

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Guenter Roeck

author

2023-07-21 16:17 UTC #8 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Quoted 7 lines · Mark Brown

Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Mark Brown
Yeah. You *can* use the dynamically allocating caches safely if you ensure that no new cache nodes are allocated during I/O. I'd not realised people were actually doing this.

Quoted 8 lines

Quoted 5 lines
Ok.
Dan, let me know if you don't have time to send a proper patch. I have one based on your suggestion prepared that I could send out if needed.
Dan sent the patch already, assuming my CI doesn't blow up unexpectedly it should be applied tonight.

Excellent.

Thanks,
Guenter

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Dan Carpenter

2023-07-21 16:18 UTC #9 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

In reply to Guenter Roeck

Quoted 3 lines · Guenter Roeck

Dan, let me know if you don't have time to send a proper patch. I have one based on your suggestion prepared that I could send out if needed.

I sent it but, aww crud, I forgot to CC you. Really, get_maintainer.pl should add everyone from the tag section to the CC list...

https://lore.kernel.org/all/[email protected]/

regards,
dan carpenter

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Mark Brown

maintainer

2023-07-21 16:22 UTC #10 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

Quoted 8 lines · Dan Carpenter

Quoted 3 lines · Guenter Roeck
Dan, let me know if you don't have time to send a proper patch. I have one based on your suggestion prepared that I could send out if needed.
I sent it but, aww crud, I forgot to CC you. Really, get_maintainer.pl should add everyone from the tag section to the CC list...

b4 prep --auto-to-cc does that IIRC!

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Guenter Roeck

author

2023-07-21 16:30 UTC #11 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

In reply to Dan Carpenter

Quoted 11 lines · Dan Carpenter

Quoted 3 lines · Guenter Roeck
Dan, let me know if you don't have time to send a proper patch. I have one based on your suggestion prepared that I could send out if needed.
I sent it but, aww crud, I forgot to CC you. Really, get_maintainer.pl should add everyone from the tag section to the CC list...
https://lore.kernel.org/all/[email protected]/

No worries.

Thanks,
Guenter

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Guenter Roeck

author

2023-07-21 15:06 UTC #12 lore raw

Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

In reply to Marek Szyprowski

Quoted 15 lines · Marek Szyprowski

Hi,
Quoted 11 lines · Guenter Roeck
REGCACHE_RBTREE and REGCACHE_MAPLE dynamically allocate memory for regmap operations. This is incompatible with spinlock based locking which is used for fast_io operations. Reject affected configurations.
Signed-off-by Guenter Roeck <[email protected]>
---
This seems prudent, given that accesses will be protected by spinlock but may allocate memory with GFP_KERNEL. Another option might be to use WARN_ON instead of rejecting the configuration to avoid hard regressions (and I think both drivers/net/ieee802154/mcr20a.c and sound/soc/codecs/sti-sas.c may be affected, though I can not test it).

Quoted 5 lines

This patch, which landed in today's linux-next, breaks operation of the RockChip's VOP2 DRM driver (drivers/gpu/drm/rockchip/rockchip_drm_vop2.c). I'm not sure what is the proper fix in this case. Should one change the cache type to REGCACHE_FLAT?

Ah, I missed regcache_init_mmio() when looking for affected drivers. This affects a larger number of drivers than I thought. In addition to the drivers mentioned above,

drivers/soc/qcom/icc-bwmon.c
sound/soc/bcm/bcm2835-i2s.c
sound/soc/codecs/jz4740.c
sound/soc/fsl/fsl_aud2htx.c
sound/soc/fsl/fsl_easrc.c
sound/soc/fsl/fsl_micfil.c

all use unsafe locking (spinlock with REGCACHE_RBTREE).

Thanks,
Guenter

Quoted 26 lines

Quoted 14 lines

   drivers/base/regmap/regmap.c | 9 +++++++++
   1 file changed, 9 insertions(+)

drivers/base/regmap/regmap.c +2 -0

index 89a7f1c459c1..b4640285c0b9 100644
@@ -777,6 +777,15 @@ struct regmap *__regmap_init(struct device *dev,
   	} else {
   		if ((bus && bus->fast_io) ||
   		    config->fast_io) {
+			/*
+			 * fast_io is incompatible with REGCACHE_RBTREE and REGCACHE_MAPLE

drivers/base/regmap/regmap.c struct regmap *__regmap_init(struct device *dev, · line 791

Quoted 10 lines

drivers/base/regmap/regmap.c +7 -0

+			 * since both need to dynamically allocate memory.
+			 */
+			if (config->cache_type == REGCACHE_RBTREE ||
+			    config->cache_type == REGCACHE_MAPLE) {
+				ret = -EINVAL;
+				goto err_name;
+			}
   			if (config->use_raw_spinlock) {
   				raw_spin_lock_init(&map->raw_spinlock);
   				map->lock = regmap_lock_raw_spinlock;

Best regards

Mark Brown

maintainer

2023-07-20 18:19 UTC #13 lore raw

In reply to Guenter Roeck

Quoted 6 lines · Guenter Roeck

REGCACHE_RBTREE and REGCACHE_MAPLE dynamically allocate memory for regmap operations. This is incompatible with spinlock based locking which is used for fast_io operations. Disable locking for the associated unit tests to avoid lockdep splashes.

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next

Thanks!

[1/2] regmap: Disable locking for RBTREE and MAPLE unit tests
(no commit info)
[2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches

      commit: ee43f5bb23340c27603c3ad8ef94f677ad7cb9ad

All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying to this mail.

Thanks,
Mark

Mark Brown

maintainer

2023-07-21 17:41 UTC #14 lore raw

Re: (subset) [PATCH 1/2] regmap: Disable locking for RBTREE and MAPLE unit tests

In reply to Guenter Roeck

Quoted 6 lines · Guenter Roeck

REGCACHE_RBTREE and REGCACHE_MAPLE dynamically allocate memory for regmap operations. This is incompatible with spinlock based locking which is used for fast_io operations. Disable locking for the associated unit tests to avoid lockdep splashes.

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next

Thanks!

[1/2] regmap: Disable locking for RBTREE and MAPLE unit tests

      commit: a9e26169cfda651802f88262a315146fbe4bc74c

If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying to this mail.

Thanks,
Mark