Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp202212ybg; Thu, 11 Jun 2020 22:12:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7ti43MLPUgvd0T73bEvI135LnM30vbhDT4s48Urb58W47WjKuTNjtOKskUoCI163cnnwr X-Received: by 2002:a05:6402:362:: with SMTP id s2mr10172125edw.337.1591938775385; Thu, 11 Jun 2020 22:12:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591938775; cv=none; d=google.com; s=arc-20160816; b=Be1IE5Q36rlmuFXIfmT5qAQ78Xv95BdVYf1fYGSpKooRJ2OtwBWbo7LKs4oxxYJwwz 85+S3IunTabhIIeGED3JVC/+ZhXUJdQ0qlhNsf/A3M6D/qxN1P5V/UbKLb2qng/qE+La TuHtyxrr0JzMDM7VjaPiRirmuH2OeC5RiC/N7AQDR17VuisbOONP1SI9SYuyiCpa6q/1 ow8vIqEn7IGuAJdQUoga8eWWEyvSe+nQwpWTz20Y7xG1FnBfCCHtyHLU99DR9m8UPEfB KC9tcJ44now8lSsm9kRBFK3HQFAOwIhCIAqaJKP686ctH4s9BtYf7IYJUQRL1ET4N36A FCng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=tPzdtLdZrXqK4x2tzJvrFoBoLPxkl+ym9iPKcZXpCp8=; b=aXA8JgWaxdU0awgPm07yyscMUe99yo184WNzP6G56ZXTGVCoKOtGa3kQYBwyTlkuWY huQ6IhUET9hNLevZLJ23fHGFxb4iup30/8DypdO1u9w4cNB9qLs8rKKmcLzIvAhuwnEq 1wcHhxZn8ggxeJbTfe/hIglerx6KJGtBsIyAynIciCjXGomnOg6ujlelJo6a7eZ1UVpZ WAC4Z6/BpXjIzrV6957YfMUJmPl1kf3EGTfDDp7lnL4Pei2lH+oS2vY+rMPIMP4/8bsh UQ6xirUJpQ07Wi4joD/OLaadYOKSc+Wi7jMwnpvku0wc4C6xnyAIvOa2P765SUgkjlEf r8Jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=orcon.net.nz Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d20si2981903edr.177.2020.06.11.22.12.31; Thu, 11 Jun 2020 22:12:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=orcon.net.nz Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726405AbgFLFIc (ORCPT + 99 others); Fri, 12 Jun 2020 01:08:32 -0400 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:34317 "EHLO smtp-1.orcon.net.nz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725858AbgFLFIb (ORCPT ); Fri, 12 Jun 2020 01:08:31 -0400 X-Greylist: delayed 1223 seconds by postgrey-1.27 at vger.kernel.org; Fri, 12 Jun 2020 01:08:30 EDT Received: from [121.99.228.40] (port=19283 helo=tower) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1jjbbm-0007KJ-5z; Fri, 12 Jun 2020 16:48:02 +1200 Date: Fri, 12 Jun 2020 16:47:57 +1200 From: Michael Cree To: Matt Turner Cc: Kees Cook , Linux-Arch , LKML , linux-alpha , Richard Henderson , Ivan Kokshaysky Subject: Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage) Message-ID: <20200612044757.GA10703@tower> Mail-Followup-To: Michael Cree , Matt Turner , Kees Cook , Linux-Arch , LKML , linux-alpha , Richard Henderson , Ivan Kokshaysky References: <20200602024804.GA3776630@p50-ethernet.mattst88.com> <202006021052.E52618F@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 11, 2020 at 09:23:52PM -0700, Matt Turner wrote: > Since I noticed earlier that using maxcpus=1 on a 2-CPU system > prevented the system from hanging, I tried disabling CONFIG_SMP on my > 1-CPU system as well. In doing so, I discovered that the RCU torture > module (RCU_TORTURE_TEST) triggers some null pointer dereferences on > Alpha when CONFIG_SMP is set, but works successfully when CONFIG_SMP > is unset. > > That seems likely to be a symptom of the same underlying problem that > started this thread, don't you think? If so, I'll focus my attention > on that. I wonder if that is related to user space segfaults we are now seeing on SMP systems but not UP systems while building Alpha debian-ports. It's happening in the test-suites of builds of certain software (such as autogen and guile) but they always build successfully with the test suite passing on a UP system. When investigating I seem to recall it was a NULL (or near NULL) pointer dereference but couldn't make any sense of how it might have got into such an obviously wrong state. Cheers, Michael.