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
tapenko
> 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>]
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
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 file ch
n the 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 eventfs_
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
--
> 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
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()
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
of 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
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
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
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:
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
>
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:
>
> 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
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
> > > copi
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
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
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
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
>
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
t;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: ea3271f7196c (&q
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");
>
>
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)) {
> >>> +
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
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 clear kernel
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
dd 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_user_asce()
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/
em_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 that the a
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)
> >> +{
> >> +
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
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,
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
> >
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
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,
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:
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
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:
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
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
> -
>
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
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
>
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(-)
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
On Tue, Sep 08, 2020 at 03:30:31PM +0200, pet...@infradead.org wrote:
>
> After commit eb1f00237aca ("lockdep,trace: Expose tracepoints") the
> lock tracepoints are visible to lockdep and RCU-lockdep is finding a
> bunch more RCU violations that were previously hidden.
>
> Switch the
- Couple of other minor fixes and improvements.
Alexander Gordeev (2):
s390/numa: set node distance to LOCAL_DISTANCE
s390/numa: move code to arch/s390/kernel
Gerald Schaefer (1):
s390/gmap: improve THP splitting
Heik
On Wed, Aug 05, 2020 at 05:50:53PM +0200, Krzysztof Kozlowski wrote:
> The VFIO_AP uses ap_driver_register() (and deregister) functions
> implemented in ap_bus.c (compiled into ap.o). However the ap.o will be
> built only if CONFIG_ZCRYPT is selected.
>
> This was not visible before commit
On Wed, Aug 05, 2020 at 03:06:27PM +0200, Stefano Brivio wrote:
> On Wed, 5 Aug 2020 22:31:21 +1000
> Stephen Rothwell wrote:
>
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (s390 defconfig)
> > failed like this:
> >
> > net/ipv4/ip_tunnel_core.c:335:2: error:
On Mon, Aug 03, 2020 at 09:27:36PM +0200, Thomas Gleixner wrote:
> Heiko Carstens writes:
>
> > On Mon, Aug 03, 2020 at 06:05:24PM +0200, Thomas Gleixner wrote:
> >> +/**
> >> + * vdso_update_begin - Start of a VDSO update section
> >> + *
> >&g
On Mon, Aug 03, 2020 at 06:05:24PM +0200, Thomas Gleixner wrote:
> +/**
> + * vdso_update_begin - Start of a VDSO update section
> + *
> + * Allows architecture code to safely update the architecture specific VDSO
> + * data.
> + */
> +void vdso_update_begin(void)
> +{
> + struct vdso_data
ruct field renames
s390/zcrypt: split ioctl function into smaller code units
s390/ap: rename and clarify ap state machine related stuff
s390/zcrypt: provide cex4 cca sysfs attributes for cex3
s390/ap: rework crypto config info and default domain code
Heiko Carstens (11):
On Thu, Jul 30, 2020 at 09:35:15AM +0200, Ilya Leoshkevich wrote:
> On Thu, 2020-07-30 at 14:36 +0800, Wang Hai wrote:
> > test_unwind() misses to call kfree(bt) in an error path.
> > Add the missed function call to fix it.
> >
> > Fixes: 0610154650f1 ("s390/test_unwind: print verbose unwinding
>
On Wed, Jul 22, 2020 at 11:45:49AM +0200, David Hildenbrand wrote:
> This series is based on the latest s390/features branch [1]. It
> consolidates vmem_add_range(), vmem_remove_range(), and vmemmap_populate()
> into a single, recursive page table walker. It then implements
> vmemmap_free() and
Hello Linus,
please pull s390 updates for 5.8-rc7.
Thanks,
Heiko
The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7:
Linux 5.8-rc6 (2020-07-19 15:41:18 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git
1 - 100 of 1909 matches
Mail list logo
