Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp101095pxb; Tue, 9 Mar 2021 17:19:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJxjgnS/c80eT2N3yb/vKAyPNhoriXkR6Z/ewWWuclug1+vXEBE2yz+tBCRS3zGwnr9Pk4cB X-Received: by 2002:aa7:cf16:: with SMTP id a22mr449235edy.288.1615339150707; Tue, 09 Mar 2021 17:19:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615339150; cv=none; d=google.com; s=arc-20160816; b=MkgmlStf/Ux69PUNd2xBgWIbP+C08/30UJPAySpuUTTvQZ1Lb88+uphixo8ZFiGbAu f3KxAfDXCqs4IUEnBiYj5ZDMXLFBtNhMiCqGqt9AIVgtPIYIldsmHeF3WS2V2X+fA2bo H6V1rrRcQhvM+iUsD31g70/pZzG8ndJJlsKtB4TmTIFMu7Q16MtZW25SrZq2Ytv3YBeV FhAWvC55JdluSWLD3ITOiRJi6D1p0185D+9Zx4N2/rBATe8ENbn47H5FNpTJI3XCz6/q LY3ob7bRwM0pXN2P7pKDZbMsncAoFbsSmnPCttjVH3dlaoVwTnKu2ZGXpdkvUfCEbLZ6 jPBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=U4CJrHCCSjmv7TYvnaiYyhgWEFewNXozUKhU34oA7b0=; b=p/UaLd9LeTF2I9mm0cKsGyObQJXgee2r9il2262NwqbZ+O2ao6DK/dcb7TFVNJjP85 5KEECOgNPLOgtlbXC4Jcn+zQklDtkaYG9y51P/xF9ZlWoqxk+cWFGWnQMIe7+skspuHU lLg9ZjYit3WQaCujnglKOuRns3TV8zd+H29cEelunQq7hKi2aZCY3lAxIkHehJ9gruJe cu1bcnplJXhTq9Rttn5UC6QQvYY/FA/mJwq9LcM8bO4P2g3ykGwiZXr8n3zJgDf0iA9I 0b1L6YOrrL+B/GB1xAX4eHs1adRGf6T/uaF1ckcM1vx5d4PUTH6aXWIdv0BgndoqwPUC DLNw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o5si10386779ejn.708.2021.03.09.17.18.48; Tue, 09 Mar 2021 17:19:10 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231228AbhCJBQJ (ORCPT + 99 others); Tue, 9 Mar 2021 20:16:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229875AbhCJBPl (ORCPT ); Tue, 9 Mar 2021 20:15:41 -0500 Received: from mail.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87198C06174A; Tue, 9 Mar 2021 17:15:41 -0800 (PST) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) by mail.monkeyblade.net (Postfix) with ESMTPSA id 00DB84D0F5B8A; Tue, 9 Mar 2021 17:15:40 -0800 (PST) Date: Tue, 09 Mar 2021 17:15:40 -0800 (PST) Message-Id: <20210309.171540.1612415953102779664.davem@davemloft.net> To: torvalds@linux-foundation.org Cc: glaubitz@physik.fu-berlin.de, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [GIT] SPARC From: David Miller In-Reply-To: <20210309.162454.822491855062735992.davem@davemloft.net> References: <20210309.110812.234617387417457658.davem@davemloft.net> <20210309.162454.822491855062735992.davem@davemloft.net> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.monkeyblade.net [0.0.0.0]); Tue, 09 Mar 2021 17:15:41 -0800 (PST) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Miller Date: Tue, 09 Mar 2021 16:24:54 -0800 (PST) > From: Linus Torvalds > Date: Tue, 9 Mar 2021 11:27:41 -0800 > >> On Tue, Mar 9, 2021 at 11:08 AM David Miller wrote: >> >> (And yes, I prefer lore.kernel.org over marc, although for single >> patches it doesn't make much of a difference. For patch series, I find >> 'b4' so convenient that I definitely want the patch to show up on >> lore.kernel.org). > > Sadly, lore does not archive sparclinux@vger.kernel.org, so there > isn't much choice in this case. >> >> I'll await your pull request or 'I have nothing else, take it from >> xyz', this thread is otherwise archived for me as "done". > > I added Rob's fix to the tree, here is a new pull request, thanks! > > The following changes since commit 062c84fccc4444805738d76a2699c4d3c95184ec: > > Merge tag 'rproc-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc (2021-02-24 11:30:13 -0800) > > are available in the Git repository at: > > git://git.kernel.org:/pub/scm/linux/kernel/git/davem/sparc.git > Somehow you pull didn't get commits: commit 69264b4a43aff7307283e2bae29e9305ab6b7d47 (HEAD -> master, origin/master, origin/HEAD) Author: Corentin Labbe Date: Mon Mar 8 09:51:26 2021 +0000 sparc: sparc64_defconfig: remove duplicate CONFIGs After my patch there is CONFIG_ATA defined twice. Remove the duplicate one. Same problem for CONFIG_HAPPYMEAL, except I added as builtin for boot test with NFS. Reported-by: Stephen Rothwell Fixes: a57cdeb369ef ("sparc: sparc64_defconfig: add necessary configs for qemu") Signed-off-by: Corentin Labbe Signed-off-by: David S. Miller commit e5e8b80d352ec999d2bba3ea584f541c83f4ca3f Author: Rob Gardner Date: Sun Feb 28 22:48:16 2021 -0700 sparc64: Fix opcode filtering in handling of no fault loads is_no_fault_exception() has two bugs which were discovered via random opcode testing with stress-ng. Both are caused by improper filtering of opcodes. The first bug can be triggered by a floating point store with a no-fault ASI, for instance "sta %f0, [%g0] #ASI_PNF", opcode C1A01040. The code first tests op3[5] (0x1000000), which denotes a floating point instruction, and then tests op3[2] (0x200000), which denotes a store instruction. But these bits are not mutually exclusive, and the above mentioned opcode has both bits set. The intent is to filter out stores, so the test for stores must be done first in order to have any effect. The second bug can be triggered by a floating point load with one of the invalid ASI values 0x8e or 0x8f, which pass this check in is_no_fault_exception(): if ((asi & 0xf2) == ASI_PNF) An example instruction is "ldqa [%l7 + %o7] #ASI 0x8f, %f38", opcode CF95D1EF. Asi values greater than 0x8b (ASI_SNFL) are fatal in handle_ldf_stq(), and is_no_fault_exception() must not allow these invalid asi values to make it that far. In both of these cases, handle_ldf_stq() reacts by calling sun4v_data_access_exception() or spitfire_data_access_exception(), which call is_no_fault_exception() and results in an infinite recursion. Signed-off-by: Rob Gardner Tested-by: Anatoly Pugachev Can you repull to get them, thanks.