From patchwork Fri Dec 23 11:28:59 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Sverdlin, Alexander" X-Patchwork-Id: 36212 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp271085wrn; Fri, 23 Dec 2022 03:38:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXv/3e+flSEi9CO7viYBiaWH9W0zY03EDMInr2VfV3xXQvx3VPLUgpOfIJOljzYG7uTUAgr9 X-Received: by 2002:aa7:dd13:0:b0:467:6e86:e963 with SMTP id i19-20020aa7dd13000000b004676e86e963mr7168729edv.38.1671795512685; Fri, 23 Dec 2022 03:38:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671795512; cv=none; d=google.com; s=arc-20160816; b=K1H71hom3WxLkwGGGqDVhBHZXB7KHcYJYZgechAGm2TAezSnWxdGbYrtrdP59RxKEF 5bjwFw7Sq5GBjDs7pJ93agileml801pIuhvHMWUazX2KZgkkKCoURLWxY3HZ+AcfvyiM eYp+X9KOjkigc3tBTRMPE+OIDYsNBnucVq5Ve7mBEeZaitqxUCWJmGmfSbdmry+VR8jO 5cmcoG3v2TG3WnduoebEgQCpZhw9KHve1NKgkjWxftt4MdyPLRD2R7FTqYkkWB7tG93Q Ogdme5GruGlaMJVSWBS2V0ewUS47VRBCO1kBGMt20MiPuyZpftuhtTM8foegvbeNEGcJ MN6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:feedback-id:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from:dkim-signature; bh=xslShCd5gPqP/2+ekZx5ArPRn3E72uetbLlpOQ+muGs=; b=Not7aw9TaPzECqBWxHB6Ue8gZP1oRvxHkmpaH4o9Xvfr/l0NhSLbDO5I5/dPnp5xPA hsggFRIpu14sVog47njn/97AKhxIgHWmmxaU6dFsaVDX270TNJfTuYpnb5KhOE+stUiN i/Z54MM13sjxoXMdwWur7k5wBF+LfL5/UnAMikvQ1W7/lRoDOujgpiaf25CTXzmVLje2 r3kPY2+8iQQRzQghD/af/VWY5uFpJhpk7ylkeYkyDsCZu9rl2dZS7GLc8XDskyfIJI+W b3Z7WqqH0i6wlTKMnUGRxW3uKNOix9xIUApChqI+TyMJVT7aEIKf4IESpoWwfzmryfKX Zyuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@siemens.com header.s=fm1 header.b=CurpmO2N; 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=NONE dis=NONE) header.from=siemens.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dr7-20020a170907720700b007c12e19ba40si2302648ejc.666.2022.12.23.03.38.09; Fri, 23 Dec 2022 03:38:32 -0800 (PST) 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=@siemens.com header.s=fm1 header.b=CurpmO2N; 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=NONE dis=NONE) header.from=siemens.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235805AbiLWLaQ (ORCPT + 99 others); Fri, 23 Dec 2022 06:30:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229734AbiLWLaO (ORCPT ); Fri, 23 Dec 2022 06:30:14 -0500 X-Greylist: delayed 61 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 23 Dec 2022 03:30:12 PST Received: from mta-65-225.siemens.flowmailer.net (mta-65-225.siemens.flowmailer.net [185.136.65.225]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E2CE6578 for ; Fri, 23 Dec 2022 03:30:11 -0800 (PST) Received: by mta-65-225.siemens.flowmailer.net with ESMTPSA id 20221223112907bc9b90364b972175f1 for ; Fri, 23 Dec 2022 12:29:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=alexander.sverdlin@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc; bh=xslShCd5gPqP/2+ekZx5ArPRn3E72uetbLlpOQ+muGs=; b=CurpmO2NpxWWhKR/0ZjYld2Qur8hyZFdGNgeBRDqnzBjV3zdPjwCKdgNhx1SFXpELKXyV3 YNXYFSA5RTDMVQAlAdmVqcMShbwdvzwPIfIdn7hEVf1Q4t6pTS48RZ8G5whsc8bcwq2z/Qvp ccfnbuHtoh7bRXuFFNrzTG0gt769E=; From: "A. Sverdlin" To: linux-doc@vger.kernel.org Cc: Alexander Sverdlin , Jonathan Corbet , Federico Vaga , Thomas Gleixner , Ingo Molnar , Manfred Spraul , linux-kernel@vger.kernel.org Subject: [PATCH v2] docs: kernel-hacking: discourage from calling disable_irq() in atomic Date: Fri, 23 Dec 2022 12:28:59 +0100 Message-Id: <20221223112859.937196-1-alexander.sverdlin@siemens.com> MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-456497:519-21489:flowmailer X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753004651327105469?= X-GMAIL-MSGID: =?utf-8?q?1753004651327105469?= From: Alexander Sverdlin Correct the example in documentation so that disable_irq() is not being called in atomic context. disable_irq() calls sleeping synchronize_irq(), it's not allowed to call them in atomic context. Link: https://lore.kernel.org/lkml/87k02wbs2n.ffs@tglx/ Reviewed-by: Manfred Spraul Signed-off-by: Alexander Sverdlin --- Changelog: v2: Dropped changes to manage.c because of already applied https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kernel-irq-managec-disable_irq-might-sleep.patch Documentation/kernel-hacking/locking.rst | 4 ++-- Documentation/translations/it_IT/kernel-hacking/locking.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index 6805ae6e86e65..95fd6e0900d92 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -1274,11 +1274,11 @@ Manfred Spraul points out that you can still do this, even if the data is very occasionally accessed in user context or softirqs/tasklets. The irq handler doesn't use a lock, and all other accesses are done as so:: - spin_lock(&lock); + mutex_lock(&lock); disable_irq(irq); ... enable_irq(irq); - spin_unlock(&lock); + mutex_unlock(&lock); The disable_irq() prevents the irq handler from running (and waits for it to finish if it's currently running on other CPUs). diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 51af37f2d6210..bfbada56cf351 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1309,11 +1309,11 @@ se i dati vengono occasionalmente utilizzati da un contesto utente o da un'interruzione software. Il gestore d'interruzione non utilizza alcun *lock*, e tutti gli altri accessi verranno fatti così:: - spin_lock(&lock); + mutex_lock(&lock); disable_irq(irq); ... enable_irq(irq); - spin_unlock(&lock); + mutex_unlock(&lock); La funzione disable_irq() impedisce al gestore d'interruzioni d'essere eseguito (e aspetta che finisca nel caso fosse in esecuzione su