On Sun, Feb 03, 2019 at 05:30:39PM +0100, Thomas Gleixner wrote:
> On Sat, 2 Feb 2019, Heiko Carstens wrote:
> > I added a barrier between those two and now the code looks like this:
> >
> > 140: a5 1b 00 01 oill%r1,1
> > 144: e3 10 a0 e0 00 24
On Sat, Feb 02, 2019 at 11:14:27AM +0100, Thomas Gleixner wrote:
> On Sat, 2 Feb 2019, Heiko Carstens wrote:
> So after the unlock @timestamp 337.215675 the kernel does not deal with
> that futex at all until the failed lock attempt where it rightfully rejects
> the attempt due to
On Thu, Jan 31, 2019 at 06:06:53PM +0100, Sebastian Sewior wrote:
> On 2019-01-31 17:52:28 [+0100], Heiko Carstens wrote:
> > ...nevertheless Stefan and I looked through the lovely disassembly of
> > _pthread_mutex_lock_full() to verify if the compiler barriers are
> >
On Fri, Feb 01, 2019 at 10:01:59AM +0100, Heiko Carstens wrote:
> On Thu, Jan 31, 2019 at 06:28:39PM -0500, Tony Krowiak wrote:
> > On 1/30/19 1:32 PM, Sebastian Ott wrote:
> > >On Wed, 30 Jan 2019, Tony Krowiak wrote:
> > >>+#if IS_ENABLED(CONFIG_ZCRYPT)
&
On Thu, Jan 31, 2019 at 06:28:39PM -0500, Tony Krowiak wrote:
> On 1/30/19 1:32 PM, Sebastian Ott wrote:
> >On Wed, 30 Jan 2019, Tony Krowiak wrote:
> >>+#if IS_ENABLED(CONFIG_ZCRYPT)
> >>+void ap_bus_cfg_chg(void);
> >>+#else
> >>+#error "no CONFIG_ZCRYPT"
> >^
> >I don't think that's the
On Thu, Jan 31, 2019 at 06:06:53PM +0100, Sebastian Sewior wrote:
> On 2019-01-31 17:52:28 [+0100], Heiko Carstens wrote:
> > ...nevertheless Stefan and I looked through the lovely disassembly of
> > _pthread_mutex_lock_full() to verify if the compiler barriers are
> >
On Thu, Jan 31, 2019 at 01:27:25AM +0100, Thomas Gleixner wrote:
> On Thu, 31 Jan 2019, Thomas Gleixner wrote:
>
> > On Wed, 30 Jan 2019, Paul E. McKenney wrote:
> > > On Thu, Jan 31, 2019 at 12:13:51AM +0100, Thomas Gleixner wrote:
> > > > I might be wrong as usual, but this would definitely
On Tue, Jan 29, 2019 at 08:25:58AM +0100, Laura Abbott wrote:
> On 1/23/19 5:24 AM, Heiko Carstens wrote:
> >On Wed, Jan 23, 2019 at 01:55:13PM +0100, Laura Abbott wrote:
> >>There's a build failure with gcc9:
...
> >Hmmm, this works only for the kernel image, but not
On Tue, Jan 29, 2019 at 02:03:01PM +0100, Thomas Gleixner wrote:
> On Tue, 29 Jan 2019, Peter Zijlstra wrote:
>
> > On Tue, Jan 29, 2019 at 11:24:09AM +0100, Heiko Carstens wrote:
> >
> > > Yes, sure. However ;) I reproduced the above with v5.0-rc4 + your
>
On Tue, Jan 29, 2019 at 10:45:44AM +0100, Thomas Gleixner wrote:
> On Tue, 29 Jan 2019, Heiko Carstens wrote:
> > On Mon, Jan 28, 2019 at 04:53:19PM +0100, Thomas Gleixner wrote:
> > > Patch below cures that.
> >
> > With your patch the kernel war
On Mon, Jan 28, 2019 at 04:53:19PM +0100, Thomas Gleixner wrote:
> On Mon, 28 Jan 2019, Peter Zijlstra wrote:
> > On Mon, Jan 28, 2019 at 02:44:10PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 29, 2018 at 12:23:21PM +0100, Heiko Carstens wrote:
> > >
> > > &
On Tue, Jan 22, 2019 at 04:21:02PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Martin Schwidefs
On Tue, Jan 22, 2019 at 04:21:00PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Martin Schwidefs
On Wed, Jan 23, 2019 at 01:55:13PM +0100, Laura Abbott wrote:
> There's a build failure with gcc9:
>
> ./arch/s390/include/asm/jump_label.h: Assembler messages:
> ./arch/s390/include/asm/jump_label.h:23: Error: bad expression
> ./arch/s390/include/asm/jump_label.h:23: Error: junk at end of
On Wed, Jan 23, 2019 at 01:33:15PM +0100, Thomas Gleixner wrote:
> Heiko,
>
> On Wed, 23 Jan 2019, Heiko Carstens wrote:
> > It doesn't look like it does. One occurrence was the one below when
> > using commit 7939f8beecf1 (which is post 5.0-rc2) for building the
> > ke
On Tue, Jan 22, 2019 at 05:33:37PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 22, 2019 at 05:24:54PM +0100, Heiko Carstens wrote:
> > On Tue, Jan 22, 2019 at 04:21:02PM +0100, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no need to ever check the
On Tue, Jan 22, 2019 at 10:14:00PM +0100, Thomas Gleixner wrote:
> On Mon, 21 Jan 2019, Thomas Gleixner wrote:
> > On Mon, 21 Jan 2019, Heiko Carstens wrote:
> >
> > > Hi Thomas,
> > >
> > > [full quote below]
> > >
> > > Did you have
On Tue, Jan 22, 2019 at 04:21:02PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Martin Schwidefs
Hi Thomas,
[full quote below]
Did you have any time to look into this yet? :)
The warning is still reproducible.
On Thu, Nov 29, 2018 at 12:23:21PM +0100, Heiko Carstens wrote:
> On Wed, Nov 28, 2018 at 03:32:45PM +0100, Thomas Gleixner wrote:
> > Heiko,
> >
> > On Tu
pass only counts elapsed time, not time since the epoch. They
> will be dealt with later.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/s390/kernel/syscalls/syscall.tbl | 20 +
For the s390 bits:
Acked-by: Heiko Carstens
> we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat
> mode. The resulting asm/unistd.h changes look a bit counterintuitive.
>
> This is only a cleanup patch and it should not change any behavior.
>
> Signed-off-by: Arnd Bergmann
...
> arch/s390/include/asm/unistd.h | 2 +-
For the s390 bits:
Acked-by: Heiko Carstens
/include/asm/unistd.h | 16
> arch/parisc/include/asm/unistd.h | 3 ---
> arch/s390/include/asm/unistd.h | 2 --
> arch/xtensa/include/asm/unistd.h | 12
> 4 files changed, 33 deletions(-)
For the s390 bits:
Acked-by: Heiko Carstens
ls/syscall.tbl | 3 +++
> arch/sh/kernel/syscalls/syscall.tbl | 4
> arch/sparc/include/asm/unistd.h | 5 -
> arch/sparc/kernel/syscalls/syscall.tbl | 4
> arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
> 12 files changed, 28 insertions(+), 15 deletions(-)
For the s390 bits:
Acked-by: Heiko Carstens
++
> arch/powerpc/kernel/syscalls/syscall.tbl | 13 +
> arch/s390/kernel/syscalls/syscall.tbl | 12
> arch/sh/kernel/syscalls/syscall.tbl | 11 +++
> arch/sparc/kernel/syscalls/syscall.tbl| 12
> arch/x86/entry/syscalls/syscall_32.tbl| 11 +++
> 7 files changed, 81 insertions(+)
For the s390 bits:
Acked-by: Heiko Carstens
patch below. If there
aren't any objections this should be added to Martin's 'compat' branch.
>From 71880dcdc62e2f89dc206a4e46c1c60e59ce3b0d Mon Sep 17 00:00:00 2001
From: Heiko Carstens
Date: Mon, 21 Jan 2019 10:30:44 +0100
Subject: [PATCH] s390: fix system call tracing
When converting t
25 +++--
> 3 files changed, 15 insertions(+), 18 deletions(-)
Tested and still seems to work like before.
Acked-by: Heiko Carstens
Please remove this hunk, since the code _should_ be able to handle
allocation failures anyway (see end of quoted code).
Otherwise for the s390 bits:
Acked-by: Heiko Carstens
On Thu, Jan 17, 2019 at 05:21:50PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 17, 2019 at 2:36 PM Heiko Carstens
> wrote:
> >
> > On Wed, Jan 16, 2019 at 02:15:18PM +0100, Arnd Bergmann wrote:
>
> > > I did not test the changes at runtime, but I looked at the
>
On Thu, Jan 17, 2019 at 05:29:55PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 17, 2019 at 2:29 PM Heiko Carstens
> > SYSCALL_DEFINE1(s390_personality, unsigned int, personality)
> > {
> > diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> > index ab9d0e3c6d50..ad016a7db
On Thu, Jan 17, 2019 at 10:51:02AM +0100, Ingo Molnar wrote:
>
> * Heiko Carstens wrote:
>
> > > - if (timr->it_requeue_pending == info->si_sys_private) {
> > > + if (timr->it_interval && timr->it_requeue_pending ==
> > > info->si_sy
On Wed, Jan 16, 2019 at 02:15:18PM +0100, Arnd Bergmann wrote:
> Hi Heiko and Martin,
>
> As promised, I gave this a go and changed the SYSCALL_DEFINEx()
> infrastructure to always include the wrappers for doing the
> 31-bit argument conversion on s390 compat mode.
>
> This does three main
On Wed, Jan 16, 2019 at 02:15:22PM +0100, Arnd Bergmann wrote:
> Any system call that takes a pointer argument on s390 requires
> a wrapper function to do a 31-to-64 zero-extension, these are
> currently generated in arch/s390/kernel/compat_wrapper.c.
>
> On arm64 and x86, we already generate
On Wed, Jan 16, 2019 at 02:15:20PM +0100, Arnd Bergmann wrote:
> The sys_ipc() and compat_ksys_ipc() functions are meant to only
> be used from the system call table, not called by another function.
>
> Introduce ksys_*() interfaces for this purpose, as we have done
> for many other system calls.
On Wed, Jan 16, 2019 at 02:15:18PM +0100, Arnd Bergmann wrote:
> Hi Heiko and Martin,
>
> As promised, I gave this a go and changed the SYSCALL_DEFINEx()
> infrastructure to always include the wrappers for doing the
> 31-bit argument conversion on s390 compat mode.
>
> This does three main
On Fri, Jan 11, 2019 at 06:30:43PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 9:36 PM Heiko Carstens
> wrote:
> > On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
>
> > Since you only need/want the system call numbers, could you please
&
On Thu, Jan 10, 2019 at 06:22:12PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/s390/kernel/syscalls/syscall.tbl
> b/arch/s390/kernel/syscalls/syscall.tbl
> index f84ea364a302..b3199a744731 100644
> --- a/arch/s390/kernel/syscalls/syscall.tbl
> +++ b/arch/s390/kernel/syscalls/syscall.tbl
> @@
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for
On Thu, Jan 10, 2019 at 05:24:34PM +0100, Arnd Bergmann wrote:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both. We also
> have some architectures that require passing IPC_64 in the flags, and
> others that
On Wed, Jan 09, 2019 at 11:35:41AM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct
Deepa Dinamani
> ---
> arch/s390/include/uapi/asm/Kbuild | 1 +
> arch/s390/include/uapi/asm/socket.h | 117
For the s390 bits:
Acked-by: Heiko Carstens
On Mon, Jan 07, 2019 at 08:19:26PM +0100, Michael Mueller wrote:
>
> On 03.01.19 15:43, Pierre Morel wrote:
> >On 19/12/2018 20:17, Michael Mueller wrote:
> >>This function processes the Gib Alert List (GAL). It is required
> >>to run when either a gib alert interruption has been received or
>
On Thu, Jan 03, 2019 at 11:52:51PM +, Martin Lau wrote:
> On Thu, Jan 03, 2019 at 11:41:18PM +0100, Heiko Carstens wrote:
> > On Thu, Jan 03, 2019 at 07:12:05PM +, Martin Lau wrote:
> > > On Thu, Jan 03, 2019 at 12:46:13PM +0100, Heiko Carstens wr
On Thu, Jan 03, 2019 at 07:12:05PM +, Martin Lau wrote:
> On Thu, Jan 03, 2019 at 12:46:13PM +0100, Heiko Carstens wrote:
> > Hello,
> >
> > the kernel commit 7337224fc150 ("bpf: Improve the info.func_info and
> > info.func_info_rec_size behavior&quo
Hello,
the kernel commit 7337224fc150 ("bpf: Improve the info.func_info and
info.func_info_rec_size behavior") breaks one of strace's self tests:
FAIL: bpf-obj_get_info_by_fd-prog-v.gen
Looking into the kernel commit, it seems that the user space visible
uapi change is intentional; even though
| 7 ++-
> scripts/Kbuild.include | 8
> scripts/kconfig/Makefile | 4 +---
> 6 files changed, 12 insertions(+), 26 deletions(-)
For the s390 bits:
Acked-by: Heiko Carstens
On Fri, Dec 21, 2018 at 01:34:53PM +0100, Ingo Molnar wrote:
> Linus,
>
> Please pull the latest timers-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> timers-urgent-for-linus
>
># HEAD: 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94
On Mon, Dec 17, 2018 at 11:05:06PM +0100, Arnd Bergmann wrote:
> On Mon, Dec 17, 2018 at 10:40 PM Arnd Bergmann wrote:
> >
> > On Mon, Dec 17, 2018 at 2:06 PM Heiko Carstens
> > wrote:
> > >
> > > Hi Arnd,
> > >
> > > in linux-ne
On Mon, Dec 17, 2018 at 05:39:49PM +0100, Michal Hocko wrote:
> On Mon 17-12-18 17:03:50, Michal Hocko wrote:
> > On Mon 17-12-18 16:59:22, Heiko Carstens wrote:
> > > Hi Michal,
> > >
> > > with linux-next as of today on s390 I see tons of messages like
>
Hi Michal,
with linux-next as of today on s390 I see tons of messages like
[ 20.536664] page dumped because: has_unmovable_pages
[ 20.536792] page:03d081ff4080 count:1 mapcount:0
mapping:8ff88600 index:0x0 compound_mapcount: 0
[ 20.536794] flags: 0x3fffe010200(slab|head)
[
Hi Arnd,
in linux-next as of today 16 strace self tests fail on s390. I could
bisect this to b136972b063b ("y2038: socket: Add compat_sys_recvmmsg_time64").
The following tests fail:
mmsg.gen.test
clock.gen.test
regex.gen.test
sched.gen.test
trace_fstatfs.gen.test
On Thu, Dec 13, 2018 at 04:50:06PM -0800, Kees Cook wrote:
> On Thu, Dec 13, 2018 at 12:10 PM Tycho Andersen wrote:
> >
> > A recent patch landed in the security tree [1] that changed the type of the
> > seccomp syscall. Unfortunately, I didn't quite get every instance of the
> > forward
On Wed, Nov 28, 2018 at 03:32:45PM +0100, Thomas Gleixner wrote:
> Heiko,
>
> On Tue, 27 Nov 2018, Heiko Carstens wrote:
>
> > with the glibc self-tests I was able to trigger the "this should not
> > happen" warning ;) below on s390 (with panic_on_warn=1 se
On Wed, Nov 28, 2018 at 03:32:45PM +0100, Thomas Gleixner wrote:
> Heiko,
>
> On Tue, 27 Nov 2018, Heiko Carstens wrote:
>
> > with the glibc self-tests I was able to trigger the "this should not
> > happen" warning ;) below on s390 (with panic_on_warn=1 se
On Tue, Nov 27, 2018 at 02:19:16PM +0100, Michal Hocko wrote:
> On Tue 27-11-18 09:36:03, Heiko Carstens wrote:
> > Use pr_alert_once() instead of pr_alert() if page table misaccounting
> > has been detected.
> >
> > If this happens once it is very likely that there
On Tue, Nov 27, 2018 at 02:19:16PM +0100, Michal Hocko wrote:
> On Tue 27-11-18 09:36:03, Heiko Carstens wrote:
> > Use pr_alert_once() instead of pr_alert() if page table misaccounting
> > has been detected.
> >
> > If this happens once it is very likely that there
On Tue, Nov 27, 2018 at 03:47:13AM -0800, Guenter Roeck wrote:
> >E.g. something like the below. If there aren't any objections, I will
> >provide a proper patch with changelog, etc.
> >
> >diff --git a/kernel/fork.c b/kernel/fork.c
> >index 07cddff89c7b..d7aeec03c57f 100644
> >--- a/kernel/fork.c
On Tue, Nov 27, 2018 at 03:47:13AM -0800, Guenter Roeck wrote:
> >E.g. something like the below. If there aren't any objections, I will
> >provide a proper patch with changelog, etc.
> >
> >diff --git a/kernel/fork.c b/kernel/fork.c
> >index 07cddff89c7b..d7aeec03c57f 100644
> >--- a/kernel/fork.c
.
Cc: Kirill A. Shutemov
Cc: Martin Schwidefsky
Signed-off-by: Heiko Carstens
---
kernel/fork.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff89c7b..c887e9eba89f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -647,8 +647,8
.
Cc: Kirill A. Shutemov
Cc: Martin Schwidefsky
Signed-off-by: Heiko Carstens
---
kernel/fork.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff89c7b..c887e9eba89f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -647,8 +647,8
On Tue, Nov 27, 2018 at 11:05:15AM +0300, Kirill A. Shutemov wrote:
> > E.g. something like the below. If there aren't any objections, I will
> > provide a proper patch with changelog, etc.
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 07cddff89c7b..d7aeec03c57f 100644
> > ---
On Tue, Nov 27, 2018 at 11:05:15AM +0300, Kirill A. Shutemov wrote:
> > E.g. something like the below. If there aren't any objections, I will
> > provide a proper patch with changelog, etc.
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 07cddff89c7b..d7aeec03c57f 100644
> > ---
Hello,
with the glibc self-tests I was able to trigger the "this should not
happen" warning ;) below on s390 (with panic_on_warn=1 set). It looks
like it is hardly reproducible.
This one happened with commit d146194f31c9 for compiling the kernel.
Config can be re-created with "make ARCH=s390
Hello,
with the glibc self-tests I was able to trigger the "this should not
happen" warning ;) below on s390 (with panic_on_warn=1 set). It looks
like it is hardly reproducible.
This one happened with commit d146194f31c9 for compiling the kernel.
Config can be re-created with "make ARCH=s390
On Wed, Oct 31, 2018 at 01:36:23PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 31, 2018 at 11:09:44AM +0100, Heiko Carstens wrote:
> > On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
> > > Thanks for testing. Unfortunately Heiko reported anoth
On Wed, Oct 31, 2018 at 01:36:23PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 31, 2018 at 11:09:44AM +0100, Heiko Carstens wrote:
> > On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
> > > Thanks for testing. Unfortunately Heiko reported anoth
On Fri, Nov 23, 2018 at 11:17:48AM +0900, Sergey Senozhatsky wrote:
> On (11/22/18 15:15), Petr Mladek wrote:
> > The commit cefc8be82403cf ("Consolidate bust_spinlocks()") kept
> > the s390-specific implementation because of the absence of CONFIG_VT.
> > In fact, the only difference was calling
On Fri, Nov 23, 2018 at 11:17:48AM +0900, Sergey Senozhatsky wrote:
> On (11/22/18 15:15), Petr Mladek wrote:
> > The commit cefc8be82403cf ("Consolidate bust_spinlocks()") kept
> > the s390-specific implementation because of the absence of CONFIG_VT.
> > In fact, the only difference was calling
On Sun, Nov 04, 2018 at 01:28:06PM -0800, Guenter Roeck wrote:
> __node_distance is used by nvme, resulting in:
>
> ERROR: "__node_distance" [drivers/nvme/host/nvme-core.ko] undefined!
>
> when trying to build nvme as module.
>
> Fixes: f333444708f8 ("nvme: take node locality into account when
On Sun, Nov 04, 2018 at 01:28:06PM -0800, Guenter Roeck wrote:
> __node_distance is used by nvme, resulting in:
>
> ERROR: "__node_distance" [drivers/nvme/host/nvme-core.ko] undefined!
>
> when trying to build nvme as module.
>
> Fixes: f333444708f8 ("nvme: take node locality into account when
On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
> Thanks for testing. Unfortunately Heiko reported another issue yesterday
> with the patch applied. This time the other way around:
>
> BUG: non-zero pgtables_bytes on freeing mm: -16384
>
> I am trying to understand how this
On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
> Thanks for testing. Unfortunately Heiko reported another issue yesterday
> with the patch applied. This time the other way around:
>
> BUG: non-zero pgtables_bytes on freeing mm: -16384
>
> I am trying to understand how this
On Thu, Oct 25, 2018 at 04:05:43PM +0900, Sergey Senozhatsky wrote:
> On (10/25/18 08:28), Heiko Carstens wrote:
> >
> > With your patch this looks nearly like the common code variant. I did
> > some code archaeology and this function is unchanged since ~17 years.
>
On Thu, Oct 25, 2018 at 04:05:43PM +0900, Sergey Senozhatsky wrote:
> On (10/25/18 08:28), Heiko Carstens wrote:
> >
> > With your patch this looks nearly like the common code variant. I did
> > some code archaeology and this function is unchanged since ~17 years.
>
On Wed, Oct 24, 2018 at 01:34:25PM +0900, Sergey Senozhatsky wrote:
> On (10/24/18 13:30), Sergey Senozhatsky wrote:
> From: Sergey Senozhatsky
> Subject: [PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks()
...
> From the comment it seems that s390 wants to just poke klogd.
> There is
On Wed, Oct 24, 2018 at 01:34:25PM +0900, Sergey Senozhatsky wrote:
> On (10/24/18 13:30), Sergey Senozhatsky wrote:
> From: Sergey Senozhatsky
> Subject: [PATCH] s390/fault: use wake_up_klogd() in bust_spinlocks()
...
> From the comment it seems that s390 wants to just poke klogd.
> There is
On Tue, Oct 16, 2018 at 02:29:28PM +0800, Pingfan Liu wrote:
> > I think it is caused by the uinon page->lru and page->next. It can be fixed
> > by:
> > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> > index 3a1a1db..4aa0fb5 100644
> > --- a/include/linux/slub_def.h
> > +++
On Tue, Oct 16, 2018 at 02:29:28PM +0800, Pingfan Liu wrote:
> > I think it is caused by the uinon page->lru and page->next. It can be fixed
> > by:
> > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> > index 3a1a1db..4aa0fb5 100644
> > --- a/include/linux/slub_def.h
> > +++
Hello,
with linux-next for 20181008 I can reliably crash my system with lot's of
debugging options enabled on s390. List debugging triggers the list
corruption below, which I could bisect down to this commit:
fde06e07750477f049f12d7d471ffa505338a3e7 is the first bad commit
commit
Hello,
with linux-next for 20181008 I can reliably crash my system with lot's of
debugging options enabled on s390. List debugging triggers the list
corruption below, which I could bisect down to this commit:
fde06e07750477f049f12d7d471ffa505338a3e7 is the first bad commit
commit
On Sat, Oct 06, 2018 at 11:08:23AM -0500, Wenwen Wang wrote:
> In qeth_snmp_command(), the length of the user request is firstly copied
> from the user-space buffer 'udata' to the kernel variable 'req_len' and
> checked to see whether it is too large. If the check fails, an error code
> EINVAL is
On Sat, Oct 06, 2018 at 11:08:23AM -0500, Wenwen Wang wrote:
> In qeth_snmp_command(), the length of the user request is firstly copied
> from the user-space buffer 'udata' to the kernel variable 'req_len' and
> checked to see whether it is too large. If the check fails, an error code
> EINVAL is
n
> the s390 linker script. Let's fix that.
>
> Fixes: e872267b8bcbb179 ("jump_table: move entries into ro_after_init region")
> Reported-by: Guenter Roeck
> Cc: Heiko Carstens
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Martin Schwidefs
n
> the s390 linker script. Let's fix that.
>
> Fixes: e872267b8bcbb179 ("jump_table: move entries into ro_after_init region")
> Reported-by: Guenter Roeck
> Cc: Heiko Carstens
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Martin Schwidefs
On Thu, Sep 27, 2018 at 11:08:14PM -0300, Leonardo Brás wrote:
> Avoids building s390 drivers if 'make drivers/s390/' is called but
> ARCH is not s390.
>
> Signed-off-by: Leonardo Brás
> ---
> drivers/s390/Makefile | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git
On Thu, Sep 27, 2018 at 11:08:14PM -0300, Leonardo Brás wrote:
> Avoids building s390 drivers if 'make drivers/s390/' is called but
> ARCH is not s390.
>
> Signed-off-by: Leonardo Brás
> ---
> drivers/s390/Makefile | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git
Commit-ID: 13ddb52c165ba47d153b7b040931a5cbe9220866
Gitweb: https://git.kernel.org/tip/13ddb52c165ba47d153b7b040931a5cbe9220866
Author: Heiko Carstens
AuthorDate: Tue, 18 Sep 2018 23:51:44 -0700
Committer: Thomas Gleixner
CommitDate: Thu, 27 Sep 2018 17:56:49 +0200
s390/jump_label
Commit-ID: 13ddb52c165ba47d153b7b040931a5cbe9220866
Gitweb: https://git.kernel.org/tip/13ddb52c165ba47d153b7b040931a5cbe9220866
Author: Heiko Carstens
AuthorDate: Tue, 18 Sep 2018 23:51:44 -0700
Committer: Thomas Gleixner
CommitDate: Thu, 27 Sep 2018 17:56:49 +0200
s390/jump_label
On Thu, Sep 06, 2018 at 02:16:27PM +0800, Ding Xiang wrote:
> device_unregister will put device, do not need to do it one more time
>
> Signed-off-by: Ding Xiang
> ---
> drivers/s390/scsi/zfcp_unit.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/s390/scsi/zfcp_unit.c
On Thu, Sep 06, 2018 at 02:16:27PM +0800, Ding Xiang wrote:
> device_unregister will put device, do not need to do it one more time
>
> Signed-off-by: Ding Xiang
> ---
> drivers/s390/scsi/zfcp_unit.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/s390/scsi/zfcp_unit.c
s390/zcrypt: add copy_from_user length plausibility checks
Heiko Carstens (1):
s390/sysinfo: add missing #ifdef CONFIG_PROC_FS
Hendrik Brueckner (1):
s390/cpum_sf: save TOD clock base in SDBs for time conversion
Janosch Frank (11):
s390/mm: Make gmap_protect_range more m
s390/zcrypt: add copy_from_user length plausibility checks
Heiko Carstens (1):
s390/sysinfo: add missing #ifdef CONFIG_PROC_FS
Hendrik Brueckner (1):
s390/cpum_sf: save TOD clock base in SDBs for time conversion
Janosch Frank (11):
s390/mm: Make gmap_protect_range more m
On Thu, Aug 09, 2018 at 11:18:05AM -0400, Tony Krowiak wrote:
> On 08/09/2018 05:06 AM, Cornelia Huck wrote:
> >On Wed, 8 Aug 2018 10:44:14 -0400
> >Tony Krowiak wrote:
> >
> >>From: Harald Freudenberger
> >>
> >>Move all the inline functions from the ap bus header
> >>file ap_asm.h into the
On Thu, Aug 09, 2018 at 11:18:05AM -0400, Tony Krowiak wrote:
> On 08/09/2018 05:06 AM, Cornelia Huck wrote:
> >On Wed, 8 Aug 2018 10:44:14 -0400
> >Tony Krowiak wrote:
> >
> >>From: Harald Freudenberger
> >>
> >>Move all the inline functions from the ap bus header
> >>file ap_asm.h into the
me this change makes quite some difference.
Reviewed-by: Heiko Carstens
me this change makes quite some difference.
Reviewed-by: Heiko Carstens
So this is required for s390 as well.
>From 77d87236f3d5474f33c25534d8ba2c7c54c88c55 Mon Sep 17 00:00:00 2001
From: Heiko Carstens
Date: Wed, 4 Jul 2018 09:13:37 +0200
Subject: [PATCH] s390/jump_label: switch to relative references
Signed-off-by: Heiko Carstens
---
arch/s390/Kconfig
So this is required for s390 as well.
>From 77d87236f3d5474f33c25534d8ba2c7c54c88c55 Mon Sep 17 00:00:00 2001
From: Heiko Carstens
Date: Wed, 4 Jul 2018 09:13:37 +0200
Subject: [PATCH] s390/jump_label: switch to relative references
Signed-off-by: Heiko Carstens
---
arch/s390/Kconfig
On Tue, Jul 03, 2018 at 10:55:46AM +0200, Heiko Carstens wrote:
> > > > We're piece-wise enabling rseq across architectures anyway, and when the
> > > > relevant maintains do this, they can have a look at their
> > > > {get,put}_user() implementations and fi
On Tue, Jul 03, 2018 at 10:55:46AM +0200, Heiko Carstens wrote:
> > > > We're piece-wise enabling rseq across architectures anyway, and when the
> > > > relevant maintains do this, they can have a look at their
> > > > {get,put}_user() implementations and fi
> > > We're piece-wise enabling rseq across architectures anyway, and when the
> > > relevant maintains do this, they can have a look at their
> > > {get,put}_user() implementations and fix them.
> > >
> > > If you rely on get_user(u64) working, that means microblaze is already
> > > broken, but
201 - 300 of 1909 matches
Mail list logo
