From patchwork Wed Sep 20 10:46:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sebastian Andrzej Siewior X-Patchwork-Id: 142388 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp4097159vqi; Wed, 20 Sep 2023 05:25:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHygFC01ZVaKR6l4gUZ8hZ20GUOF1cbF1NTvMOwoWOxpRHE6IVnBXIjaJTOb7JWmC34tlQA X-Received: by 2002:a17:902:c407:b0:1c4:6613:82a3 with SMTP id k7-20020a170902c40700b001c4661382a3mr2016063plk.16.1695212714861; Wed, 20 Sep 2023 05:25:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695212714; cv=none; d=google.com; s=arc-20160816; b=PYhPfhLR4ltjFk7xU1mhfFAvhMsXfWZqlhAhZn5xfEb+7pP0lYp2NJQHDuLgzUP1H3 Uw8HXYSaK38pBc6ir0K4lSbJjwRmUasaLIh6Yu0WMppTX7ZRHFCkIuS9otYU5ZsgA5Fm /rexpmvjIxe6k+jX4yZ8eh1r7a9K0z+xeAsSCwfY+lBNojzbvfGJbLXf9Ug+bvaYyKhZ gbUUyVpYUteVXSynw+i/+SleTcuNWOriPaF+bykr+yaukhCOw/cOEUsrSxIlo4/sxGT1 9TrXqOrup+tmsFLzLAtrgl4FKxloH5GKyL5ijowqC2KyCYv+1G98BdtNVOS1LQPCH3Wn W37A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:dkim-signature:dkim-signature:date; bh=wAGWwRdw1kc9xidRjeEttNJpxiDPA74+rQRMxWuGmyM=; fh=WSSN1YuT60CRkNYJ/GravGmfiJXGSaGVA+yT0fkjzmc=; b=bd6eaFyF42848YqTY/hHIFoIpYeI+o/LRET18fW7NrHUqJwGiuYeBaBB4kJ830T1mZ JC56F6bmY7Jd8ikz+poZppcwbwLSBno9pbVDGP56uIOe+wIIoBaFB2hbildGpFFheWxk L23TETn/iJjumRGRqgU0xMDYCqBZdZ4RheZrRR2Afwm6F5DKQcba3RQX+z0wBg1q/12Y ZprLIZG60SHqRvNxWW/Sr0cV33QMsTNOhMePJxsLTgLaBGeUHCVBNZl+JBb2kjaNFn2t iP21rZ52sPyLxfyZ6HLmd3o27tfJacfHKrZX7obEbk4QsOlbOAXXMmnnWQGC5Vrgn5Q9 9SOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=oTVlk4LA; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id r18-20020a170902be1200b001b5589848absi11626122pls.234.2023.09.20.05.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 05:25:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=oTVlk4LA; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 29ACC82922E0; Wed, 20 Sep 2023 03:47:37 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234424AbjITKra (ORCPT + 26 others); Wed, 20 Sep 2023 06:47:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234368AbjITKq7 (ORCPT ); Wed, 20 Sep 2023 06:46:59 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A774CE9 for ; Wed, 20 Sep 2023 03:46:33 -0700 (PDT) Date: Wed, 20 Sep 2023 12:46:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1695206791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=wAGWwRdw1kc9xidRjeEttNJpxiDPA74+rQRMxWuGmyM=; b=oTVlk4LAF19nJfppSVBUcHMXzk89PFb9Nq4zyZwJRRQwx1Ci2fvDIQCH7MA8nmjibQOFn1 dAMuCstKal7Dv3xOmWiJZgkY6FhLFPXL2LZaLDNpEaKtXbuzSAwLpOIMjzE/2QXn+b5EmW cCLXWBq8/xOF8Q2kM2VxXsrjT2Gj/FvQjBlsGRTZQgIJ1LN789VvWO0YpaBUhPAPmYj0xI FtdyHNmiA2diwGbRrFrHVPZmlaWHj3Sl+K1NWW0ixBzrq1nEakTbf8j1JCuDL3fQi9WBHx HCraghRVCM4s0MvNqD5hiSS0B3EadMQp9+P8lwvtBMrGrjSEHF0bJ+BS7PtINA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1695206791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=wAGWwRdw1kc9xidRjeEttNJpxiDPA74+rQRMxWuGmyM=; b=JyuIEQ8PNwF+Njx/kSLOBh6hV1YwB69q7QARgBXmFfQSrZSHeULCI8i/6hlzqFb/DjokzM 6tsv4JcMRNf7GKCg== From: Sebastian Andrzej Siewior To: linux-kernel@vger.kernel.org, Peter Zijlstra Cc: Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , Thomas Gleixner , Tetsuo Handa Subject: [PATCH REPOST] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Message-ID: <20230920104627._DTHgPyA@linutronix.de> MIME-Version: 1.0 Content-Disposition: inline X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 20 Sep 2023 03:47:37 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777559367649234957 X-GMAIL-MSGID: 1777559367649234957 It was brought up by Tetsuo that the following sequence write_seqlock_irqsave() printk_deferred_enter() could lead to a deadlock if the lockdep annotation within write_seqlock_irqsave() triggers. The problem is that the sequence counter is incremented before the lockdep annotation is performed. The lockdep splat would then attempt to invoke printk() but the reader side, of the same seqcount, could have a tty_port::lock acquired waiting for the sequence number to become even again. The other lockdep annotations come before the actual locking because "we want to see the locking error before it happens". There is no reason why seqcount should be different here. Do the lockdep annotation first then perform the locking operation (the sequence increment). Fixes: 1ca7d67cf5d5a ("seqcount: Add lockdep functionality to seqcount/seqlock structures") Reported-by: Tetsuo Handa Closes: https://lore.kernel.org/20230621130641.-5iueY1I@linutronix.de Signed-off-by: Sebastian Andrzej Siewior --- The previous submission was in https://lore.kernel.org/r/20230623171232.892937-2-bigeasy@linutronix.de The mm bits in the referenced thread have been merged as of -rc1. include/linux/seqlock.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/linux/seqlock.h +++ b/include/linux/seqlock.h @@ -512,8 +512,8 @@ do { \ static inline void do_write_seqcount_begin_nested(seqcount_t *s, int subclass) { - do_raw_write_seqcount_begin(s); seqcount_acquire(&s->dep_map, subclass, 0, _RET_IP_); + do_raw_write_seqcount_begin(s); } /**