* Re: [PATCH v2] powerpc/config: powernv_defconfig updates
From: Nicholas Piggin @ 2018-04-11 12:43 UTC (permalink / raw)
To: Balbir Singh; +Cc: open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
In-Reply-To: <CAKTCnzm3ckm7Pujnbc-XMfqNQ0Td8cDyCgwCgGU-6_WL_u9X8w@mail.gmail.com>
On Wed, 11 Apr 2018 22:24:06 +1000
Balbir Singh <bsingharora@gmail.com> wrote:
> On Wed, Apr 11, 2018 at 8:42 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> > On Wed, 11 Apr 2018 20:04:45 +1000
> > Balbir Singh <bsingharora@gmail.com> wrote:
> >
> >> On Wed, Apr 11, 2018 at 7:12 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> >> > For consideration:
> >> >
> >> > * Add IPv6 support built in + additional modules - Because it's 2018 maan.
> >> > * Add DEFERRED_STRUCT_PAGE_INIT - Let's see what breaks.
> >>
> >> We did not find any benefits with this on a P8 in terms of boot time
> >> with large memory. May be worth reinvestigating
> >
> > Worth putting in the defconfig just for testing until then?
>
> Absolutely!
>
> >
> >>
> >> > * Add PPC_MEMTRACE - Small powernv debugfs driver for getting hardware traces.
> >> > * Add MEMORY_FAILURE - Machine check exceptions can now drive memory failure.
> >
> > ^^^^
> > Okay for this one?
>
> Yep definitely!
>
> >
> >> > * Turn on FANOTIFY - This is the current filesystem notification feature.
> >> > * Turn on SCOM_DEBUGFS - Handy for hardware/firmware debugging, security risk?
> >>
> >> Yep, should not be in defconfig, IMHO
> >
> > Why not? Honest question, I hear some things about secure
> > boot when I ask about this option but I'm not quite sure why, or
> > what we are securing here.
> >
> > If the firmware does not want us to mess with scoms, it should
> > restrict the call, no?
> >
>
> Yes, firmware definitely should. Do we need inband debugging?
I think it's a matter of convenience when testing and debugging
things. OTOH I haven't used it a great deal myself. Others do
want it if we can just ensure firmware will do the right thing
if we're in some secure configuration.
Thanks,
Nick
^ permalink raw reply
* Re: [V2] powerpc/fscr: Enable interrupts earlier before calling get_user()
From: Michael Ellerman @ 2018-04-11 14:49 UTC (permalink / raw)
To: Anshuman Khandual, linuxppc-dev
In-Reply-To: <20180329062337.29437-1-khandual@linux.vnet.ibm.com>
On Thu, 2018-03-29 at 06:23:37 UTC, Anshuman Khandual wrote:
> The function get_user() can sleep while trying to fetch instruction
> from user address space and causes the following warning from the
> scheduler.
>
> BUG: sleeping function called from invalid context
>
> Though interrupts get enabled back but it happens bit later after
> get_user() is called. This change moves enabling these interrupts
> earlier covering the function get_user(). While at this, lets check
> for kernel mode and crash as this interrupt should not have been
> triggered from the kernel context.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/709b973c844c0b4d115ac3a227a2e5
cheers
^ permalink raw reply
* Re: powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
From: Michael Ellerman @ 2018-04-11 14:49 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: leitao, mauricfo, linuxram
In-Reply-To: <20180405124913.12001-1-mpe@ellerman.id.au>
On Thu, 2018-04-05 at 12:49:13 UTC, Michael Ellerman wrote:
> The recent LPM changes to setup_rfi_flush() are causing some section
> mismatch warnings because we removed the __init annotation on
> setup_rfi_flush():
>
> The function setup_rfi_flush() references
> the function __init ppc64_bolted_size().
> the function __init memblock_alloc_base().
>
> The references are actually in init_fallback_flush(), but that is
> inlined into setup_rfi_flush().
>
> These references are safe because:
> - only pseries calls setup_rfi_flush() at runtime
> - pseries always passes L1D_FLUSH_FALLBACK at boot
> - so the fallback flush area will always be allocated
> - so the check in init_fallback_flush() will always return early:
> /* Only allocate the fallback flush area once (at boot time). */
> if (l1d_flush_fallback_area)
> return;
>
> - and therefore we won't actually call the freed init routines.
>
> We should rework the code to make it safer by default rather than
> relying on the above, but for now as a quick-fix just add a __ref
> annotation to squash the warning.
>
> Fixes: abf110f3e1ce ("powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/501a78cbc17c329fabf8e9750a1e9a
cheers
^ permalink raw reply
* Re: [1/2] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode
From: Michael Ellerman @ 2018-04-11 14:49 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20180405175631.31381-2-npiggin@gmail.com>
On Thu, 2018-04-05 at 17:56:30 UTC, Nicholas Piggin wrote:
> This crashes with a "Bad real address for load" attempting to load
> from the vmalloc region in realmode (faulting address is in DAR).
>
> Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
> LE SMP NR_CPUS=2048 NUMA PowerNV
> CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted 4.16.0-01530-g43d1859f0994
> NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
> REGS: c000000fff76dd80 TRAP: 0200 Not tainted (4.16.0-01530-g43d1859f0994)
> MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 00000000
> CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3
> NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
> LR [c0000000000c2430] do_tlbies+0x230/0x2f0
>
> I suspect the reason is the per-cpu data is not in the linear chunk.
> This could be restored if that was able to be fixed, but for now,
> just remove the tracepoints.
>
> Fixes: 0428491cba ("powerpc/mm: Trace tlbie(l) instructions")
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/19ce7909ed11c49f7eddf59e7f49cd
cheers
^ permalink raw reply
* Re: powerpc/modules: Fix crashes by adding CONFIG_RELOCATABLE to vermagic
From: Michael Ellerman @ 2018-04-11 14:49 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: ard.biesheuvel
In-Reply-To: <20180410012206.4395-1-mpe@ellerman.id.au>
On Tue, 2018-04-10 at 01:22:06 UTC, Michael Ellerman wrote:
> If you build the kernel with CONFIG_RELOCATABLE=n, then install the
> modules, rebuild the kernel with CONFIG_RELOCATABLE=y and leave the
> old modules installed, we crash something like:
>
> Unable to handle kernel paging request for data at address 0xd000000018d66cef
> Faulting instruction address: 0xc0000000021ddd08
> Oops: Kernel access of bad area, sig: 11 [#1]
> Modules linked in: x_tables autofs4
> CPU: 2 PID: 1 Comm: systemd Not tainted 4.16.0-rc6-gcc_ubuntu_le-g99fec39 #1
> ...
> NIP check_version.isra.22+0x118/0x170
> Call Trace:
> __ksymtab_xt_unregister_table+0x58/0xfffffffffffffcb8 [x_tables] (unreliable)
> resolve_symbol+0xb4/0x150
> load_module+0x10e8/0x29a0
> SyS_finit_module+0x110/0x140
> system_call+0x58/0x6c
>
> This happens because since commit 71810db27c1c ("modversions: treat
> symbol CRCs as 32 bit quantities"), a relocatable kernel encodes and
> handles symbol CRCs differently from a non-relocatable kernel.
>
> Although it's possible we could try and detect this situation and
> handle it, it's much more robust to simply make the state of
> CONFIG_RELOCATABLE part of the module vermagic.
>
> Fixes: 71810db27c1c ("modversions: treat symbol CRCs as 32 bit quantities")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/73aca179d78eaa11604ba0783a6d8b
cheers
^ permalink raw reply
* Re: powerpc/8xx: Build fix with Hugetlbfs enabled
From: Michael Ellerman @ 2018-04-11 14:49 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20180410085126.15882-1-aneesh.kumar@linux.ibm.com>
On Tue, 2018-04-10 at 08:51:26 UTC, "Aneesh Kumar K.V" wrote:
> 8xx use slice code when hugetlbfs is enabled. We missed a header include on
> 8xx which resulted in the below build failure.
>
> config: mpc885_ads_defconfig + CONFIG_HUGETLBFS
>
> CC arch/powerpc/mm/slice.o
> arch/powerpc/mm/slice.c: In function 'slice_get_unmapped_area':
> arch/powerpc/mm/slice.c:655:2: error: implicit declaration of function 'need_extra_context' [-Werror=implicit-function-declaration]
> arch/powerpc/mm/slice.c:656:3: error: implicit declaration of function 'alloc_extended_context' [-Werror=implicit-function-declaration]
> cc1: all warnings being treated as errors
> make[1]: *** [arch/powerpc/mm/slice.o] Error 1
> make: *** [arch/powerpc/mm] Error 2
>
> on PPC64 the mmu_context.h was included via linux/pkeys.h
>
> CC: Christophe LEROY <christophe.leroy@c-s.fr>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/032900e62c176d75923baf95ad880e
cheers
^ permalink raw reply
* Re: [1/3] powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops
From: Michael Ellerman @ 2018-04-11 14:49 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180410114933.24581-2-npiggin@gmail.com>
On Tue, 2018-04-10 at 11:49:31 UTC, Nicholas Piggin wrote:
> This is the start of an effort to tidy up and standardise all the
> delays. Existing loops have a range of delay/sleep periods from 1ms
> to 20ms, and some have no delay. They all loop forever except rtc,
> which times out after 10 retries, and that uses 10ms delays. So use
> 10ms as our standard delay. The OPAL maintainer agrees 10ms is a
> reasonable starting point.
>
> The idea is to use the same recipe everywhere, once this is proven to
> work then it will be documented as an OPAL API standard. Then both
> firmware and OS can agree, and if a particular call needs something
> else, then that can be documented with reasoning.
>
> This is not the end-all of this effort, it's just a relatively easy
> change that fixes some existing high latency delays. There should be
> provision for standardising timeouts and/or interruptible loops where
> possible, so non-fatal firmware errors don't cause hangs.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/34dd25de9fe3f60bfdb31b473bf04b
cheers
^ permalink raw reply
* Re: [3/3] powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops
From: Michael Ellerman @ 2018-04-11 14:49 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180410114933.24581-4-npiggin@gmail.com>
On Tue, 2018-04-10 at 11:49:33 UTC, Nicholas Piggin wrote:
> The OPAL NVRAM driver does not sleep in case it gets OPAL_BUSY or
> OPAL_BUSY_EVENT from firmware, which causes large scheduling
> latencies, and various lockup errors to trigger (again, BMC reboot
> can cause it).
>
> Fix this by converting it to the standard form OPAL_BUSY loop that
> sleeps.
>
> Fixes: 628daa8d5abfd ("powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks")
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/3b8070335f751aac9f1526ae2e012e
cheers
^ permalink raw reply
* Re: powerpc/modules: Fix crashes by adding CONFIG_RELOCATABLE to vermagic
From: Ard Biesheuvel @ 2018-04-11 14:54 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <40Ln4W304zz9s3X@ozlabs.org>
On 11 April 2018 at 16:49, Michael Ellerman
<patch-notifications@ellerman.id.au> wrote:
> On Tue, 2018-04-10 at 01:22:06 UTC, Michael Ellerman wrote:
>> If you build the kernel with CONFIG_RELOCATABLE=n, then install the
>> modules, rebuild the kernel with CONFIG_RELOCATABLE=y and leave the
>> old modules installed, we crash something like:
>>
>> Unable to handle kernel paging request for data at address 0xd000000018d66cef
>> Faulting instruction address: 0xc0000000021ddd08
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> Modules linked in: x_tables autofs4
>> CPU: 2 PID: 1 Comm: systemd Not tainted 4.16.0-rc6-gcc_ubuntu_le-g99fec39 #1
>> ...
>> NIP check_version.isra.22+0x118/0x170
>> Call Trace:
>> __ksymtab_xt_unregister_table+0x58/0xfffffffffffffcb8 [x_tables] (unreliable)
>> resolve_symbol+0xb4/0x150
>> load_module+0x10e8/0x29a0
>> SyS_finit_module+0x110/0x140
>> system_call+0x58/0x6c
>>
>> This happens because since commit 71810db27c1c ("modversions: treat
>> symbol CRCs as 32 bit quantities"), a relocatable kernel encodes and
>> handles symbol CRCs differently from a non-relocatable kernel.
>>
>> Although it's possible we could try and detect this situation and
>> handle it, it's much more robust to simply make the state of
>> CONFIG_RELOCATABLE part of the module vermagic.
>>
>> Fixes: 71810db27c1c ("modversions: treat symbol CRCs as 32 bit quantities")
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> Applied to powerpc fixes.
>
> https://git.kernel.org/powerpc/c/73aca179d78eaa11604ba0783a6d8b
>
> cheers
Thanks for the cc. I guess this only affects powerpc, given that it is
the only arch that switches between CRC immediate values and CRC
offsets depending on the configuration.
^ permalink raw reply
* [GIT PULL] asm-generic fixes for v4.17-rc1
From: Arnd Bergmann @ 2018-04-11 15:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sinan Kaya, linuxppc-dev, linux-rdma, linux-s390, Linux ARM,
linux-arch, Linux Kernel Mailing List, Martin Schwidefsky,
Heiko Carstens, Ley Foon Tan, moderated list:NIOS2 ARCHITECTURE,
Michal Simek, moderated list:H8/300 ARCHITECTURE, Yoshinori Sato,
sparclinux, David S. Miller, Guan Xuetao, linux-xtensa, openrisc
The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda:
Linux 4.16 (2018-04-01 14:20:27 -0700)
are available in the git repository at:
git+ssh://gitolite@ra.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
tags/asm-generic
for you to fetch changes up to a71e7c44ffb7baea0c0795824afc34cc0bc1a301:
io: change writeX_relaxed() to remove barriers (2018-04-10 16:37:34 +0200)
----------------------------------------------------------------
asm-generic fixes for v4.17-rc1
I have one regression fix for a minor build problem after the architecture
removal series, plus a rework of the barriers in the readl/writel
functions, thanks to work by Sinan Kaya:
This started from a discussion on the linuxpcc and rdma mailing lists
[1]. To summarize, we decided that architectures are responsible to
serialize readl() and writel() accesses on a device MMIO space relative
to DMA performed by that device.
This series provides a pessimistic implementation of that behavior for
asm-generic/io.h, which is in turn used by a number of architectures
(h8300, microblaze, nios2, openrisc, s390, sparc, um, unicore32, and
xtensa). Some of those presumably need no extra barriers, or something
weaker than rmb()/wmb(), and they are advised to override the new default
for better performance.
For inb()/outb(), the same barriers are used, but architectures might
want to add another barrier to outb() here if that can guarantee
non-posted behavior (some architectures can, others cannot do that).
The readl_relaxed()/writel_relaxed() family of functions retains the
existing behavior with no extra barriers.
[1]: https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-March/170481.html
----------------------------------------------------------------
Liu, Changcheng (1):
dts: remove cris & metag dts hard link file
Sinan Kaya (7):
io: define several IO & PIO barrier types for the asm-generic version
io: define stronger ordering for the default readX() implementation
io: define stronger ordering for the default writeX() implementation
io: change outX() to have their own IO barrier overrides
io: change inX() to have their own IO barrier overrides
io: change readX_relaxed() to remove barriers
io: change writeX_relaxed() to remove barriers
include/asm-generic/io.h | 161
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------
scripts/dtc/include-prefixes/cris | 1 -
scripts/dtc/include-prefixes/metag | 1 -
3 files changed, 143 insertions(+), 20 deletions(-)
delete mode 120000 scripts/dtc/include-prefixes/cris
delete mode 120000 scripts/dtc/include-prefixes/metag
^ permalink raw reply
* Re: [GIT PULL] asm-generic fixes for v4.17-rc1
From: Linus Torvalds @ 2018-04-11 23:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sinan Kaya, linuxppc-dev, linux-rdma, linux-s390, Linux ARM,
linux-arch, Linux Kernel Mailing List, Martin Schwidefsky,
Heiko Carstens, Ley Foon Tan, moderated list:NIOS2 ARCHITECTURE,
Michal Simek, moderated list:H8/300 ARCHITECTURE, Yoshinori Sato,
sparclinux, David S. Miller, Guan Xuetao, linux-xtensa, openrisc
In-Reply-To: <CAK8P3a081_hkr5d0FRWpTaT-AsJoqznsS1=_WF4JVLTUOupUgg@mail.gmail.com>
On Wed, Apr 11, 2018 at 8:40 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> are available in the git repository at:
>
> git+ssh://gitolite@ra.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
> tags/asm-generic
Yeah, no they aren't available there at all.
That tag is some old tag from two years ago that just contains your
ancient "asm-generic: use compat version for preadv2 and pwritev2".
Forgot to push out? Or forgot to use "-f" to overwrite the old tag?
Linus
^ permalink raw reply
* [PATCH v2 07/10] block/swim: Rename macros to avoid inconsistent inverted logic
From: Finn Thain @ 2018-04-12 0:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jens Axboe, Laurent Vivier, linux-m68k, linux-kernel, linux-block,
stable, Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <cover.1523493475.git.fthain@telegraphics.com.au>
The Sony drive status bits use active-low logic. The swim_readbit()
function converts that to 'C' logic for readability. Hence, the
sense of the names of the status bit macros should not be inverted.
Mostly they are correct. However, the TWOMEG_DRIVE, MFM_MODE and
TWOMEG_MEDIA macros have inverted sense (like MkLinux). Fix this
inconsistency and make the following patches less confusing.
The same problem affects swim3.c so fix that too.
No functional change.
The FDHD drive status bits are documented in sonydriv.cpp from MAME
and in swimiii.h from MkLinux.
Cc: Laurent Vivier <lvivier@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: stable@vger.kernel.org # v4.14+
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Acked-by: Laurent Vivier <lvivier@redhat.com>
---
drivers/block/swim.c | 8 ++++----
drivers/block/swim3.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/block/swim.c b/drivers/block/swim.c
index 7b847170cf71..d1ee4670666a 100644
--- a/drivers/block/swim.c
+++ b/drivers/block/swim.c
@@ -110,7 +110,7 @@ struct iwm {
/* Select values for swim_select and swim_readbit */
#define READ_DATA_0 0x074
-#define TWOMEG_DRIVE 0x075
+#define ONEMEG_DRIVE 0x075
#define SINGLE_SIDED 0x076
#define DRIVE_PRESENT 0x077
#define DISK_IN 0x170
@@ -118,9 +118,9 @@ struct iwm {
#define TRACK_ZERO 0x172
#define TACHO 0x173
#define READ_DATA_1 0x174
-#define MFM_MODE 0x175
+#define GCR_MODE 0x175
#define SEEK_COMPLETE 0x176
-#define ONEMEG_MEDIA 0x177
+#define TWOMEG_MEDIA 0x177
/* Bits in handshake register */
@@ -612,7 +612,7 @@ static void setup_medium(struct floppy_state *fs)
struct floppy_struct *g;
fs->disk_in = 1;
fs->write_protected = swim_readbit(base, WRITE_PROT);
- fs->type = swim_readbit(base, ONEMEG_MEDIA);
+ fs->type = swim_readbit(base, TWOMEG_MEDIA);
if (swim_track00(base))
printk(KERN_ERR
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index af51015d056e..469541c1e51e 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -148,7 +148,7 @@ struct swim3 {
#define MOTOR_ON 2
#define RELAX 3 /* also eject in progress */
#define READ_DATA_0 4
-#define TWOMEG_DRIVE 5
+#define ONEMEG_DRIVE 5
#define SINGLE_SIDED 6 /* drive or diskette is 4MB type? */
#define DRIVE_PRESENT 7
#define DISK_IN 8
@@ -156,9 +156,9 @@ struct swim3 {
#define TRACK_ZERO 10
#define TACHO 11
#define READ_DATA_1 12
-#define MFM_MODE 13
+#define GCR_MODE 13
#define SEEK_COMPLETE 14
-#define ONEMEG_MEDIA 15
+#define TWOMEG_MEDIA 15
/* Definitions of values used in writing and formatting */
#define DATA_ESCAPE 0x99
--
2.16.1
^ permalink raw reply related
* Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
From: Dmitry V. Levin @ 2018-04-12 1:34 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, linuxppc-dev, linux-sparc, linux-arm-kernel,
linux-kernel
In-Reply-To: <20180409152253.GD10489@altlinux.org>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
Hi,
On Mon, Apr 09, 2018 at 06:22:53PM +0300, Dmitry V. Levin wrote:
> There seems to be a regression in v4.16 on ppc compat very similar
> to sparc compat regression reported earlier at
> https://marc.info/?l=linux-sparc&m=151501500704383 .
>
> The symptoms are exactly the same: the same signal_receive test from
> the strace test suite fails with the same diagnostics:
> https://build.opensuse.org/public/build/home:ldv_alt/openSUSE_Factory_PowerPC/ppc/strace/_log
The log is big, just look for "KERNEL BUG".
> Unfortunately, I do not have any means to investigate further,
> so just passing this information on to those who care.
OK, the faulty commit is v4.16-rc1~159^2~39
("signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP").
One might think that a commit called "Document conflicts" shouldn't
introduce an ABI regression, but this one definitely does by defining
FPE_FIXME and TRAP_FIXME in arch/powerpc/include/uapi/asm/siginfo.h
that affect siginfo_layout().
A similar commit v4.16-rc1~159^2~37
("signal/arm: Document conflicts with SI_USER and SIGFPE") must have
introduced a similar ABI regression to compat arm.
An earlier commit v4.14-rc1~60^2^2~5
("signal/sparc: Document a conflict with SI_USER with SIGFPE") introduced
a similar ABI regression to compat sparc.
There is a clear pattern of sneaking in ABI changes using innocently
looking commit messages.
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
From: Linus Torvalds @ 2018-04-12 1:45 UTC (permalink / raw)
To: Eric W. Biederman, Linus Torvalds, ppc-dev, linux-sparc,
linux-arm-kernel, Linux Kernel Mailing List
In-Reply-To: <20180412013435.GA21219@altlinux.org>
On Wed, Apr 11, 2018 at 6:34 PM, Dmitry V. Levin <ldv@altlinux.org> wrote:
>
> There is a clear pattern of sneaking in ABI changes using innocently
> looking commit messages.
Yes, this siginfo stuff has been a mess.
Eric - this needs to stop. Or we need to revert all that garbage entirely.
Send a fix. And stop changing the siginfo layout or field values.
Linus
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/fadump: Do not use hugepages when fadump is active
From: Mahesh Jagannath Salgaonkar @ 2018-04-12 4:34 UTC (permalink / raw)
To: Hari Bathini, Michael Ellerman
Cc: linuxppc-dev, Aneesh Kumar K.V, Anshuman Khandual
In-Reply-To: <152336768322.8374.8580280567534579046.stgit@hbathini.in.ibm.com>
On 04/10/2018 07:11 PM, Hari Bathini wrote:
> FADump capture kernel boots in restricted memory environment preserving
> the context of previous kernel to save vmcore. Supporting hugepages in
> such environment makes things unnecessarily complicated, as hugepages
> need memory set aside for them. This means most of the capture kernel's
> memory is used in supporting hugepages. In most cases, this results in
> out-of-memory issues while booting FADump capture kernel. But hugepages
> are not of much use in capture kernel whose only job is to save vmcore.
> So, disabling hugepages support, when fadump is active, is a reliable
> solution for the out of memory issues. Introducing a flag variable to
> disable HugeTLB support when fadump is active.
>
> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
> ---
>
> Changes in v2:
> * Introduce a hugetlb_disabled flag to enable/disable hugepage support &
> use that flag to disable hugepage support when fadump is active.
Looks good to me.
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
>
> arch/powerpc/include/asm/page.h | 1 +
> arch/powerpc/kernel/fadump.c | 8 ++++++++
> arch/powerpc/mm/hash_utils_64.c | 6 ++++--
> arch/powerpc/mm/hugetlbpage.c | 7 +++++++
> 4 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 8da5d4c..40aee93 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -39,6 +39,7 @@
>
> #ifndef __ASSEMBLY__
> #ifdef CONFIG_HUGETLB_PAGE
> +extern bool hugetlb_disabled;
> extern unsigned int HPAGE_SHIFT;
> #else
> #define HPAGE_SHIFT PAGE_SHIFT
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index bea8d5f..8ceabef4 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -402,6 +402,14 @@ int __init fadump_reserve_mem(void)
> if (fw_dump.dump_active) {
> pr_info("Firmware-assisted dump is active.\n");
>
> +#ifdef CONFIG_HUGETLB_PAGE
> + /*
> + * FADump capture kernel doesn't care much about hugepages.
> + * In fact, handling hugepages in capture kernel is asking for
> + * trouble. So, disable HugeTLB support when fadump is active.
> + */
> + hugetlb_disabled = true;
> +#endif
> /*
> * If last boot has crashed then reserve all the memory
> * above boot_memory_size so that we don't touch it until
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index cf290d41..eab8f1d 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -571,8 +571,10 @@ static void __init htab_scan_page_sizes(void)
> }
>
> #ifdef CONFIG_HUGETLB_PAGE
> - /* Reserve 16G huge page memory sections for huge pages */
> - of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
> + if (!hugetlb_disabled) {
> + /* Reserve 16G huge page memory sections for huge pages */
> + of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
> + }
> #endif /* CONFIG_HUGETLB_PAGE */
> }
>
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 876da2b..18c080a 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -35,6 +35,8 @@
> #define PAGE_SHIFT_16M 24
> #define PAGE_SHIFT_16G 34
>
> +bool hugetlb_disabled = false;
> +
> unsigned int HPAGE_SHIFT;
> EXPORT_SYMBOL(HPAGE_SHIFT);
>
> @@ -653,6 +655,11 @@ static int __init hugetlbpage_init(void)
> {
> int psize;
>
> + if (hugetlb_disabled) {
> + pr_info("HugeTLB support is disabled!\n");
> + return 0;
> + }
> +
> #if !defined(CONFIG_PPC_FSL_BOOK3E) && !defined(CONFIG_PPC_8xx)
> if (!radix_enabled() && !mmu_has_feature(MMU_FTR_16M_PAGE))
> return -ENODEV;
>
^ permalink raw reply
* [PATCH] powerpc/mm/radix: Fix checkstops caused by invalid tlbiel
From: Michael Ellerman @ 2018-04-12 5:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: joel, npiggin
In tlbiel_radix_set_isa300() we use the PPC_TLBIEL() macro to
construct tlbiel instructions. The instruction takes 5 fields, two of
which are registers, and the others are constants. But because it's
constructed with inline asm the compiler doesn't know that.
We got the constraint wrong on the 'r' field, using "r" tells the
compiler to put the value in a register. The value we then get in the
macro is the *register number*, not the value of the field.
That means when we mask the register number with 0x1 we get 0 or 1
depending on which register the compiler happens to put the constant
in, eg:
li r10,1
tlbiel r8,r9,2,0,0
li r7,1
tlbiel r10,r6,0,0,1
If we're unlucky we might generate an invalid instruction form, for
example RIC=0, PRS=1 and R=0, tlbiel r8,r7,0,1,0, this has been
observed to cause machine checks:
Oops: Machine check, sig: 7 [#1]
CPU: 24 PID: 0 Comm: swapper
NIP: 00000000000385f4 LR: 000000000100ed00 CTR: 000000000000007f
REGS: c00000000110bb40 TRAP: 0200
MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48002222 XER: 20040000
CFAR: 00000000000385d0 DAR: 0000000000001c00 DSISR: 00000200 SOFTE: 1
If the machine check happens early in boot while we have MSR_ME=0 it
will escalate into a checkstop and kill the box entirely.
To fix it we could change the inline asm constraint to "i" which
tells the compiler the value is a constant. But a better fix is to just
pass a literal 1 into the macro, which bypasses any problems with inline
asm constraints.
Fixes: d4748276ae14 ("powerpc/64s: Improve local TLB flush for boot and MCE on POWER9")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/mm/tlb-radix.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
index 2fba6170ab3f..a5d7309c2d05 100644
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -33,13 +33,12 @@ static inline void tlbiel_radix_set_isa300(unsigned int set, unsigned int is,
{
unsigned long rb;
unsigned long rs;
- unsigned int r = 1; /* radix format */
rb = (set << PPC_BITLSHIFT(51)) | (is << PPC_BITLSHIFT(53));
rs = ((unsigned long)pid << PPC_BITLSHIFT(31));
- asm volatile(PPC_TLBIEL(%0, %1, %2, %3, %4)
- : : "r"(rb), "r"(rs), "i"(ric), "i"(prs), "r"(r)
+ asm volatile(PPC_TLBIEL(%0, %1, %2, %3, 1)
+ : : "r"(rb), "r"(rs), "i"(ric), "i"(prs)
: "memory");
}
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] powerpc/mm/radix: Fix checkstops caused by invalid tlbiel
From: Nicholas Piggin @ 2018-04-12 6:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, joel
In-Reply-To: <20180412055352.21998-1-mpe@ellerman.id.au>
On Thu, 12 Apr 2018 15:53:52 +1000
Michael Ellerman <mpe@ellerman.id.au> wrote:
> In tlbiel_radix_set_isa300() we use the PPC_TLBIEL() macro to
> construct tlbiel instructions. The instruction takes 5 fields, two of
> which are registers, and the others are constants. But because it's
> constructed with inline asm the compiler doesn't know that.
>
> We got the constraint wrong on the 'r' field, using "r" tells the
> compiler to put the value in a register. The value we then get in the
> macro is the *register number*, not the value of the field.
>
> That means when we mask the register number with 0x1 we get 0 or 1
> depending on which register the compiler happens to put the constant
> in, eg:
>
> li r10,1
> tlbiel r8,r9,2,0,0
>
> li r7,1
> tlbiel r10,r6,0,0,1
>
> If we're unlucky we might generate an invalid instruction form, for
> example RIC=0, PRS=1 and R=0, tlbiel r8,r7,0,1,0, this has been
> observed to cause machine checks:
>
> Oops: Machine check, sig: 7 [#1]
> CPU: 24 PID: 0 Comm: swapper
> NIP: 00000000000385f4 LR: 000000000100ed00 CTR: 000000000000007f
> REGS: c00000000110bb40 TRAP: 0200
> MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48002222 XER: 20040000
> CFAR: 00000000000385d0 DAR: 0000000000001c00 DSISR: 00000200 SOFTE: 1
>
> If the machine check happens early in boot while we have MSR_ME=0 it
> will escalate into a checkstop and kill the box entirely.
>
> To fix it we could change the inline asm constraint to "i" which
> tells the compiler the value is a constant. But a better fix is to just
> pass a literal 1 into the macro, which bypasses any problems with inline
> asm constraints.
>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> Fixes: d4748276ae14 ("powerpc/64s: Improve local TLB flush for boot and MCE on POWER9")
> Cc: stable@vger.kernel.org # v4.16+
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/mm/tlb-radix.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
> index 2fba6170ab3f..a5d7309c2d05 100644
> --- a/arch/powerpc/mm/tlb-radix.c
> +++ b/arch/powerpc/mm/tlb-radix.c
> @@ -33,13 +33,12 @@ static inline void tlbiel_radix_set_isa300(unsigned int set, unsigned int is,
> {
> unsigned long rb;
> unsigned long rs;
> - unsigned int r = 1; /* radix format */
>
> rb = (set << PPC_BITLSHIFT(51)) | (is << PPC_BITLSHIFT(53));
> rs = ((unsigned long)pid << PPC_BITLSHIFT(31));
>
> - asm volatile(PPC_TLBIEL(%0, %1, %2, %3, %4)
> - : : "r"(rb), "r"(rs), "i"(ric), "i"(prs), "r"(r)
> + asm volatile(PPC_TLBIEL(%0, %1, %2, %3, 1)
> + : : "r"(rb), "r"(rs), "i"(ric), "i"(prs)
> : "memory");
> }
>
^ permalink raw reply
* [PATCH RFC 1/1] KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space
From: Sam Bobroff @ 2018-04-12 7:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm, kvm-ppc, paulus, david, clg
It is not currently possible to create the full number of possible
VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
threads per core than it's core stride (or "VSMT mode"). This is
because the VCORE ID and XIVE offsets to grow beyond KVM_MAX_VCPUS
even though the VCPU ID is less than KVM_MAX_VCPU_ID.
To address this, "pack" the VCORE ID and XIVE offsets by using
knowledge of the way the VCPU IDs will be used when there are less
guest threads per core than the core stride. The primary thread of
each core will always be used first. Then, if the guest uses more than
one thread per core, these secondary threads will sequentially follow
the primary in each core.
So, the only way an ID above KVM_MAX_VCPUS can be seen, is if the
VCPUs are being spaced apart, so at least half of each core is empty
and IDs between KVM_MAX_VCPUS and (KVM_MAX_VCPUS * 2) can be mapped
into the second half of each core (4..7, in an 8-thread core).
Similarly, if IDs above KVM_MAX_VCPUS * 2 are seen, at least 3/4 of
each core is being left empty, and we can map down into the second and
third quarters of each core (2, 3 and 5, 6 in an 8-thread core).
Lastly, if IDs above KVM_MAX_VCPUS * 4 are seen, only the primary
threads are being used and 7/8 of the core is empty, allowing use of
the 1, 3, 5 and 7 thread slots.
(Strides less than 8 are handled similarly.)
This allows the VCORE ID or offset to be calculated quickly from the
VCPU ID or XIVE server numbers, without access to the VCPU structure.
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
---
Hello everyone,
I've tested this on P8 and P9, in lots of combinations of host and guest
threading modes and it has been fine but it does feel like a "tricky"
approach, so I still feel somewhat wary about it.
I've posted it as an RFC because I have not tested it with guest native-XIVE,
and I suspect that it will take some work to support it.
arch/powerpc/include/asm/kvm_book3s.h | 19 +++++++++++++++++++
arch/powerpc/kvm/book3s_hv.c | 14 ++++++++++----
arch/powerpc/kvm/book3s_xive.c | 9 +++++++--
3 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 376ae803b69c..1295056d564a 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -368,4 +368,23 @@ extern int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu);
#define SPLIT_HACK_MASK 0xff000000
#define SPLIT_HACK_OFFS 0xfb000000
+/* Pack a VCPU ID from the [0..KVM_MAX_VCPU_ID) space down to the
+ * [0..KVM_MAX_VCPUS) space, while using knowledge of the guest's core stride
+ * (but not it's actual threading mode, which is not available) to avoid
+ * collisions.
+ */
+static inline u32 kvmppc_pack_vcpu_id(struct kvm *kvm, u32 id)
+{
+ const int block_offsets[MAX_SMT_THREADS] = {0, 4, 2, 6, 1, 5, 3, 7};
+ int stride = kvm->arch.emul_smt_mode > 1 ?
+ kvm->arch.emul_smt_mode : kvm->arch.smt_mode;
+ int block = (id / KVM_MAX_VCPUS) * (MAX_SMT_THREADS / stride);
+ u32 packed_id;
+
+ BUG_ON(block >= MAX_SMT_THREADS);
+ packed_id = (id % KVM_MAX_VCPUS) + block_offsets[block];
+ BUG_ON(packed_id >= KVM_MAX_VCPUS);
+ return packed_id;
+}
+
#endif /* __ASM_KVM_BOOK3S_H__ */
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 9cb9448163c4..49165cc90051 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1762,7 +1762,7 @@ static int threads_per_vcore(struct kvm *kvm)
return threads_per_subcore;
}
-static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int core)
+static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int id)
{
struct kvmppc_vcore *vcore;
@@ -1776,7 +1776,7 @@ static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int core)
init_swait_queue_head(&vcore->wq);
vcore->preempt_tb = TB_NIL;
vcore->lpcr = kvm->arch.lpcr;
- vcore->first_vcpuid = core * kvm->arch.smt_mode;
+ vcore->first_vcpuid = id;
vcore->kvm = kvm;
INIT_LIST_HEAD(&vcore->preempt_list);
@@ -1992,12 +1992,18 @@ static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
mutex_lock(&kvm->lock);
vcore = NULL;
err = -EINVAL;
- core = id / kvm->arch.smt_mode;
+ if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+ BUG_ON(kvm->arch.smt_mode != 1);
+ core = kvmppc_pack_vcpu_id(kvm, id);
+ } else {
+ core = id / kvm->arch.smt_mode;
+ }
if (core < KVM_MAX_VCORES) {
vcore = kvm->arch.vcores[core];
+ BUG_ON(cpu_has_feature(CPU_FTR_ARCH_300) && vcore);
if (!vcore) {
err = -ENOMEM;
- vcore = kvmppc_vcore_create(kvm, core);
+ vcore = kvmppc_vcore_create(kvm, id & ~(kvm->arch.smt_mode - 1));
kvm->arch.vcores[core] = vcore;
kvm->arch.online_vcores++;
}
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index f9818d7d3381..681dfe12a5f3 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -317,6 +317,11 @@ static int xive_select_target(struct kvm *kvm, u32 *server, u8 prio)
return -EBUSY;
}
+static u32 xive_vp(struct kvmppc_xive *xive, u32 server)
+{
+ return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server);
+}
+
static u8 xive_lock_and_mask(struct kvmppc_xive *xive,
struct kvmppc_xive_src_block *sb,
struct kvmppc_xive_irq_state *state)
@@ -1084,7 +1089,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev,
pr_devel("Duplicate !\n");
return -EEXIST;
}
- if (cpu >= KVM_MAX_VCPUS) {
+ if (cpu >= KVM_MAX_VCPU_ID) {
pr_devel("Out of bounds !\n");
return -EINVAL;
}
@@ -1098,7 +1103,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev,
xc->xive = xive;
xc->vcpu = vcpu;
xc->server_num = cpu;
- xc->vp_id = xive->vp_base + cpu;
+ xc->vp_id = xive_vp(xive, cpu);
xc->mfrr = 0xff;
xc->valid = true;
--
2.16.1.74.g9b0b1f47b
^ permalink raw reply related
* Re: [GIT PULL] asm-generic fixes for v4.17-rc1
From: Arnd Bergmann @ 2018-04-12 7:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sinan Kaya, linuxppc-dev, linux-rdma, linux-s390, Linux ARM,
linux-arch, Linux Kernel Mailing List, Martin Schwidefsky,
Heiko Carstens, Ley Foon Tan, moderated list:NIOS2 ARCHITECTURE,
Michal Simek, moderated list:H8/300 ARCHITECTURE, Yoshinori Sato,
sparclinux, David S. Miller, Guan Xuetao, linux-xtensa, openrisc
In-Reply-To: <CA+55aFx4_gaBeffy9roFRnkB30fnRa=nhh5qR=o=CgrWmgphiw@mail.gmail.com>
On Thu, Apr 12, 2018 at 1:16 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Apr 11, 2018 at 8:40 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> are available in the git repository at:
>>
>> git+ssh://gitolite@ra.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
>> tags/asm-generic
>
> Yeah, no they aren't available there at all.
>
> That tag is some old tag from two years ago that just contains your
> ancient "asm-generic: use compat version for preadv2 and pwritev2".
>
> Forgot to push out? Or forgot to use "-f" to overwrite the old tag?
Yes, something like that, I first tagged the local branch in the wrong
tree which had an old branch of the same name, noticed my mistake
as I pushed it, but then screwed up again when I tried to correct it:
I force-pushed the correct branch again, but not the tag.
Pushed the right tag now, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
tags/asm-generic
Arnd
^ permalink raw reply
* Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
From: Russell King - ARM Linux @ 2018-04-12 9:58 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: Eric W. Biederman, linux-sparc, linuxppc-dev, Linus Torvalds,
linux-kernel, linux-arm-kernel
In-Reply-To: <20180412013435.GA21219@altlinux.org>
On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> A similar commit v4.16-rc1~159^2~37
> ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have
> introduced a similar ABI regression to compat arm.
So, could you explain how can this change cause a regression?
+#define FPE_FIXME 0
- vfp_raise_sigfpe(0, regs);
+ vfp_raise_sigfpe(FPE_FIXME, regs);
I think you're talking garbage here - look at the damned change.
It subsitutes a definition for a constant, and vfp_raise_sigfpe()
ends up receiving exactly the same value bother before and after
the change.
The change is rather incomplete though because it should have
also changed:
int si_code = 0;
as well.
So, the commit log is accurate in this case: it _is_ about
documenting the conflicting cases between SI_USER and SIGFPE and
that bit of the change has no ABI effect.
What does slightly annoy me is the creation of uapi/asm/siginfo.h
to contain a definition that _isn't_ to be exposed as part of the
UAPI. If it's not part of the UAPI, it doesn't belong in a UAPI
header, period. In any case, I don't think that is exposed to
userspace.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
From: Dmitry V. Levin @ 2018-04-12 11:03 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Eric W. Biederman, sparclinux, linuxppc-dev, Linus Torvalds,
linux-kernel, linux-arm-kernel
In-Reply-To: <20180412095811.GC16141@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
On Thu, Apr 12, 2018 at 10:58:11AM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> > A similar commit v4.16-rc1~159^2~37
> > ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have
> > introduced a similar ABI regression to compat arm.
>
> So, could you explain how can this change cause a regression?
>
> +#define FPE_FIXME 0
> - vfp_raise_sigfpe(0, regs);
> + vfp_raise_sigfpe(FPE_FIXME, regs);
No, this hunk hasn't caused the regression, but another one did:
diff --git a/arch/arm/include/uapi/asm/siginfo.h b/arch/arm/include/uapi/asm/siginfo.h
new file mode 100644
index 0000000..d051388
--- /dev/null
+++ b/arch/arm/include/uapi/asm/siginfo.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_SIGINFO_H
+#define __ASM_SIGINFO_H
+
+#include <asm-generic/siginfo.h>
+
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+#endif
This is due to FPE_FIXME handling in kernel/signal.c
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply related
* [PATCH] cxl: Set the PBCQ Tunnel BAR register when enabling capi mode
From: Philippe Bergheaud @ 2018-04-12 11:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: fbarrat, clombard, benh, Philippe Bergheaud
Skiboot used to set the default Tunnel BAR register value when capi mode
was enabled. This approach was ok for the cxl driver, but prevented other
drivers from choosing different values.
Skiboot versions > 5.11 will not set the default value any longer. This
patch modifies the cxl driver to set/reset the Tunnel BAR register when
entering/exiting the cxl mode, with pnv_pci_set_tunnel_bar().
Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com>
---
drivers/misc/cxl/pci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 83f1d08058fc..3beff9188446 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1742,6 +1742,9 @@ static int cxl_configure_adapter(struct cxl *adapter, struct pci_dev *dev)
/* Required for devices using CAPP DMA mode, harmless for others */
pci_set_master(dev);
+ if ((rc = pnv_pci_set_tunnel_bar(dev, 0x00020000E0000000ull, 1)))
+ goto err;
+
if ((rc = pnv_phb_to_cxl_mode(dev, adapter->native->sl_ops->capi_mode)))
goto err;
@@ -1768,6 +1771,7 @@ static void cxl_deconfigure_adapter(struct cxl *adapter)
{
struct pci_dev *pdev = to_pci_dev(adapter->dev.parent);
+ pnv_pci_set_tunnel_bar(pdev, 0x00020000E0000000ull, 0);
cxl_native_release_psl_err_irq(adapter);
cxl_unmap_adapter_regs(adapter);
--
2.16.2
^ permalink raw reply related
* [PATCH v4] mm: remove odd HAVE_PTE_SPECIAL
From: Laurent Dufour @ 2018-04-12 11:48 UTC (permalink / raw)
To: linux-kernel, linux-mm, mhocko, akpm
Cc: linuxppc-dev, x86, linux-doc, linux-snps-arc, linux-arm-kernel,
linux-riscv, linux-s390, linux-sh, sparclinux, Jerome Glisse,
aneesh.kumar, benh, paulus, Jonathan Corbet, Catalin Marinas,
Will Deacon, Yoshinori Sato, Rich Felker, David S . Miller,
Thomas Gleixner, Ingo Molnar, Vineet Gupta, Palmer Dabbelt,
Albert Ou, Martin Schwidefsky, Heiko Carstens, David Rientjes,
Robin Murphy, Christophe LEROY
In-Reply-To: <20180411110936.GG23400@dhcp22.suse.cz>
Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.
There is no functional change introduced by this patch
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
mm/memory.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 96910c625daa..345e562a138d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -817,17 +817,12 @@ static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr,
* PFNMAP mappings in order to support COWable mappings.
*
*/
-#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
-# define HAVE_PTE_SPECIAL 1
-#else
-# define HAVE_PTE_SPECIAL 0
-#endif
struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
pte_t pte, bool with_public_device)
{
unsigned long pfn = pte_pfn(pte);
- if (HAVE_PTE_SPECIAL) {
+ if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) {
if (likely(!pte_special(pte)))
goto check_pfn;
if (vma->vm_ops && vma->vm_ops->find_special_page)
@@ -862,7 +857,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
return NULL;
}
- /* !HAVE_PTE_SPECIAL case follows: */
+ /* !CONFIG_ARCH_HAS_PTE_SPECIAL case follows: */
if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
if (vma->vm_flags & VM_MIXEDMAP) {
@@ -881,6 +876,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
if (is_zero_pfn(pfn))
return NULL;
+
check_pfn:
if (unlikely(pfn > highest_memmap_pfn)) {
print_bad_pte(vma, addr, pte, NULL);
@@ -904,7 +900,7 @@ struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long addr,
/*
* There is no pmd_special() but there may be special pmds, e.g.
* in a direct-access (dax) mapping, so let's just replicate the
- * !HAVE_PTE_SPECIAL case from vm_normal_page() here.
+ * !CONFIG_ARCH_HAS_PTE_SPECIAL case from vm_normal_page() here.
*/
if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
if (vma->vm_flags & VM_MIXEDMAP) {
@@ -1933,7 +1929,8 @@ static int __vm_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
* than insert_pfn). If a zero_pfn were inserted into a VM_MIXEDMAP
* without pte special, it would there be refcounted as a normal page.
*/
- if (!HAVE_PTE_SPECIAL && !pfn_t_devmap(pfn) && pfn_t_valid(pfn)) {
+ if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) &&
+ !pfn_t_devmap(pfn) && pfn_t_valid(pfn)) {
struct page *page;
/*
--
2.7.4
^ permalink raw reply related
* Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
From: Russell King - ARM Linux @ 2018-04-12 12:19 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: Eric W. Biederman, sparclinux, linuxppc-dev, Linus Torvalds,
linux-kernel, linux-arm-kernel
In-Reply-To: <20180412110314.GA28070@altlinux.org>
On Thu, Apr 12, 2018 at 02:03:14PM +0300, Dmitry V. Levin wrote:
> On Thu, Apr 12, 2018 at 10:58:11AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> > > A similar commit v4.16-rc1~159^2~37
> > > ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have
> > > introduced a similar ABI regression to compat arm.
> >
> > So, could you explain how can this change cause a regression?
> >
> > +#define FPE_FIXME 0
> > - vfp_raise_sigfpe(0, regs);
> > + vfp_raise_sigfpe(FPE_FIXME, regs);
>
> No, this hunk hasn't caused the regression, but another one did:
>
> diff --git a/arch/arm/include/uapi/asm/siginfo.h b/arch/arm/include/uapi/asm/siginfo.h
> new file mode 100644
> index 0000000..d051388
> --- /dev/null
> +++ b/arch/arm/include/uapi/asm/siginfo.h
> @@ -0,0 +1,13 @@
> +#ifndef __ASM_SIGINFO_H
> +#define __ASM_SIGINFO_H
> +
> +#include <asm-generic/siginfo.h>
> +
> +/*
> + * SIGFPE si_codes
> + */
> +#ifdef __KERNEL__
> +#define FPE_FIXME 0 /* Broken dup of SI_USER */
> +#endif /* __KERNEL__ */
> +
> +#endif
>
> This is due to FPE_FIXME handling in kernel/signal.c
Building strace 4.22 on ARM and running the test suite reveals no
problems with the signal_receive test, tested on both 4.14 and 4.16
kernels - there's no "KERNEL BUG" reports in any of the test results.
However, stock strace 4.22 source doesn't appear to contain the
"KERNEL BUG" string anywhere, so this may be a Suse specific addition
to the test:
~/src/strace-4.22$ grep -ri 'KERNEL BUG' .
./strace.1:Arguably, every instance of such behavior is a kernel bug.)
./strace.1.in:Arguably, every instance of such behavior is a kernel bug.)
./NEWS: * Worked around a kernel bug in tracing privileged executables.
./ChangeLog: aarch64: workaround gcc+kernel bug.
./ChangeLog: tests: workaround kernel bugs in seccomp-strict.test and prctl-seccomp-strict.test
./ChangeLog: instead. We don't want the testsuite failing due to kernel bugs.
./ChangeLog: First guess is that it's a workaround for old kernel bugs:
./ChangeLog: This kernel bug is fixed long ago. This change removes the workaround.
Any ideas where the "KERNEL BUG" in Suse builds is coming from? Any
ideas how to test it on other architectures (iow, where can we get
source that contains this test?)
Based on previous experience, unfortunately folk don't tend to report
user ABI regressions to kernel developers, so we'd probably never know
that there's a problem - I do think the safer thing would've been to
leave it well alone, and just accept that we'll end up copying more
words to userspace than is actually intended.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid
From: Dmitry V. Levin @ 2018-04-12 12:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Eric W. Biederman, sparclinux, linuxppc-dev, Linus Torvalds,
linux-kernel, linux-arm-kernel
In-Reply-To: <20180412121949.GD16141@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]
On Thu, Apr 12, 2018 at 01:19:49PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 12, 2018 at 02:03:14PM +0300, Dmitry V. Levin wrote:
> > On Thu, Apr 12, 2018 at 10:58:11AM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> > > > A similar commit v4.16-rc1~159^2~37
> > > > ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have
> > > > introduced a similar ABI regression to compat arm.
> > >
> > > So, could you explain how can this change cause a regression?
> > >
> > > +#define FPE_FIXME 0
> > > - vfp_raise_sigfpe(0, regs);
> > > + vfp_raise_sigfpe(FPE_FIXME, regs);
> >
> > No, this hunk hasn't caused the regression, but another one did:
> >
> > diff --git a/arch/arm/include/uapi/asm/siginfo.h b/arch/arm/include/uapi/asm/siginfo.h
> > new file mode 100644
> > index 0000000..d051388
> > --- /dev/null
> > +++ b/arch/arm/include/uapi/asm/siginfo.h
> > @@ -0,0 +1,13 @@
> > +#ifndef __ASM_SIGINFO_H
> > +#define __ASM_SIGINFO_H
> > +
> > +#include <asm-generic/siginfo.h>
> > +
> > +/*
> > + * SIGFPE si_codes
> > + */
> > +#ifdef __KERNEL__
> > +#define FPE_FIXME 0 /* Broken dup of SI_USER */
> > +#endif /* __KERNEL__ */
> > +
> > +#endif
> >
> > This is due to FPE_FIXME handling in kernel/signal.c
>
> Building strace 4.22 on ARM and running the test suite reveals no
> problems with the signal_receive test, tested on both 4.14 and 4.16
> kernels - there's no "KERNEL BUG" reports in any of the test results.
https://build.opensuse.org/public/build/home:ldv_alt/openSUSE_Factory_ARM/armv7l/strace/_log
- the test just fails there with
[ 50s] + uname -a
[ 50s] Linux armbuild01 4.16.0-1-lpae #1 SMP PREEMPT Wed Apr 4 13:35:56 UTC 2018 (e16f96d) armv7l armv7l armv7l GNU/Linux
...
[ 570s] FAIL: signal_receive.gen
[ 570s] ---- SIGFPE {si_signo=SIGFPE, si_code=SI_USER, si_pid=25332, si_uid=399} ---
[ 570s] +--- SIGFPE {si_signo=SIGFPE, si_code=SI_USER, si_pid=25332, si_uid=0} ---
[ 570s] signal_receive.gen.test: failed test: ../../strace -a16 -e trace=kill ../signal_receive output mismatch
> However, stock strace 4.22 source doesn't appear to contain the
> "KERNEL BUG" string anywhere, so this may be a Suse specific addition
> to the test:
The "KERNEL BUG" diagnostics I was talking about was added to strace yesterday
as a part of workaround commit, see
https://github.com/strace/strace/commit/34c7794cc16e2511eda7b1d5767c655a83b17309
Before that change the test just failed.
[...]
> Any ideas where the "KERNEL BUG" in Suse builds is coming from?
strace developers use OBS to test strace.git for regressions.
The build environment is provided by OBS, all the rest comes from strace.git.
> Any ideas how to test it on other architectures (iow, where can we get
> source that contains this test?)
Just use master branch of https://github.com/strace/strace
or https://gitlab.com/strace/strace (they are the same).
> Based on previous experience, unfortunately folk don't tend to report
> user ABI regressions to kernel developers, so we'd probably never know
> that there's a problem - I do think the safer thing would've been to
> leave it well alone, and just accept that we'll end up copying more
> words to userspace than is actually intended.
Well, these changes caused visible regressions in strace test suite on arm, ppc,
and sparc - this is the reason why I have reported them to kernel developers.
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox