Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp5772460rwr; Mon, 24 Apr 2023 08:46:20 -0700 (PDT) X-Google-Smtp-Source: AKy350aVK9iJy4pPp8On8krQr3Ixlu5aI1MIJfKPj5axUOam2Dyeh2JwZa0xeAAJDpWsdmpZCvHR X-Received: by 2002:a05:6a20:a104:b0:f2:7dd:2753 with SMTP id q4-20020a056a20a10400b000f207dd2753mr21473201pzk.33.1682351179815; Mon, 24 Apr 2023 08:46:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682351179; cv=none; d=google.com; s=arc-20160816; b=oI57xaKBhcw1ua7gamFiPICs9vYm/uQfghkk+tdDhCNrnilDdYWYnbCK900Gra+FrC cAfpXr6x7aBaMcgO/O0zrgWztFzFElnpK4UKGUmaJce599qCjKzJI4KYQ4KxLUe1H/C9 hbqj1puqpQV9KGdyiSUNiyRlr0DY4axqftOwSo0f+3FBDmCDZlWYG8zZ+zzwLQr8aRpH yBUD4C6TjhF3aC3skMjFBbCXqcZ9hQL5KMHl9fdM1iBxm8K4sdb1mxTF0seIFQscVpMR +LFfrVS7X/yfppmsAaJcNfstauRWT5PMat3Dvq8PqpRRi32TDxvlMUyrn7/QL3ZNu3zC czjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=yfr4WklUyN4DdO6pAjOoECs3XqvOLfctFvUfRY6LCMc=; b=EyPUxQlrc9MwwLshl8HefmBUlO/tQrw/PcWtpf/HyWv+l4acuv5DloSnjXtrjLvVOZ +zDx57qG1y1NYguCXtGnmwcFELgUf83Rhi4X7rNbC7RaPGhDzK4WBK7ismGzcfqpuH3J d/hMrWj4WoFGs5WDpN/hFpwdyXCg7iKDD6FI7XLKQvjCMkDWoRWMb3wDotbmVHqH4jtE w7xdd6bwymMugHQIEPjfJHy4qVJxvaiI1SoxTf8RBFfBK3xXo1wVk9/LXW5oPizQiSkt X70bHES80Z4GqeGULvbHQlVjb4YXXo9Mjvh6n45SlSDTl5jTrJM1X8JFNVLgmRVtv4nR 9A+Q== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c5-20020a6566c5000000b0051a6292309fsi11332865pgw.894.2023.04.24.08.46.07; Mon, 24 Apr 2023 08:46:19 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232004AbjDXPkq (ORCPT + 99 others); Mon, 24 Apr 2023 11:40:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231794AbjDXPkp (ORCPT ); Mon, 24 Apr 2023 11:40:45 -0400 X-Greylist: delayed 1044 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 24 Apr 2023 08:40:43 PDT Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 816CB114; Mon, 24 Apr 2023 08:40:43 -0700 (PDT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 33OFDqb6006351; Mon, 24 Apr 2023 10:13:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 33OFDpYA006350; Mon, 24 Apr 2023 10:13:51 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 24 Apr 2023 10:13:51 -0500 From: Segher Boessenkool To: Michael Ellerman Cc: Boqun Feng , Joel Fernandes , Zhouyi Zhou , linuxppc-dev , rcu , linux-kernel , lance@osuosl.org, "Paul E. McKenney" Subject: Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail Message-ID: <20230424151351.GP19790@gate.crashing.org> References: <87fs8pzalj.fsf@mail.concordia> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87fs8pzalj.fsf@mail.concordia> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, 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 Hi! On Mon, Apr 24, 2023 at 11:14:00PM +1000, Michael Ellerman wrote: > Boqun Feng writes: > > On Sat, Apr 22, 2023 at 09:28:39PM +0200, Joel Fernandes wrote: > >> On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote: > >> > by debugging, I see the r10 is assigned with r13 on c000000000226eb4, > >> > but if there is a context-switch before c000000000226edc, a false > >> > positive will be reported. > I've never understood why the compiler wants to make a copy of a > register variable into another register!? >:# It is usually because a) you told it to (maybe via an earlyclobber), or b) it looked cheaper. I don't see either here :-( > > here I think that the compiler is using r10 as an alias to r13, since > > for userspace program, it's safe to assume the TLS pointer doesn't > > change. However this is not true for kernel percpu pointer. r13 is a "fixed" register, but that means it has a fixed purpose (so not available for allocation), it does not mean "unchanging". > > The real intention here is to compare 40(r1) vs 3192(r13) for stack > > guard checking, however since r13 is the percpu pointer in kernel, so > > the value of r13 can be changed if the thread gets scheduled to a > > different CPU after reading r13 for r10. > > Yeah that's not good. The GCC pattern here makes the four machine insns all stay together. That is to make sure to not leak any secret value, which is impossible to guarantee otherwise. What tells GCC r13 can randomly change behind its back? And, what then makes GCC ignore that fact? > > + asm volatile("" : : : "r13", "memory"); Any asm without output is always volatile. > > Needless to say, the correct fix is to make ppc stack protector aware of > > r13 is volatile. > > I suspect the compiler developers will tell us to go jump :) Why would r13 change over the course of *this* function / this macro, why can this not happen anywhere else? > The problem of the compiler caching r13 has come up in the past, but I > only remember it being "a worry" rather than causing an actual bug. In most cases the compiler is smart enough to use r13 directly, instead of copying it to another reg and then using that one. But not here for some strange reason. That of course is a very minor generated machine code quality bug and nothing more :-( > We've had the DEBUG_PREEMPT checks in get_paca(), which have given us at > least some comfort that if the compiler is caching r13, it shouldn't be > doing it in preemptable regions. > > But obviously that doesn't help at all with the stack protector check. > > I don't see an easy fix. > > Adding "volatile" to the definition of local_paca seems to reduce but > not elimate the caching of r13, and the GCC docs explicitly say *not* to > use volatile. It also triggers lots of warnings about volatile being > discarded. The point here is to say some code clobbers r13, not the asm volatile? > Or something simple I haven't thought of? :) At what points can r13 change? Only when some particular functions are called? Segher