[RFC,2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches
Message ID | 20230720032848.1306349-2-linux@roeck-us.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp2874767vqt; Wed, 19 Jul 2023 21:20:49 -0700 (PDT) X-Google-Smtp-Source: APBJJlExqiJLCiqrSiwbyrUGhHgAeU7pEx4Fs9jLw6EwWxPt4HlnuQWaquiEzKq8sqZ2zP8Y5V8r X-Received: by 2002:a17:906:10d0:b0:994:4e9c:30cc with SMTP id v16-20020a17090610d000b009944e9c30ccmr1383545ejv.39.1689826849758; Wed, 19 Jul 2023 21:20:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689826849; cv=none; d=google.com; s=arc-20160816; b=ofaVQ0bluGTdjX8Y08apKksFeQbUahWY9JLepIBjUY1xztDUaUWCy9fpoR0u4xC5JA ed2sfziSmFgqERsgCQclgb+cymp3Db/NxO1/PH26lZvht2O8xsHhIoAISI4qablNolzz U2RM8Asqi3qjDbPiU9GmgcOdb8CahLRl1nzDwoBCngl/SEr0uZpnrGWn040fKeTYsz/9 gPa3W8f+vtTnQv1t1cPQF7xaisZO06Q2WtaazKtiWSHVhMoqFzhkQzMtYxg4OJoJ+iH8 N8hlm+irS5p1Is6dsG9jxRUtI9g0ABgETRYE4Ambq1dUQYgCwJUeISmaTowMFZLOQS2B gvtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from:sender :dkim-signature; bh=L0oNMuifMnagYqKrM9m6tne2TXEDYzPsYeKHQDjncmo=; fh=JuR3MKiWAj55R51kzxw12G54eDCo8KRHpj6+qbYT4gc=; b=ZzMTHOrrw77XJQis5UJ1rsiimpa64OEBF2dAetADEVvWp1nAIQ8SDf9svu3b+wPxd7 YnNQt+6hDkSKClPKQ+lJeeCKfVF5aCIzhdWX0M6DBQvKBDSbTh39C2cThbnltoElUA7B Uio3KSr7+2VtkcALNtg/9jHiMWlhW8E+AuVqcZWiY3HgpH0NkU0IsRulaFHO60G8csxc BqDPzyV8chktYdDhdpBIbKpYC3Pb+TAZauO3ccabQzfmfh8eBIx1VP5ejvrz+o8aI2cI EyCoYu1kkTjSfrujYQY0Shv3FF8FJs8poWQdMRrkdm2Mk75jA/SWSiJqfLwEGpyZDSws isQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=M4HqC7jN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y13-20020a170906070d00b0098cd2a20b3esi70485ejb.847.2023.07.19.21.20.26; Wed, 19 Jul 2023 21:20:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=M4HqC7jN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229835AbjGTD26 (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Wed, 19 Jul 2023 23:28:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbjGTD2y (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Jul 2023 23:28:54 -0400 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F42231B9 for <linux-kernel@vger.kernel.org>; Wed, 19 Jul 2023 20:28:53 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-5577004e21bso115123a12.2 for <linux-kernel@vger.kernel.org>; Wed, 19 Jul 2023 20:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689823733; x=1692415733; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=L0oNMuifMnagYqKrM9m6tne2TXEDYzPsYeKHQDjncmo=; b=M4HqC7jN8AZVdfqhxjxnS/wDHCfOln+PN29vS+/sLBxxp714NS48ojlUBY7qv1rfht 9UVzKpFmyW0hblPll1g+fVFC7iM2Vqz75okVG0ntCj9DnNl4x/sAwxXevZUGL62ntnnj XKvGeQSxtP+o3Lkm6frKkX4WoxUfTaKNOxqTtic1eBR5RCLrDtUS0nzxr5qPFED25pDI OrT/VxxHfn8UETIjYwLhYgtQ9uVASRH5JQ+00tPVEGd/0K4L4f5zoF6oacNS8LwVOlOo uxAdy+vOQBu6QDvBOcuSyD9A/3aOdBuhfAmCJBcEvu/678B7QrksujMuAonWmxmwbXwT Agrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689823733; x=1692415733; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=L0oNMuifMnagYqKrM9m6tne2TXEDYzPsYeKHQDjncmo=; b=gNQ9lfi30D9Gzl5MMlLBQ/b0GgF0kifIjBaew+F2ehYtlhF5EGgl8FZJy5I5tQMhrn 48uqRjqsisNnb9hrMZfj5GNMmCUFzYR5LFM3RitPGwsx61tDBHumhslGRXWiFRg5Ev0s c6Ir4whHn1lLa62wqq6pW5rtrp9JP5XtZ4KZ3wsU4FdO6x8WRylctaPKexUCMG+m8Tq+ Y6bbTBDq17TZBZct3Zr1bCYJ+OWZVstrk1sz3miH+Os3Jx9woK4QFL9Lo27SmRdfp2gO Xc+k2Fj1McSOOcRgPurBppscru4MHqYYKhp+VnncVuYJWV3IFgiBS4P6hbmuDpQ5iure ZMqQ== X-Gm-Message-State: ABy/qLZGKctTOdk9dBZyZyOPkUecz69rzjBT7mV3+LFXgYoWaRidGT1u IyVpc7i9avvDztAUSbK4e4Y= X-Received: by 2002:a05:6a20:3d22:b0:133:5352:c7ac with SMTP id y34-20020a056a203d2200b001335352c7acmr8195018pzi.38.1689823733344; Wed, 19 Jul 2023 20:28:53 -0700 (PDT) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id f3-20020a17090274c300b001b80b428d4bsm23225plt.67.2023.07.19.20.28.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 20:28:52 -0700 (PDT) Sender: Guenter Roeck <groeck7@gmail.com> From: Guenter Roeck <linux@roeck-us.net> To: Mark Brown <broonie@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J . Wysocki" <rafael@kernel.org>, linux-kernel@vger.kernel.org, Guenter Roeck <linux@roeck-us.net> Subject: [RFC PATCH 2/2] regmap: Reject fast_io regmap configurations with RBTREE and MAPLE caches Date: Wed, 19 Jul 2023 20:28:48 -0700 Message-Id: <20230720032848.1306349-2-linux@roeck-us.net> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230720032848.1306349-1-linux@roeck-us.net> References: <20230720032848.1306349-1-linux@roeck-us.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771911878391187345 X-GMAIL-MSGID: 1771911878391187345 |
Series |
[1/2] regmap: Disable locking for RBTREE and MAPLE unit tests
|
|
Commit Message
Guenter Roeck
July 20, 2023, 3:28 a.m. UTC
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@roeck-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).
drivers/base/regmap/regmap.c | 9 +++++++++
1 file changed, 9 insertions(+)
Comments
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@roeck-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
On Fri, Jul 21, 2023 at 04:53:42PM +0200, Marek Szyprowski wrote: > 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).
On 7/21/23 07:53, Marek Szyprowski wrote: > 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@roeck-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? > 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 > >> 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
On 7/21/23 08:03, Mark Brown wrote: > On Fri, Jul 21, 2023 at 04:53:42PM +0200, Marek Szyprowski wrote: > >> 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
On Fri, Jul 21, 2023 at 08:07:28AM -0700, Guenter Roeck wrote: > On 7/21/23 08:03, Mark Brown wrote: > > 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.
On 7/21/23 08:13, Mark Brown wrote: > On Fri, Jul 21, 2023 at 08:07:28AM -0700, Guenter Roeck wrote: >> On 7/21/23 08:03, Mark Brown wrote: > >>> 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. 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
On Fri, Jul 21, 2023 at 09:01:03AM -0700, Guenter Roeck wrote: > On 7/21/23 08:13, Mark Brown wrote: > > 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.
On Fri, Jul 21, 2023 at 05:14:42PM +0100, Mark Brown wrote: > On Fri, Jul 21, 2023 at 09:01:03AM -0700, Guenter Roeck wrote: > > On 7/21/23 08:13, Mark Brown wrote: > > > > 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. Excellent. Thanks, Guenter
On Fri, Jul 21, 2023 at 09:01:03AM -0700, Guenter Roeck wrote: > 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/58f12a07-5f4b-4a8f-ab84-0a42d1908cb9@moroto.mountain/ regards, dan carpenter
On Fri, Jul 21, 2023 at 07:18:03PM +0300, Dan Carpenter wrote: > On Fri, Jul 21, 2023 at 09:01:03AM -0700, Guenter Roeck wrote: > > 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!
On 7/21/23 09:18, Dan Carpenter wrote: > On Fri, Jul 21, 2023 at 09:01:03AM -0700, Guenter Roeck wrote: > >> 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/58f12a07-5f4b-4a8f-ab84-0a42d1908cb9@moroto.mountain/ > No worries. Thanks, Guenter
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;