Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp2998036rwe; Mon, 29 Aug 2022 04:16:32 -0700 (PDT) X-Google-Smtp-Source: AA6agR4+kZw4j7qV/Ecakk61pZ367K8bYRXfpJTPSyRqHVGK7x53cJU/SdLKzxOQDLKQCIkLlchu X-Received: by 2002:a05:6402:2b8b:b0:43a:5475:f1ae with SMTP id fj11-20020a0564022b8b00b0043a5475f1aemr15969475edb.363.1661771792201; Mon, 29 Aug 2022 04:16:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661771792; cv=none; d=google.com; s=arc-20160816; b=OwQu9YDMriGTDfJcafSwxC82RDQ9ELsQAIOuD6r8pqDuVwqy7FjE6F95MZCvwQrYgE ghqJcSSz4b8TdQVA6Bl9j3wLO+/++XVghB2UeA8bGTACUaRLOH6JJRx6lv58c9cakH7m TehbtZ8P/ZHWpweERh5I5PsaCpO4Wj/Odl2i37fISdQ0NG21Usbtkb/LhPLhnFmsNVMV ltAid2zxUs/QP8EPswIgWiRzvFbecWAiGNx6Cx5+qvfAntjHJOe8HkQmwNd1cVaM9Swt skQUKuK9efVwJyY6unNH5yvMu818ioajCjyHAOct68AMXE0cElCzjCVKRJpfR2U6sMAl +MTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=oyLuIO191oPFAdUBGExhG1LQql3RLJYD3yyEkPdMHco=; b=HCMqcwQ0ytwWhlMj5kkUWeDyxir4dUELE5bLcNpI8xcU3rI1OiwWXprIb6Tzdx815N fRSftuuPGq4fNoS5GG0XjTGwACskSQnFoHRh1em2M4BbiHgPegvp9pWi/c8CZ5DOosaI crw0K8JuZNbjch5fW61fYGE/dAUTHpqTXR5MrvQ0cn+PfqkbNmT8fAdFLQxmM1SNbRU6 XPRWJukC2Dm+CIq1jqw275e5H896hKMgM3tlU7+LIBaFU5Wz07Ij6T80chwZ+ypyux8D 8OgErLaFI+6hIk4dYt/1f8tp2AebyyBU4iYjXS37MF4cej3zCtGYPeiz7dt/fFfGra4e 2FTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Z6etRM3q; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oz10-20020a1709077d8a00b0073d9f16e5b3si1639149ejc.258.2022.08.29.04.16.02; Mon, 29 Aug 2022 04:16:32 -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=20210112 header.b=Z6etRM3q; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229879AbiH2K2f (ORCPT + 99 others); Mon, 29 Aug 2022 06:28:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbiH2K2c (ORCPT ); Mon, 29 Aug 2022 06:28:32 -0400 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C56621EC78; Mon, 29 Aug 2022 03:28:31 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id cb8so5780673qtb.0; Mon, 29 Aug 2022 03:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=oyLuIO191oPFAdUBGExhG1LQql3RLJYD3yyEkPdMHco=; b=Z6etRM3qVay6FXg/5ukZMy7N+xR7PZrZ+XB/D0gGD0u7hKq3bHVsmuECXZnwfyzUoQ m4AMuGXv7OIiRbd8/DnBeHmLx5j31ixAupPW0Z68EkdbONeei8sN9ers5iuLQnu2UEg3 Wpv4nUqB9Vmq1PDcLaC4rzkkfjmW4iOCQVTD4EozDrlyq7HCauIoq0M+6dIJMxmD1iVp lW4/9Qi742JVlDGtfRRJrTTxxMaDZv+sYCqwSg67LXR9EvAmSJNKMRi8dGwiO9DAdUVH +UCa8dVmjULb2C+ZjjJHx9YKn0RAsSwhgZt1wAhsrsTHBgmQ3pKVdpLC9SsjzsWf8oy/ lJrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=oyLuIO191oPFAdUBGExhG1LQql3RLJYD3yyEkPdMHco=; b=17jyALbkzkkezfrenElUcvwaJ+UNcdjpZCbh43qr2yYGurQP81MQesy2tZqI9QHPyF f73IYSiLTAtobb5rPWP+GeAS6dwdGxmWfIh3Lj/G77+Jr9Ej2ytxDZDMIgg1BMrkEJO1 ElPEZ7xEzwkBe3FEX+fE9eKzoxmJTuye8Nc7SLqNG2U586ckRCaKXz3M3mAsmu0wD5Tn A5AeLNJAr4pljQPOinkTHejlETuXoRFG7rn58IYs8i1ELk7fKw2t1U4X6pBm3F3Edkvr xB5plK5vjHUpt2+P/KOwlN2DO/ZtjuFA5akpl0lYqR2BFke/aPo1EyrDaofLtgBjPokm mOPA== X-Gm-Message-State: ACgBeo0tVZ6KfB+q+BXJpPM2fSu0F/P2q3ZgL7P3jqs6P8iuJzkgwR1T W/559S8Bz4x2mQHitSuPKAQItQwJXzay4Lxia80= X-Received: by 2002:a05:622a:491:b0:344:95bf:8f05 with SMTP id p17-20020a05622a049100b0034495bf8f05mr9567065qtx.61.1661768910839; Mon, 29 Aug 2022 03:28:30 -0700 (PDT) MIME-Version: 1.0 References: <20220829091840.2791846-1-vincent.whitchurch@axis.com> In-Reply-To: <20220829091840.2791846-1-vincent.whitchurch@axis.com> From: Andy Shevchenko Date: Mon, 29 Aug 2022 13:27:54 +0300 Message-ID: Subject: Re: [PATCH v2] iio: Use per-device lockdep class for mlock To: Vincent Whitchurch Cc: Jonathan Cameron , kernel@axis.com, Lars-Peter Clausen , Matt Ranostay , linux-iio , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 29, 2022 at 12:18 PM Vincent Whitchurch wrote: > > If an IIO driver uses callbacks from another IIO driver and calls > iio_channel_start_all_cb() from one of its buffer setup ops, then > lockdep complains due to the lock nesting, as in the below example with > lmp91000. > > Since the locks are being taken on different IIO devices, there is no > actual deadlock. Fix the warning by telling lockdep to use a different > class for each iio_device. > > ============================================ > WARNING: possible recursive locking detected > -------------------------------------------- > python3/23 is trying to acquire lock: > (&indio_dev->mlock){+.+.}-{3:3}, at: iio_update_buffers > > but task is already holding lock: > (&indio_dev->mlock){+.+.}-{3:3}, at: enable_store > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&indio_dev->mlock); > lock(&indio_dev->mlock); > > *** DEADLOCK *** > > May be due to missing lock nesting notation > > 5 locks held by python3/23: > #0: (sb_writers#5){.+.+}-{0:0}, at: ksys_write > #1: (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter > #2: (kn->active#14){.+.+}-{0:0}, at: kernfs_fop_write_iter > #3: (&indio_dev->mlock){+.+.}-{3:3}, at: enable_store > #4: (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_update_buffers > > Call Trace: > __mutex_lock > iio_update_buffers > iio_channel_start_all_cb > lmp91000_buffer_postenable > __iio_update_buffers > enable_store This looks much better than the previous version, thanks! Reviewed-by: Andy Shevchenko > Fixes: 67e17300dc1d76 ("iio: potentiostat: add LMP91000 support") > Signed-off-by: Vincent Whitchurch > --- > > Notes: > v2: > - Use a different lockdep class for each iio_device, instead of using > mutex_lock_nested. > - Add fixes tag pointing to first IIO driver which used this API. > - Trim call stack in commit message. > > drivers/iio/industrialio-core.c | 5 +++++ > include/linux/iio/iio-opaque.h | 2 ++ > 2 files changed, 7 insertions(+) > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c > index 0f4dbda3b9d3..921d8e8643a2 100644 > --- a/drivers/iio/industrialio-core.c > +++ b/drivers/iio/industrialio-core.c > @@ -1621,6 +1621,8 @@ static void iio_dev_release(struct device *device) > > iio_device_detach_buffers(indio_dev); > > + lockdep_unregister_key(&iio_dev_opaque->mlock_key); > + > ida_free(&iio_ida, iio_dev_opaque->id); > kfree(iio_dev_opaque); > } > @@ -1680,6 +1682,9 @@ struct iio_dev *iio_device_alloc(struct device *parent, int sizeof_priv) > INIT_LIST_HEAD(&iio_dev_opaque->buffer_list); > INIT_LIST_HEAD(&iio_dev_opaque->ioctl_handlers); > > + lockdep_register_key(&iio_dev_opaque->mlock_key); > + lockdep_set_class(&indio_dev->mlock, &iio_dev_opaque->mlock_key); > + > return indio_dev; > } > EXPORT_SYMBOL(iio_device_alloc); > diff --git a/include/linux/iio/iio-opaque.h b/include/linux/iio/iio-opaque.h > index 6b3586b3f952..d1f8b30a7c8b 100644 > --- a/include/linux/iio/iio-opaque.h > +++ b/include/linux/iio/iio-opaque.h > @@ -11,6 +11,7 @@ > * checked by device drivers but should be considered > * read-only as this is a core internal bit > * @driver_module: used to make it harder to undercut users > + * @mlock_key: lockdep class for iio_dev lock > * @info_exist_lock: lock to prevent use during removal > * @trig_readonly: mark the current trigger immutable > * @event_interface: event chrdevs associated with interrupt lines > @@ -42,6 +43,7 @@ struct iio_dev_opaque { > int currentmode; > int id; > struct module *driver_module; > + struct lock_class_key mlock_key; > struct mutex info_exist_lock; > bool trig_readonly; > struct iio_event_interface *event_interface; > -- > 2.34.1 > -- With Best Regards, Andy Shevchenko