Message ID | 20210308.154619.729170517586257571.davem@davemloft.net |
---|---|
State | Accepted |
Delegated to: | David Miller |
Headers | show |
Series | [GIT] SPARC | expand |
Hi Dave! On 3/9/21 12:46 AM, David Miller wrote: > Just some more random bits from Al, including a conversion over to generic exytables. Is there a chance we could include this important fix by Rob Gardner for 5.12 as well? > https://marc.info/?l=linux-sparc&m=161457847223456&w=2 It fixes a hard kernel crash under certain loads which we have seen in Debian quite frequently. Thanks, Adrian
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Date: Tue, 9 Mar 2021 01:19:05 +0100 > Hi Dave! > > On 3/9/21 12:46 AM, David Miller wrote: >> Just some more random bits from Al, including a conversion over to generic exytables. > > Is there a chance we could include this important fix by Rob Gardner for 5.12 as well? > >> https://marc.info/?l=linux-sparc&m=161457847223456&w=2 > > It fixes a hard kernel crash under certain loads which we have seen in Debian quite frequently. I'll ake sure that gets into my next pull req, thanks.
On Tue, Mar 9, 2021 at 11:08 AM David Miller <davem@davemloft.net> wrote: > > I'll make sure that gets into my next pull req, thanks. Note that it's obviously always easiest for me to just ignore something like sparc entirely, but on the other hand, particularly for low-volume trees it's also ok to just say "I don't have anything pending, here's the link to lore.kernel.org, can you apply that one patch directly". (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). I'll await your pull request or 'I have nothing else, take it from xyz', this thread is otherwise archived for me as "done". Linus
From: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue, 9 Mar 2021 11:27:41 -0800 > On Tue, Mar 9, 2021 at 11:08 AM David Miller <davem@davemloft.net> 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 for you to fetch changes up to 69264b4a43aff7307283e2bae29e9305ab6b7d47: sparc: sparc64_defconfig: remove duplicate CONFIGs (2021-03-09 16:22:40 -0800) ---------------------------------------------------------------- Al Viro (10): sparc32: don't bother with lookup_fault() in __bzero() sparc32: kill lookup_fault() sparc32: switch __bzero() away from range exception table entries sparc32: get rid of range exception table entries in checksum_32.S sparc32: switch copy_user.S away from range exception table entries sparc32: switch to generic extables Merge remote-tracking branch 'sparc/master' into work.sparc32 sparc64: get rid of fake_swapper_regs sparc32: get rid of fake_swapper_regs sparc32: take ->thread.flags out Corentin Labbe (1): sparc: sparc64_defconfig: remove duplicate CONFIGs David S. Miller (2): Merge branch 'work.sparc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Merge branch 'work.sparc32' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Rob Gardner (1): sparc64: Fix opcode filtering in handling of no fault loads arch/sparc/configs/sparc64_defconfig | 4 +- arch/sparc/include/asm/elf_64.h | 1 - arch/sparc/include/asm/{extable_64.h => extable.h} | 4 +- arch/sparc/include/asm/processor_32.h | 6 +- arch/sparc/include/asm/thread_info_64.h | 1 + arch/sparc/include/asm/uaccess.h | 3 + arch/sparc/include/asm/uaccess_32.h | 38 ---------- arch/sparc/include/asm/uaccess_64.h | 1 - arch/sparc/kernel/head_32.S | 2 +- arch/sparc/kernel/head_64.S | 2 +- arch/sparc/kernel/process_32.c | 12 ---- arch/sparc/kernel/setup_32.c | 3 - arch/sparc/kernel/setup_64.c | 4 -- arch/sparc/kernel/traps_64.c | 13 ++-- arch/sparc/kernel/unaligned_32.c | 106 ++------------------------- arch/sparc/lib/checksum_32.S | 64 +++++++---------- arch/sparc/lib/copy_user.S | 315 +++++++++++++++++++++++++++++---------------------------------------------------- arch/sparc/lib/memset.S | 87 +++++++++-------------- arch/sparc/mm/Makefile | 2 +- arch/sparc/mm/extable.c | 107 ---------------------------- arch/sparc/mm/fault_32.c | 80 +++------------------ arch/sparc/mm/mm_32.h | 2 - lib/extable.c | 5 -- 23 files changed, 205 insertions(+), 657 deletions(-) rename arch/sparc/include/asm/{extable_64.h => extable.h} (92%) delete mode 100644 arch/sparc/mm/extable.c
From: David Miller <davem@davemloft.net> Date: Tue, 09 Mar 2021 16:24:54 -0800 (PST) > From: Linus Torvalds <torvalds@linux-foundation.org> > Date: Tue, 9 Mar 2021 11:27:41 -0800 > >> On Tue, Mar 9, 2021 at 11:08 AM David Miller <davem@davemloft.net> 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 <clabbe@baylibre.com> 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 <sfr@canb.auug.org.au> Fixes: a57cdeb369ef ("sparc: sparc64_defconfig: add necessary configs for qemu") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit e5e8b80d352ec999d2bba3ea584f541c83f4ca3f Author: Rob Gardner <rob.gardner@oracle.com> 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 <rob.gardner@oracle.com> Tested-by: Anatoly Pugachev <matorola@gmail.com> Can you repull to get them, thanks.
On Tue, Mar 9, 2021 at 5:15 PM David Miller <davem@davemloft.net> wrote: > > Somehow you pull didn't get commits: Look closer at the pull date. That was before you had updated your branch. I did a second pull just moments ago, I'll push it out (along with the networking one), after all my tests have passed. Linus
From: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue, 9 Mar 2021 17:17:24 -0800 > On Tue, Mar 9, 2021 at 5:15 PM David Miller <davem@davemloft.net> wrote: >> >> Somehow you pull didn't get commits: > > Look closer at the pull date. That was before you had updated your branch. > > I did a second pull just moments ago, I'll push it out (along with the > networking one), after all my tests have passed. Thank you.
Hi David, Good to see you're back! On Wed, Mar 10, 2021 at 1:27 AM David Miller <davem@davemloft.net> wrote: > From: Linus Torvalds <torvalds@linux-foundation.org> > Date: Tue, 9 Mar 2021 11:27:41 -0800 > > On Tue, Mar 9, 2021 at 11:08 AM David Miller <davem@davemloft.net> 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. Which is only an "ask Konstantin" (CCed) away, isn't it? Gr{oetje,eeting}s, Geert
On Wed, Mar 10, 2021 at 11:40:47AM +0100, Geert Uytterhoeven 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. > > Which is only an "ask Konstantin" (CCed) away, isn't it? I'm in the process of creating the remainder of vger archives on lore, so it would have happened anyway, but I'll bump sparclinux up in the queue. Best, -K