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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 59DC6C77B61 for ; Mon, 24 Apr 2023 19:27:21 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Q4wBH3nZlz3f5Q for ; Tue, 25 Apr 2023 05:27:19 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=Q7kqlzPw; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::82b; helo=mail-qt1-x82b.google.com; envelope-from=boqun.feng@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=Q7kqlzPw; dkim-atps=neutral Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Q4w9H6fFKz3bTJ for ; Tue, 25 Apr 2023 05:26:25 +1000 (AEST) Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-3ef34e948b1so23192671cf.2 for ; Mon, 24 Apr 2023 12:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682364382; x=1684956382; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=j5WcTX+EeaGsxdM7iEyZFoPrBHwjvydFJtcBq7twcJE=; b=Q7kqlzPwtnz9GHcfA3FamK1WCOGenrygc8tdrlX+VPt4u+vIyXEtNyjNZag0Csm8PI cBh06puZK8ynWwiyKDW0V7GpKQOoH4Zp5iB2ur0Th0zORUbDZU/gevLheLDMnv9716aF yE3Fvlb1ntmT2RsJK9CNVZ/yzOWB/gP/o+dZnbrY/NoDwB36uNYX8MSezk9960RuHBz3 vq7UOlZROP4aWaMetE3961fITx3CMxFmwDOOyjVvr1jctSOMbDpd7f8mnrYQYeSTPlhr adf6cJnm4WmeItHzq1mnNaB9uus9imw4/FIHIV8j5tSGYSpPda7OWLCkHuftpscRqj8/ KdsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682364382; x=1684956382; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j5WcTX+EeaGsxdM7iEyZFoPrBHwjvydFJtcBq7twcJE=; b=RueeFv+zr9ULXJzCwVSYU2Ac3vg4NKiKYnDpgst8r5H/k/moRjlEqtimWr8TzHVK/C k2dj1aKh8eDBGd/8WYWkvIKMsUoC9OWe6pkNQ64bV1U9BDOaYDQdk/lPS+5ZX9DAs0DI xXczQcqtA0bnrn/KEzWL4YZD2dhY1RMu8f4MtYajDUgoU2T3PMoBhiqChik5lqTosnT1 6YcrWfy0zvoDt5m0ofeihEuiI5Yb2QXBilicENzQC9MFNgBHajRct6i05G8EomYzIcMm fg5m79IPTczXyurY+diyRO6pM/PANzQtwNL4akhCf5M4c1/Bu9EwRyfJUN3G90HWE3Zr y06A== X-Gm-Message-State: AAQBX9dX+6vLtY4gav887fDZge+rcx3rliQ7/DghRl0FLDpPEsFf/d76 O2PxVV2h40mNmu29qUWScf0= X-Google-Smtp-Source: AKy350bkmGyFsKqtKrCOL6Bro0cXPDHYhK3ExLfdT6QYV5byUqQgandDIZ3XR0YL1G+aj+tjUupYvw== X-Received: by 2002:ac8:5814:0:b0:3ef:57c1:ad7 with SMTP id g20-20020ac85814000000b003ef57c10ad7mr26361936qtg.30.1682364382044; Mon, 24 Apr 2023 12:26:22 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com. [66.111.4.227]) by smtp.gmail.com with ESMTPSA id x15-20020ac84d4f000000b003ef28a76a11sm3847395qtv.68.2023.04.24.12.26.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Apr 2023 12:26:21 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id D316927C0054; Mon, 24 Apr 2023 15:26:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 24 Apr 2023 15:26:20 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedutddgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhq uhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepffehkeeuhfeigeevveejvefftdehueevfeetleevfefgudeitedvudev ieevkedunecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgv rhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfh gvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Apr 2023 15:26:19 -0400 (EDT) Date: Mon, 24 Apr 2023 12:25:42 -0700 From: Boqun Feng To: Segher Boessenkool Subject: Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail Message-ID: References: <87fs8pzalj.fsf@mail.concordia> <20230424151351.GP19790@gate.crashing.org> <20230424172900.GR19790@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230424172900.GR19790@gate.crashing.org> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Paul E. McKenney" , linux-kernel , rcu , lance@osuosl.org, Zhouyi Zhou , Joel Fernandes , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Apr 24, 2023 at 12:29:00PM -0500, Segher Boessenkool wrote: > On Mon, Apr 24, 2023 at 08:28:55AM -0700, Boqun Feng wrote: > > On Mon, Apr 24, 2023 at 10:13:51AM -0500, Segher Boessenkool wrote: > > > At what points can r13 change? Only when some particular functions are > > > called? > > > > r13 is the local paca: > > > > register struct paca_struct *local_paca asm("r13"); > > > > , which is a pointer to percpu data. > > Yes, it is a global register variable. > > > So if a task schedule from one CPU to anotehr CPU, the value gets > > changed. > > But the compiler does not see that something else changes local_paca (or It's more like this, however, in this case r13 is not changed: CPU 0 CPU 1 {r13 = 0x00} {r13 = 0x04} _switch(): _switch(): as you can see thread 1 schedules from CPU 0 to CPU 1 and neither CPU changes its r13, but in the point of view for thread 1, its r13 changes. > r13 some other way, via assembler code perhaps)? Or is there a compiler > bug? > This looks to me a compiler bug, but I'm not 100% sure. Regards, Boqun > If the latter is true: > > Can you make a reproducer and open a GCC PR? > for how to get started doing that. We need *exact* code that shows the > problem, together with a compiler command line. So that we can > reproduce the problem. That is step 0 in figuring out what is going on, > and then maybe fixing the problem :-) > > > Segher