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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Jul 2023 16:53:42 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Guenter Roeck <linux@...ck-us.net>, Mark Brown <broonie@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
        Heiko Stuebner <heiko@...ech.de>,
        Andy Yan <andy.yan@...k-chips.com>,
        Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations
 with RBTREE and MAPLE caches

Hi,

On 20.07.2023 05:28, Guenter Roeck wrote:
> 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 <linux@...ck-us.net>
> ---
> 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?


>   drivers/base/regmap/regmap.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index 89a7f1c459c1..b4640285c0b9 100644
> --- a/drivers/base/regmap/regmap.c
> +++ b/drivers/base/regmap/regmap.c
> @@ -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;

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland