Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp62385pxu; Tue, 15 Dec 2020 16:10:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8AJBpD9Ng5rK4IFJE8iu7YUcoStW9GxcRRWikl5hACGbF2t4/Xdisl9zAcz9hsJN548Nc X-Received: by 2002:a17:907:111c:: with SMTP id qu28mr4025380ejb.540.1608077457504; Tue, 15 Dec 2020 16:10:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608077457; cv=none; d=google.com; s=arc-20160816; b=SCVkgH0sYn5MPtJQh+rJsyiK3Fi5nxUCkodYgsKFCY9SOhLeoHJvtFKZ1sEmijZV5x xgS5PVQ/Cx5/VACWI3pTdXElsAUOu3KXs9g3EfdKOhNKZ3feZKC1SPkPNjXXJKSqpbTg 3QNQHiL5tDcoYqDdF9GXhJoK/4qiH+j1/wvZDqv7dP8SCnkl1v+j8XVl1mPTbLknJ8lO ZtHOfm53m+6yiFyq2InhVgK0TqeSmnCAnoFKmiQvL0qQrTR2MTTdXqi0wiBAu9JI4kDF A4nZE+PDZEYVDs34fzldYf6+jtlFCtdpK9pYmcPkQxVzbVh5Cd7Xt2nYgvzgM7qL1G/t XN8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=e8xNqAIXDTUtCX5W0kioTV0Ma1tPF9kLhETyBKP+D8c=; b=wscyA35mvEdDzOhwZxyQ0k2S4syRSL3qVRM3iLgzRxxJJKs50zJB8bXMXXfGb5si9T 0HnFDNuMdGY+76ly95Hm6TAnZxdafw4OuhDXrs2xMjKmvQ27iIaiRGWUBe7b/6355ciJ GDfncQ8V0XfAEbRFzhimrAYk1/2XxLl3Mt+fqLjcLL1E7hfHsgq3diZ4AxoUwcwNOews 9k8Xs1XPaAX+wXM3HHybIdeFC/32Q63TFuFdXfxKOLI3djbDtpjbW4Wpt1SkT/1VQfjk zRr5Zl3JRKCaqbGRkP/1BxchhbdWo/0FzdUw+tujisqvtcWv9mJCwRd+W/fJv+iVLH9O 9vNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OXiXAijr; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u7si1622431edb.213.2020.12.15.16.10.33; Tue, 15 Dec 2020 16:10:57 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OXiXAijr; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727281AbgLPAAf (ORCPT + 99 others); Tue, 15 Dec 2020 19:00:35 -0500 Received: from mail.kernel.org ([198.145.29.99]:34626 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730147AbgLOX2N (ORCPT ); Tue, 15 Dec 2020 18:28:13 -0500 X-Gm-Message-State: AOAM531/H7pDPWSXuGnSA+UkFoaK4Bo908RGj1yZCjOUv3Lw7UkG/YMA 2D0TfukSsL3qmeYbOgffS/Gewtxd2TO71yEFZCY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608074705; bh=Yek6HG48EL+fBxIl/n3oPNvuVpQoWA77lJXD5WjiI9Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OXiXAijrTa58QSy8Hn4Q0b3hdD2jgwIRoLmtDqwg/MPYV+x+/pyUW3AbpOjuV+nB6 qHbSrFKdTAC1m0NcEbvtYljyHA1Zv6nyt6mmLr4bYwvpPyFiyCUHn4CnIK8/cBSc0E EYjofvBG3KtB7FlpeBmxHXvvJmHvJe3WKC6LfFjRhhPmTisypkx78haSU7XGGrPorE 3ccgTkYkfLW05m1Rj6N7U3TPsHcORlASXLxejCT1VrKCp1ImslMHIzW7NpCoESfP0I 62gQP4OWlFeRISBJ9icDmjEWn2VN2Tgc2qYhihJtakC4Gutsd58WlpC+7MIqSCVJwH T0Oa101XVRWAw== X-Received: by 2002:aca:44d:: with SMTP id 74mr659088oie.4.1608074704756; Tue, 15 Dec 2020 15:25:04 -0800 (PST) MIME-Version: 1.0 References: <20190307091514.2489338-1-arnd@arndb.de> <87czzeg5ep.fsf@nanos.tec.linutronix.de> <20201215193800.GA1098247@ravnborg.org> In-Reply-To: <20201215193800.GA1098247@ravnborg.org> From: Arnd Bergmann Date: Wed, 16 Dec 2020 00:24:48 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline' To: Sam Ravnborg Cc: Guo Ren , Thomas Gleixner , Marco Elver , Arnd Bergmann , Russell King , Ingo Molnar , Peter Zijlstra , Darren Hart , Nick Desaulniers , Davidlohr Bueso , Elena Reshetova , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , linux-csky@vger.kernel.org, sparclinux , "David S. Miller" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 15, 2020 at 8:38 PM Sam Ravnborg wrote: > On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote: > > > > - Disable SMP support for sun4m/sun4d. From the historic git > > tree, it's unclear how well this ever worked, and very few machines > > of this class ever existed > Yeah, I have collection of sparc32 machines that I played around with > once. Including one sun4d that I brought from a friendly Linux fellow in > the UK. But somehow I lost interest as this is all very nice machines > but not useful for anything real work. > > I think we would be better served dropping support for sun4m and sun4d > from the kernel. This seems appropriate as well to me. > Last I suggested deleting sun4m/sun4d the argument to keep sun4m was that > QEMU supports sun4m - which is a good argument for sun4m. I dunno what > would be needed to migrate QEMU to LEON, see below. "qemu-system-sparc -M help" shows a "leon3_generic" platform, apparently added in 2013. Do you think that would be sufficient? > > - Mark SMP for LEON as temporarily broken. As I see in the LEON > > patch set, they have changes to enable compare-and-swap-atomic > > instructions unconditionally, as all SMP Leons have those and > > seem to require this support already for other things. > LEON on the other hand could have some nice future. They are right now > stuck on an older kernel and someone that was motivated should be able > to get LEON4 running on latest upstream. > We had it working in the past - but is was around the time I lost my > sparc interest and no-one jumped in to move it much more forward. My best guess from the public information I could find on LEON is that it keeps shifting away from Linux on LEON to other OSs, and to and to Linux on NOEL-V. So even though the CPU itself will likely have a long life ahead of it with LEON5 only a year old, it's unclear how many more updates we'll see to the kernel from the current 4.9 based release. > So in other words - no complains for the plan you outline. Thanks. I'd probably queue up a patch in my asm-generic tree for v5.12 to disable SMP on all SPARC32, add the helpers for C-Sky once Guo Ren has tested a patch, and clean up the futex code based on this. I guess we want the one-line fix for Arm that Thomas suggested for v5.10 and backports anyway, The sun4m/sun4d removal should clearly be discussed separately and go through the sparc tree, to see if anyone has objections, or if we want to remove other obsolete platforms (sun3?) along with it. Arnd