From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 208F0C433E0 for ; Wed, 12 Aug 2020 01:31:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 00AEF207F7 for ; Wed, 12 Aug 2020 01:31:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=rere.qmqm.pl header.i=@rere.qmqm.pl header.b="alJCAr0f" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726529AbgHLBbg (ORCPT ); Tue, 11 Aug 2020 21:31:36 -0400 Received: from rere.qmqm.pl ([91.227.64.183]:26779 "EHLO rere.qmqm.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726235AbgHLBbg (ORCPT ); Tue, 11 Aug 2020 21:31:36 -0400 Received: from remote.user (localhost [127.0.0.1]) by rere.qmqm.pl (Postfix) with ESMTPSA id 4BRBxf0kNvz8r; Wed, 12 Aug 2020 03:31:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rere.qmqm.pl; s=1; t=1597195894; bh=KiohsbLXRM1ii8+BcDQdtCQAhTchsGUVHj1dkF0VDaE=; h=Date:From:Subject:To:Cc:From; b=alJCAr0fQw0M6FVX28BBbRtXKTOV4J/PvQwkNxVa1DF8r+rUqljXxZPlP87KMY0db TXstkFi9pkMd59OlzCmiEvBOfiNajiKxohYxYAJohPz7ek+ZPEBWsiTt7v89fOqDH7 dYUNJ0/4jm41FOAzpKLrJib/Ehb41ZM0TcAH6cHFOurJXtf+IWPss7jrkTkPy4xv/l O5waxQG+mqF8JU7rGZQGtdTNymFpBCtVxWNmeZHL7Bc4EYWhBbQ99Iom71kgGG97wx UVTBocvLmlBkcesQSBH9E3iK68BSw9/YdjZl+QAo4g2KssS9TiBQ1siUAKsYhrxHk4 +347V+2njHwvA== X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.4 at mail Date: Wed, 12 Aug 2020 03:31:31 +0200 Message-Id: From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= Subject: [PATCH v2 0/7] regulator: fix deadlock vs memory reclaim MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit To: Dmitry Osipenko , Liam Girdwood , Mark Brown , Vladimir Zapolskiy Cc: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For systems that have eg. eMMC storage using voltage regulator, memory reclaim path might call back into regulator subsystem. This means we have to make sure no allocations happen with a regulator or regulator list locked. After this series I see no more lockdep complaints on my test system, but please review and test further. First four patches move allocations out of locked regions, next three came as a drive-by cleanups. --- v2: fix bug in patch #4 spotted by kernel test robot reworded commit #7 description Michał Mirosław (7): regulator: push allocation in regulator_init_coupling() outside of lock regulator: push allocation in regulator_ena_gpio_request() out of lock regulator: push allocations in create_regulator() outside of lock regulator: push allocation in set_consumer_device_supply() out of lock regulator: plug of_node leak in regulator_register()'s error path regulator: cleanup regulator_ena_gpio_free() regulator: remove superfluous lock in regulator_resolve_coupling() drivers/regulator/core.c | 164 +++++++++++++++++++++------------------ 1 file changed, 87 insertions(+), 77 deletions(-) -- 2.20.1