; >> in segment
> > >> s390x-linux-ld: vmlinux.unstripped: warning: allocated section
> > >> `.modinfo' not in segment
>
> Thank you for root-causing!
>
> > Cc: Heiko Carstens
> > Cc: Vasily Gorbik
> > Cc: Alexander Gordeev
> > Cc
, following
> the kernel's general convention for distinguishing code-generated text
> sections from compiler-generated ones.
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Alexander Gordeev
> Signed-off-by: Josh Poimboeuf
> ---
> arch/s390/include/asm/
On Fri, Apr 11, 2025 at 01:11:55PM +0200, Christian Borntraeger wrote:
> Am 10.04.25 um 20:44 schrieb David Hildenbrand:
> [...]
> > > ---
> >
> > So, given that
> >
> > (a) people are actively running into this
> > (b) we'll have to backport this quite a lot
> > (c) the spec issue is not a s390x
On Tue, Mar 25, 2025 at 07:48:48AM +0100, Thomas Weißschuh wrote:
> On Mon, Mar 24, 2025 at 04:55:13PM +0100, Heiko Carstens wrote:
> > On Mon, Mar 24, 2025 at 03:03:17PM +0100, Thomas Weißschuh wrote:
> > > s390 does not provide a hwcap.h UAPI header.
> > >
> > &
On Mon, Mar 24, 2025 at 03:03:17PM +0100, Thomas Weißschuh wrote:
> s390 does not provide a hwcap.h UAPI header.
>
> Add an inline definition for the constant HWCAP_S390_VXRS until a proper
> UAPI header is introduced.
>
> Fixes: 210860e7f733 ("selftests: vDSO: check cpu caps before running chach
On Thu, Oct 10, 2024 at 02:31:31PM +0200, David Hildenbrand wrote:
> On 10.10.24 10:41, Mario Casquero wrote:
> > This series has been successfully tested along with the QEMU's series.
> > Virtio-mem devices could be resized, plugged and unplugged seamlessly.
> > The memory information displayed is
On Mon, Oct 07, 2024 at 10:10:30PM +0200, Halil Pasic wrote:
> At least since commit 334304ac2bac ("dma-mapping: don't return errors
> from dma_set_max_seg_size") setting up device.dma_parms is basically
> mandated by the DMA API. As of now Channel (CCW) I/O in general does not
> utilize the DMA AP
/elfclass.h).
Fixes: 40723419f407 ("kselftest: Enable vDSO test on non x86 platforms")
Reported-by: Heiko Carstens
Tested-by: Heiko Carstens
Signed-off-by: Jens Remus
Signed-off-by: Heiko Carstens
---
tools/testing/selftests/vDSO/parse_vdso.c | 14 ++
1 file changed, 10
he correct
check must make sure that only __s390__ is defined.
Therefore add the missing !defined(__s390x__). Also use common
__s390x__ define instead of __s390X__.
Signed-off-by: Heiko Carstens
---
tools/testing/selftests/vDSO/vdso_config.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
Two s390 fixes to make vdso selftests running on s390.
Jason, given that you carry already a lot of changes for vdso
selftests I guess these should be routed via the random tree.
Patches apply on top of current random.git master branch.
Thanks,
Heiko
Heiko Carstens (1):
selftests: vDSO: fix
On Thu, Jan 04, 2024 at 11:03:42AM +0100, Alexander Gordeev wrote:
> On Tue, Jan 02, 2024 at 04:05:31PM +0100, Heiko Carstens wrote:
> Hi Heiko,
> ...
> > > @@ -253,9 +253,17 @@ static unsigned long setup_kernel_memory_layout(void)
> > > MODULES_END = round_down(_
On Thu, Dec 14, 2023 at 12:24:54AM +0100, Ilya Leoshkevich wrote:
> Now that everything else is in place, enable KMSAN in Kconfig.
>
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Heiko Carstens
: Ilya Leoshkevich
> ---
> arch/s390/include/asm/kmsan.h | 43 +++
> 1 file changed, 43 insertions(+)
Acked-by: Heiko Carstens
wed-by: Alexander Potapenko
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/boot/string.c| 16
> arch/s390/include/asm/string.h | 20 +++-----
> 2 files changed, 31 insertions(+), 5 deletions(-)
Acked-by: Heiko Carstens
penko
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/kernel/unwind_bc.c | 4
> 1 file changed, 4 insertions(+)
Acked-by: Heiko Carstens
| 6 ++
> 1 file changed, 6 insertions(+)
Acked-by: Heiko Carstens
+ \
> + KMSAN_VMALLOC_SIZE)
> +#define KMSAN_MODULES_SHADOW_START (KMSAN_VMALLOC_ORIGIN_START + \
> + KMSAN_VMALLOC_SIZE)
Long single lines for these, please :)
With that, and Alexander Gordeev's comments addressed:
Acked-by: Heiko Carstens
On Thu, Dec 14, 2023 at 12:24:47AM +0100, Ilya Leoshkevich wrote:
> KMSAN generates the following false positives on s390x:
>
> [6.063666] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
> [ ...]
> [6.577050] Call Trace:
> [6.619637] [<0690d2de>] check_flags+0x1fe/0x21
On Thu, Dec 14, 2023 at 12:24:45AM +0100, Ilya Leoshkevich wrote:
> Diagnose 224 stores 4k bytes, which cannot be deduced from the inline
> assembly constraints. This leads to KMSAN false positives.
>
> Unpoison the output buffer manually with kmsan_unpoison_memory().
>
> Signed-off-by: Ilya Leos
ings when running the ftrace testsuite.
>
> Fix by trusting the assembly code and always unpoisoning ftrace_regs in
> kprobe_ftrace_handler().
>
> Reviewed-by: Alexander Potapenko
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/kernel/ftrace.c | 2 ++
> 1 fi
whole dest manually with kmsan_unpoison_memory().
>
> Reported-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/include/asm/cpu_mf.h | 6 ++
> 1 file changed, 6 insertions(+)
Acked-by: Heiko Carstens
; arch/s390/include/asm/cpacf.h | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Heiko Carstens
On Thu, Nov 23, 2023 at 10:23:49AM -0500, Steven Rostedt wrote:
> On Thu, 23 Nov 2023 12:25:48 +0100
> Heiko Carstens wrote:
>
> > So, if it helps (this still happens with Linus' master branch):
> >
> > create_dir_dentry() is called with a "struct eve
On Fri, Nov 17, 2023 at 03:38:29PM +0100, Heiko Carstens wrote:
> On Fri, Nov 17, 2023 at 03:23:35PM +0100, Heiko Carstens wrote:
> > I think this patch causes from time to time crashes when running ftrace
> > selftests. In particular I guess there is a bug wrt error handling in th
On Fri, Nov 17, 2023 at 03:23:35PM +0100, Heiko Carstens wrote:
> I think this patch causes from time to time crashes when running ftrace
> selftests. In particular I guess there is a bug wrt error handling in this
> function (see below for call trace):
>
> > +st
Hi Steven,
On Wed, Oct 04, 2023 at 04:50:07PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Instead of having a descriptor for every file represented in the eventfs
> directory, only have the directory itself represented. Change the API to
> send in a list of entries that re
--
> 11 files changed, 54 insertions(+), 192 deletions(-)
for the s390 bits:
Acked-by: Heiko Carstens
On Thu, Apr 15, 2021 at 11:47:26AM +0100, Marc Zyngier wrote:
> On Thu, 15 Apr 2021 11:38:52 +0100,
> Heiko Carstens wrote:
> >
> > On Wed, Apr 14, 2021 at 02:44:07PM +0100, Marc Zyngier wrote:
> > > perf_pmu_name() and perf_num_counters() are unused. Drop them.
>
On Wed, Apr 14, 2021 at 02:44:07PM +0100, Marc Zyngier wrote:
> perf_pmu_name() and perf_num_counters() are unused. Drop them.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/s390/kernel/perf_event.c | 21 -
> 1 file changed, 21 deletions(-)
Acked-by: Heiko C
Hi Linux,
please pull two small s390 patches. This is also supposed to be the
last s390 pull request for 5.12. There are no known bugs left.
Thanks,
Heiko
The following changes since commit ad31a8c05196a3dc5283b193e9c74a72022d3c65:
s390/setup: use memblock_free_late() to free old stack (2021-
clobbering due to KASAN code instrumentation.
Alexander Gordeev (1):
s390/cpcmd: fix inline assembly register clobbering
Heiko Carstens (2):
s390/irq: fix reading of ext_params2 field from lowcore
s390/setup: use
On Wed, Apr 07, 2021 at 07:34:16AM +0200, Greg Kroah-Hartman wrote:
> The common scripts/install.sh script will now work for s390, no changes
> needed. So call that instead and delete the s390-only install script.
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian
and update of vdso data pages, which
results in incorrect tod clock steering, and that
clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns incorrect values.
- update MAINTAINERS for s390 vfio drivers
Heiko Carstens (3):
s390/vdso
On Thu, Mar 25, 2021 at 04:56:18PM +0800, Li Wang wrote:
> Hi Heiko,
>
> On Wed, Mar 24, 2021 at 5:58 AM Heiko Carstens wrote:
>
> > Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) does not
> > work correctly on s390 via vdso. Debugging this also revea
On Tue, Mar 23, 2021 at 10:58:17PM +0100, Heiko Carstens wrote:
> The s390 specific vdso function __arch_get_hw_counter() is supposed to
> consider tod clock steering.
>
> If a tod clock steering event happens and the tod clock is set to a
> new value __arch_get_hw_counter() will
On Tue, Mar 23, 2021 at 10:58:18PM +0100, Heiko Carstens wrote:
> Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns
> incorrect values when time is provided via vdso instead of system call:
>
> vdso_ts_nsec = 4484351380985507, vdso_ts.tv_sec = 4484351, vds
plify __arch_get_hw_counter()")
Fixes: eeab78b05d20 ("s390/vdso: implement generic vdso time namespace support")
Link: https://lore.kernel.org/linux-s390/YFnxr1ZlMIOIqjfq@osiris
Signed-off-by: Heiko Carstens
---
arch/s390/Kconfig | 1 -
arch/s390/include/asm/vdso.h
the first
element of the _vdso_data array and not at all within the _timens_data
array.
Instead of working around this simply provide an s390 specific vdso
data page which contains the tod clock steering parameters.
This allows also to remove ARCH_HAS_VDSO_DATA again.
Heiko Carstens (3):
s390
Since commit d60d7de3e16d ("lib/vdso: Allow to add architecture-specific
vdso data") it is possible to provide arch specific VDSO data.
This was only added for s390, which doesn't make use this anymore.
Therefore remove it again.
Signed-off-by: Heiko Carstens
---
arch/Kconfig
two.
Fix this by simply providing the missing value to user space.
Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
Cc: # 5.10
Signed-off-by: Heiko Carstens
---
arch/s390/kernel/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/kernel/time.c b/arch/s390/ker
On Tue, Mar 23, 2021 at 08:11:41AM +0100, Heiko Carstens wrote:
> On Tue, Mar 23, 2021 at 02:21:52PM +0800, Li Wang wrote:
> > Hi linux-s390 experts,
> >
> > We observed that LTP/clock_gettime04 always FAIL on s390x with
> > kernel-v5.12-rc3.
> > To simply sh
On Tue, Mar 23, 2021 at 02:21:52PM +0800, Li Wang wrote:
> Hi linux-s390 experts,
>
> We observed that LTP/clock_gettime04 always FAIL on s390x with
> kernel-v5.12-rc3.
> To simply show the problem, I rewrite the LTP reproducer as a simple C
> below.
> Maybe it's a new bug introduced from the kern
On Mon, Mar 22, 2021 at 06:35:33PM +0530, Bhaskar Chowdhury wrote:
>
> s/defintions/definitions/
> s/intermedate/intermediate/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> arch/s390/crypto/crc32be-vx.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
On Mon, Mar 22, 2021 at 10:53:46AM +0100, David Hildenbrand wrote:
> > > diff --git a/arch/s390/kvm/gaccess.h b/arch/s390/kvm/gaccess.h
> > > index daba10f76936..7c72a5e3449f 100644
> > > --- a/arch/s390/kvm/gaccess.h
> > > +++ b/arch/s390/kvm/gaccess.h
> > > @@ -18,17 +18,14 @@
> > >/**
> > >
On Mon, Mar 22, 2021 at 11:55:00AM +0530, Bhaskar Chowdhury wrote:
>
> s/struture/structure/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> arch/s390/kernel/os_info.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/kernel/os_info.c b/arch/s390/kernel/os_info.c
Hi Linus,
please pull three s390 specific bug fixes for 5.12-rc4.
Thanks,
Heiko
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/s39
On Fri, Mar 19, 2021 at 05:59:50PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Warning: Some of the branches in linux-next may still based on v5.12-rc1,
> so please be careful if you are trying to bisect a bug.
>
> News: if your -next included tree is based on Linus' tree tag
> v5.12-rc1{,-dontu
On Thu, Mar 18, 2021 at 10:05:01AM -0700, Nick Desaulniers wrote:
> (Replying to
> https://lore.kernel.org/linux-s390/ca+g9fytbw0hav5ooayck2rz_m2sj73krxpj0idzt+o8qtc1...@mail.gmail.com/)
>
> Yeah, our CI is failing today, too with the same error on linux-next:
> https://github.com/ClangBuiltLinux
> with the swap entry before calling swap_readpage().
>
> Signed-off-by: Shakeel Butt
> Reported-by: Heiko Carstens
> ---
>
> Andrew, please squash this into "memcg: charge before adding to
> swapcache on swapin" patch.
>
> mm/memory.c | 4
> 1 fil
On Wed, Mar 17, 2021 at 07:42:41PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> News: there will be no linux-next release on Friday this week.
>
> Warning: Some of the branches in linux-next are still based on v5.12-rc1,
> so please be careful if you are trying to bisect a bug.
>
> News: if your
90: remove IBM_PARTITION and CONFIGFS_FS from zfcpdump defconfig
Eric Farman (1):
s390/cio: return -EFAULT if copy_to_user() fails
Heiko Carstens (4):
s390/time,idle: get rid of unsigned long long
s390/topology: remove always false if check
s390,alpha: make TMPFS_INODE64
| 5 -
> mm/Kconfig | 9
> 15 files changed, 48 insertions(+), 122 deletions(-)
for the s390 bits:
Acked-by: Heiko Carstens
On Mon, Mar 01, 2021 at 01:07:26PM -0500, Eric Farman wrote:
>
>
> On 3/1/21 8:13 AM, Heiko Carstens wrote:
> > On Mon, Mar 01, 2021 at 08:01:33PM +0800, Wang Qing wrote:
> > > The copy_to_user() function returns the number of bytes remaining to be
> > > copied,
On Mon, Mar 01, 2021 at 08:01:33PM +0800, Wang Qing wrote:
> The copy_to_user() function returns the number of bytes remaining to be
> copied, but we want to return -EFAULT if the copy doesn't complete.
>
> Signed-off-by: Wang Qing
> ---
> drivers/s390/cio/vfio_ccw_ops.c | 4 ++--
> 1 file chang
On Mon, Mar 01, 2021 at 08:08:21PM +0800, Wang Qing wrote:
> The copy_to_user() function returns the number of bytes remaining to be
> copied, but we want to return -EFAULT if the copy doesn't complete.
>
> Signed-off-by: Wang Qing
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 2 +-
> 1 file chang
On Tue, Feb 23, 2021 at 09:41:40AM -0800, Guenter Roeck wrote:
> > I tried to explain why we don't want to set COMPILE_TEST for s390
> > anymore. It overrides architecture dependencies in Kconfig, and lots
> > of drivers do not set dependencies for HAS_IOMEM, HAS_DMA, and friends
> > correctly.
> >
On Mon, Feb 22, 2021 at 08:03:31AM -0800, Guenter Roeck wrote:
> > Maybe, we can add something like CONFIG_SUPPRESS_NOISY_TESTS,
> > which is set to y by all{yes,mod}config.
> >
> > This is self-documenting, so we do not need the '# too noisy' comment.
> >
> >
> >
> > config SUPPRESS_NOISY_TEST
C_PLUGIN_CYC_COMPLEXITY is primarily used for testing, disable it
> when building s390 images.
>
> Cc: Arnd Bergmann
> Cc: Heiko Carstens
> Fixes: 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")
> Signed-off-by: Guenter Roeck
> ---
> scripts/gcc-
On Sat, Feb 20, 2021 at 04:22:37PM +0800, Yang Li wrote:
> This eliminates the following coccicheck warning:
> ./arch/s390/tools/gen_facilities.c:154:37-38: WARNING: Use ARRAY_SIZE
> ./arch/s390/tools/gen_opcode_table.c:141:39-40: WARNING: Use ARRAY_SIZE
>
> Reported-by: Abaci Robot
> Signed-off-
Hi Vlad,
> > Build fails on s390 using defconfig with:
> >
> > In file included from drivers/net/ethernet/mellanox/mlx5/core/en_tc.h:40,
> > from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:45:
> > drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.h:24:29: error: field
> >
On Thu, Feb 11, 2021 at 10:26:04PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210210:
>
> The powerpc tree still had its build failure in the allyesconfig for
> which I applied a supplied patch.
>
> The v4l-dvb tree lost its build failure.
>
> The drm-misc tree lost its build
"inode64" in the mount options and thus passes it in the
> options for the remount.
>
>
> So prevent CONFIG_TMPFS_INODE64 from being selected on s390.
>
> Link:
> https://lkml.kernel.org/r/20210205230620.518245-1-seth.fors...@canonical.com
> Fixes: ea3271f7196
On Tue, Jan 19, 2021 at 11:25:01AM +0100, Christian Borntraeger wrote:
> > + if (user_mode(regs)) {
> > + send_sig(SIGSEGV, current, 0);
> > + return;
> > + } else
> > + panic("Unexpected PGM 0x3d with TEID bit 61=0");
>
> u
On Wed, Jan 20, 2021 at 03:39:14PM +0100, Christian Borntraeger wrote:
> On 20.01.21 14:42, Heiko Carstens wrote:
> > On Tue, Jan 19, 2021 at 11:25:01AM +0100, Christian Borntraeger wrote:
> >>> + if (user_mode(regs)) {
> >>> +
gt; arch/s390/configs/defconfig | 1 -
> arch/s390/oprofile/Makefile | 10 -
> arch/s390/oprofile/init.c | 37 ---
> 6 files changed, 53 deletions(-)
> delete mode 100644 arch/s390/oprofile/Makefile
> delete mode 100644 arch/s390/oprofile/init.c
Acked-by: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: "David S. Miller"
Fixes: b0a0c2615f6f ("epoll: wire up syscall epoll_pwait2")
Signed-off-by: Heiko Carstens
---
arch/arm64/include/asm/unistd32.h | 2 +-
arch/mips/kernel/syscalls/syscall_n32.tbl | 2 +-
arch/s390/kerne
avoid rare interrupt stack corruption.
- Simplify udelay() and just let it busy loop instead of implementing a
complex logic.
- arch_cpu_idle() cleanup.
- Some other minor improvements.
--------
Heiko Carstens (10):
s390: always cl
On Wed, Dec 16, 2020 at 06:52:59PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 15, 2020 at 02:47:24PM -0500, Steven Rostedt wrote:
> > On Tue, 15 Dec 2020 20:01:52 +0100
> > Heiko Carstens wrote:
> >
> > > Hello,
> > >
> > > the ftrace stack trace
On Wed, Dec 16, 2020 at 06:52:59PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 15, 2020 at 02:47:24PM -0500, Steven Rostedt wrote:
> > On Tue, 15 Dec 2020 20:01:52 +0100
> > Heiko Carstens wrote:
> >
> > > Hello,
> > >
> > > the ftrace stack trace
Hello,
the ftrace stack tracer kernel selftest is able to trigger the warning
below from time to time. This looks like there is an ordering problem
in __local_bh_enable_ip():
first there is a call to lockdep_softirqs_on() and afterwards
preempt_count_sub() is ftraced before it was able to modify
p
s390/crypto: add arch_get_random_long() support
Heiko Carstens (15):
s390: fix system call exit path
s390/mm: extend default vmalloc area size to 512GB
s390/mm: let vmalloc area size depend on physical memory size
s390: update defconfigs
s390/mm: remove unused clear
On Thu, Dec 10, 2020 at 08:25:48PM +0100, Thomas Gleixner wrote:
> The irq descriptor is already there, no need to look it up again.
>
> Signed-off-by: Thomas Gleixner
> Cc: Christian Borntraeger
> Cc: Heiko Carstens
> Cc: linux-s...@vger.kernel.org
> ---
> arch/
i.e vmem_get_max_addr() to update in case the maximum address changes
> from VMEM_MAX_PHYS to something else later.
Still not. That's way too much code churn for what you want to achieve.
If the s390 specific patch would look like below you can add
Acked-by: Heiko Carstens
But please make sure
On Wed, Dec 09, 2020 at 08:07:04AM +0530, Anshuman Khandual wrote:
> >> + if (seg->end + 1 > VMEM_MAX_PHYS || seg->end + 1 < seg->start_addr) {
> >> + rc = -ERANGE;
> >> + goto out_resource;
> >> + }
> >> +
...
> >> +struct range arch_get_mappable_range(void)
> >> +{
> >> + str
ith a new
> address range check to preserve the existing functionality. It also adds a
> VM_BUG_ON() check that would ensure that memhp_range_allowed() has already
> been called on the hotplug path.
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: David Hildenbrand
> Cc: linux
)
- fix lockdep irq state tracing
- fix logical vs physical CPU address confusion in PCI code
Alexander Gordeev (1):
s390/pci: fix CPU address in MSI for directed IRQ
Heiko
On Thu, Dec 03, 2020 at 08:28:21AM -0500, Sasha Levin wrote:
> From: Peter Zijlstra
>
> [ Upstream commit 58c644ba512cfbc2e39b758dd979edd1d6d00e27 ]
>
> We call arch_cpu_idle() with RCU disabled, but then use
> local_irq_{en,dis}able(), which invokes tracing, which relies on RCU.
>
> Switch all
On Thu, Dec 03, 2020 at 06:03:00AM +0530, Anshuman Khandual wrote:
> >> diff --git a/arch/s390/mm/extmem.c b/arch/s390/mm/extmem.c
> >> index 5060956b8e7d..cc055a78f7b6 100644
> >> --- a/arch/s390/mm/extmem.c
> >> +++ b/arch/s390/mm/extmem.c
> >> @@ -337,6 +337,11 @@ __segment_load (char *name, int
d error return code ERANGE with E2BIG
>
> Changes in RFC V1:
>
> https://lore.kernel.org/linux-mm/1606098529-7907-1-git-send-email-anshuman.khand...@arm.com/
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ard Biesh
.
>
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: David Hildenbrand
> Cc: linux-s...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual
> ---
> arch/s390/mm/extmem.c | 5 +
> arch/s390/mm/vmem.c | 13 +
On Wed, Dec 02, 2020 at 11:16:05AM +, Mark Rutland wrote:
> On Wed, Dec 02, 2020 at 11:56:49AM +0100, Heiko Carstens wrote:
> > From 7bd86fb3eb039a4163281472ca79b9158e726526 Mon Sep 17 00:00:00 2001
> > From: Heiko Carstens
> > Date: Wed, 2 Dec 2020 11:46:01 +0100
>
On Wed, Dec 02, 2020 at 10:21:16AM +0100, Peter Zijlstra wrote:
> On Tue, Dec 01, 2020 at 08:18:56PM +0100, Heiko Carstens wrote:
> OK, so with a little help from s390/PoO and Sven, the code removed skips
> the TRACE_IRQS_OFF when IRQs were enabled in the old PSW (the previous
On Wed, Dec 02, 2020 at 10:38:05AM +0100, Peter Zijlstra wrote:
> On Wed, Dec 02, 2020 at 08:54:27AM +0100, Heiko Carstens wrote:
> > > > But but but...
> > > >
> > > > do_idle() # IRQs on
> > > > local_irq_disabl
> > But but but...
> >
> > do_idle() # IRQs on
> > local_irq_disable();# IRQs off
> > defaul_idle_call() # IRQs off
> lockdep_hardirqs_on(); # IRQs off, but lockdep things they're on
> > arch_cpu_idle() # IRQs off
> > enabled_wa
On Tue, Dec 01, 2020 at 08:14:41PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 01, 2020 at 06:57:37PM +, Mark Rutland wrote:
> > On Tue, Dec 01, 2020 at 07:15:06PM +0100, Peter Zijlstra wrote:
> > > On Tue, Dec 01, 2020 at 03:55:19PM +0100, Peter Zijlstra wrote:
> > > > On Tue, Dec 01, 2020 at 0
On Sat, Nov 28, 2020 at 09:11:57PM +0530, Souptick Joarder wrote:
> Kernel test robot generates below warning ->
>
> >> arch/s390/kernel/vdso64/getcpu.c:8:5: warning: no previous prototype
> >> for function '__s390_vdso_getcpu' [-Wmissing-prototypes]
>int __s390_vdso_getcpu(unsigned *cpu, unsi
Hi Linus,
please pull one important s390 fix for 5.10-rc6.
Thanks,
Heiko
The following changes since commit 78d732e1f326f74f240d416af9484928303d9951:
s390/cpum_sf.c: fix file permission for cpum_sfb_size (2020-11-12 12:10:36
+0100)
are available in the Git repository at:
git://git.kernel
On Tue, Nov 17, 2020 at 07:34:55PM +0100, Krzysztof Kozlowski wrote:
> > Looking a bit further, I now find that we ended up disabling
> > CONFIG_COMPILE_TEST
> > entirely for arch/um, which is clearly an option that would also work for
> > s390.
>
> Yes, that was the easier solution than to spre
On Mon, Nov 16, 2020 at 10:21:26AM +0100, Arnd Bergmann wrote:
> > Don't we need the dependencies on HAS_IOMEM for the CONFIG_UML=y
> > case, too?
>
> I would have expected that as well, but I don't see the problem when building
> an arch/um kernel, all I get is
>
> ERROR: modpost: "devm_platform
space with
any TIF/CIF/PIF set
- fix file permission for cpum_sfb_size parameter
- another small defconfig update
Heiko Carstens (2):
s390: fix system call exit path
s390: update defconfigs
Thomas Richter (1
ine SECCOMP_ARCH_COMPAT AUDIT_ARCH_S390
> +# define SECCOMP_ARCH_COMPAT_NR NR_syscalls
> +# define SECCOMP_ARCH_COMPAT_NAME"s390"
> +#endif
> +
Acked-by: Heiko Carstens
Gerald Schaefer (1):
s390/mm: make pmd/pud_deref() large page aware
Harald Freudenberger (2):
s390/ap: fix ap devices reference counting
s390/pkey: fix paes selftest failure with paes and pkey static build
Heiko Carstens (3):
s390/vdso: remove empty
On Mon, Nov 02, 2020 at 11:59:41AM -0500, Qian Cai wrote:
> On Sun, 2020-11-01 at 17:31 +0000, Heiko Carstens wrote:
> > On Thu, Oct 29, 2020 at 10:21:11AM -0600, Jens Axboe wrote:
> > > Wire up TIF_NOTIFY_SIGNAL handling for s390.
> > >
> > > Cc: linux-s...
On Sat, Oct 31, 2020 at 07:38:52PM -0400, Qian Cai wrote:
> > > This is avoided by moving the call to rcu_cpu_starting up near the
> > > beginning of the smp_init_secondary() function. Note that the
> > > raw_smp_processor_id() is required in order to avoid calling into
> > > lockdep before RCU has
On Wed, Oct 28, 2020 at 02:27:42PM -0400, Qian Cai wrote:
> The call to rcu_cpu_starting() in smp_init_secondary() is not early
> enough in the CPU-hotplug onlining process, which results in lockdep
> splats as follows:
>
> WARNING: suspicious RCU usage
> -
> kernel/
Hi Linus,
please pull a simple fix, so that s390 compiles again after Joe Perches' commit
33def8498fdd ("treewide: Convert macro and uses of __section(foo) to
__section("foo")")
which went in just before 5.10-rc1.
Thanks,
Heiko
The following changes since commit 3650b228f83adda7e5ee532e2b90429c
On Sat, Sep 12, 2020 at 09:54:12PM -0400, Qian Cai wrote:
> Occasionally, running this LTP test will trigger an error below on
> s390:
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/security/dirtyc0w/dirtyc0w.c
> https://github.com/linux-test-project/ltp/blob/master/testca
On Wed, Sep 16, 2020 at 10:50:29AM +0800, Liu Shixin wrote:
> Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Liu Shixin
> ---
> arch/s390/kernel/diag.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
Applied, thanks.
On Wed, Sep 16, 2020 at 02:21:30PM +0800, Qinglang Miao wrote:
> The spinlock ap_poll_timer_lock is initialized statically. It is
> unnecessary to initialize by spin_lock_init().
>
> Signed-off-by: Qinglang Miao
> ---
> drivers/s390/crypto/ap_bus.c | 1 -
> 1 file changed, 1 deletion(-)
Applied
On Mon, Sep 14, 2020 at 09:36:07AM +0200, Harald Freudenberger wrote:
> Otherwise how to we provide this fix then ? My recommendation would
> be to go the 'usual' way: Commit this s390 internal and then let
> this go out with the next kernel merge window when next time Linus
> is pulling patches fr
1 - 100 of 1008 matches
Mail list logo
