On Tue, Apr 05, 2016 at 01:57:42PM +0200, Sebastian Andrzej Siewior wrote:
> On 04/05/2016 01:51 PM, rcoch...@linutronix.de wrote:
> > On Tue, Apr 05, 2016 at 01:36:38PM +0200, Heiko Carstens wrote:
> >> On Tue, Apr 05, 2016 at 01:23:36PM +0200, Heiko Carstens wrote:
> >
there is nothing.
>
> This regression got probably introduce in the rework while we introduced
> the hotplug thread to offload the work to the target CPU.
>
> Fixes: 4cb28ced23c4 ("cpu/hotplug: Create hotplug threads")
> Reported-by: Heiko Carstens
> Signed-off-
o the module.c changes look?
>
> Plus there are (admittedly indeed rather small and trivial) changes to
> s390 module loader, so I'd prefer to have Heiko's / Martin's Ack before
> merging this.
>
> Hence, let me piggy back on this ping to Rusty, and let me ping Heiko and
> Martin as well (adding to CC explicitly to make sure this doesn't get lost
> in general noise).
For the s390 changes:
Acked-by: Heiko Carstens
Jessica, thanks for also writing the documentation!
On Fri, Apr 01, 2016 at 01:35:16PM +0100, Sudip Mukherjee wrote:
> s390 defconfig and allmodconfig fails with the error:
> kernel/seccomp.c: In function '__secure_computing_strict':
> kernel/seccomp.c:526:3: error: implicit declaration of function
> 'get_compat_mode1_s
On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
> >Hi all,
> >
> >Changes since 20160401:
>
> s390 allmodconfig build fails with the error:
>
> arch/s390/crypto/ghash_s390.c:14:24: fatal error: crypt_s390.h: No
> such fi
On Tue, Apr 12, 2016 at 06:34:08PM +0200, Martin Schwidefsky wrote:
> On Mon, 4 Apr 2016 16:26:35 +0200
> Heiko Carstens wrote:
>
> > On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> > > On Monday 04 April 2016 09:39 AM, Stephen Rothw
tion which works the same
like CFLAGS_REMOVE.
Signed-off-by: Heiko Carstens
---
scripts/Makefile.lib | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 79e86613712f..26a48d76eb9d 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Ma
Hi Michal,
these are just two simple patches which add
1) an AFLAGS_REMOVE option which works just like CFLAGS_REMOVE and
2) one user of it in s390 code.
If you agree this is ok, then these two patches could go upstream either
via your tree or the s390 tree.
Thanks,
Heiko
Heiko Carstens (2
instructions which are availanble with the
earliest machine generation (z900). In order to make sure we don't
accidently add instructions which are not available on z900, always compile
with -march=z900. This makes sure compilation will fail if wrong
instructions are used.
Signed-off-by: Heiko Car
: Kees Cook
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Benjamin Herrenschmidt
> Cc: Martin Schwidefsky
> Cc: Heiko Carstens
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Andrew Morton
> Cc: Greg Kroah-Har
smp_store_mb() users really are about SMP ordering, not IO
> ordering, change them all to be consistent.
>
> Cc: Tony Luck
> Cc: Benjamin Herrenschmidt
> Cc: Heiko Carstens
> Suggested-by: Linus Torvalds
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> diff --git a/arc
On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me
> > know.
> >
> > ------
> >
> >
On Tue, Sep 15, 2015 at 09:41:49AM +0200, Willy Tarreau wrote:
> On Tue, Sep 15, 2015 at 08:09:27AM +0200, Heiko Carstens wrote:
> > On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote:
> > > On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > > >
On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > i just enable it on ARM64,
> > and it can work,
> > i don’t see some special requirement to enable this config .
>
> Right, so why does HAVE_LATENCYTOP_SUPPORT exist?
If
On Tue, Nov 10, 2015 at 10:05:48AM +, Will Deacon wrote:
> Hi Heiko,
>
> On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote:
> > On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> > > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
ch/powerpc/Kconfig| 3 ---
> arch/s390/Kconfig | 3 ---
> arch/sh/Kconfig | 3 ---
> arch/sparc/Kconfig | 4
> arch/unicore32/Kconfig | 3 ---
> arch/x86/Kconfig | 3 ---
> lib/Kconfig.debug | 1 -
> 12 files changed, 37 deletions(-)
Acke
On Mon, Nov 16, 2015 at 03:15:17PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 16 Nov 2015 14:45:40 +0100
>
> The debug_unregister() function performs also input parameter validation.
> Thus the test around the calls is not needed.
>
> This issue was detected by using the
On Wed, Mar 20, 2019 at 12:12:36AM +0800, Jeff Xie wrote:
> It is unnecessary to call spin_lock_bh in a tasklet.
>
> Signed-off-by: Jeff Xie
> ---
> drivers/s390/char/tty3270.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/s390/char/tty3270.c b/drivers/s39
On Tue, Sep 10, 2019 at 09:02:15AM -0400, Igor Mammedov wrote:
> Make sure that ms->dirty_bitmap is set before using it or
> print a warning and return -ENIVAL otherwise.
...
> v2:
>- drop WARN()
...
> + if (!ms->dirty_bitmap)
> + return -EINVAL;
The patch descr
On Thu, Sep 12, 2019 at 02:23:54PM +0900, Masahiro Yamada wrote:
> This is unused.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/s390/Makefile | 3 ---
> 1 file changed, 3 deletions(-)
Applied, thanks.
On Wed, Oct 02, 2019 at 09:03:33AM +0200, Michal Kubecek wrote:
> On Wed, Oct 02, 2019 at 08:46:05AM +0200, Heiko Carstens wrote:
> > On Tue, Oct 01, 2019 at 10:08:01PM +0200, Jiri Kosina wrote:
> > >
> > >In file included from arch/s390/kvm/kvm-s390.c:44:
>
uot; kernel cmdline, and I suspect nobody tested that on s390 in
> the
> past.
Yes. Peter Oberparleiter reported this also before my short vacation,
but I didn't have time to look into this. Thanks for fixing!
Reviewed-by: Heiko Carstens
On Tue, Oct 01, 2019 at 10:08:01PM +0200, Jiri Kosina wrote:
> arch/s390/kvm/kvm-s390.c calls on several places __cpacf_query() directly,
> which makes it impossible to meet the "i" constraint for the asm operands
> (opcode in this case).
>
> As we are now force-enabling CONFIG_OPTIMIZE_INLINING
On Wed, Oct 02, 2019 at 08:46:05AM +0200, Heiko Carstens wrote:
> On Tue, Oct 01, 2019 at 10:08:01PM +0200, Jiri Kosina wrote:
> > I am wondering how is it possible that none of the build-testing
> > infrastructure we have running against linux-next caught this? Not enough
>
On Mon, Oct 21, 2019 at 06:11:35PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 21, 2019 at 05:34:25PM +0200, Peter Zijlstra wrote:
> > On Mon, Oct 21, 2019 at 04:14:02PM +0200, Peter Zijlstra wrote:
>
> > So On IRC Josh suggested we use text_poke() for RELA. Since KLP is only
> > available on Power
On Tue, Oct 15, 2019 at 03:15:22PM -0400, James Bottomley wrote:
> Five changes, two in drivers (qla2xxx, zfcp), one to MAINTAINERS
> (qla2xxx) and two in the core. The last two are mostly about removing
> incorrect messages from the kernel log: the resid message is definitely
> wrong and the sync
ix race on airq_areas[]
Heiko Carstens (2):
Merge tag 'vfio-ccw-20190717-2' of
https://git.kernel.org/.../kvms390/vfio-ccw into fixes
kbuild: enable arch/s390/include/uapi/asm/zcrypt.h for uapi header test
Julian Wiedmann (2):
s390/qdio: add sanity checks to the fast-req
On Sat, Feb 09, 2019 at 12:34:20PM -0800, Laura Abbott wrote:
> On 2/5/19 12:43 PM, Heiko Carstens wrote:
> >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, Lau
On Fri, Feb 08, 2019 at 08:11:10AM +0530, Allen wrote:
> From: Allen Pais
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Allen Pais
> ---
> arch/s390/tools/gen_opcode_table.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/tools/
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 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 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 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
> &g
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 line
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 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 warning doesn'
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 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
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 things
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: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 simi
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 things
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 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 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 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
>
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
chkbss | 25 +++--
> 3 files changed, 15 insertions(+), 18 deletions(-)
Tested and still seems to work like before.
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
Whe
+++
> 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
nel/syscalls/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
/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
> 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
they
> 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
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
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 righ
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: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
> > actuall
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 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 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 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 Prarit,
On Tue, May 07, 2019 at 10:54:13AM -0400, Prarit Bhargava wrote:
> Heiko, it would still be good to get a test of this patch from you. I
> tested this here at Red Hat on some System Z machines. Without the
> modification made here in v2, the systems failed to boot ~10% of the time.
>
Hello Petr,
I just realized that early printks, or more specific vsnprintf invocations,
are broken on s390 due to
3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers").
E.g. the early boot output now looks like this where the first
(efault) should be the linux_banner:
[
We are devastated by the tragic death of Martin Schwidefsky who died
in an accident last Saturday.
Martin was the most significant contributor to the initial s390 port
of the Linux Kernel and later the maintainer of the s390 architecture
backend. His technical expertise as well as his mentoring sk
On Mon, May 13, 2019 at 03:16:11AM -0400, Jan Stancek wrote:
> - Original Message -
> > We have noticed 274 syscall test failures on x86_64 and i386 due to
> > Make the temporary directory in one shot using mkdtemp failed.
> > tst_tmpdir.c:264: BROK: tst_tmpdir:
> > mkdtemp(/scratch/ltp-7D8
Hello Prarit,
it looks like your commit f9a75c1d717f ("modules: Only return -EEXIST
for modules that have finished loading") _sometimes_ causes hangs on
s390. This is unfortunately not 100% reproducible, however the
mentioned commit seems to be the only relevant one in modules.c.
What I see is a
On Fri, Apr 26, 2019 at 09:22:34AM -0400, Prarit Bhargava wrote:
> On 4/26/19 9:07 AM, Heiko Carstens wrote:
> > Hello Prarit,
> >
> > it looks like your commit f9a75c1d717f ("modules: Only return -EEXIST
> > for modules that have finished loading") _sometim
On Fri, Apr 26, 2019 at 08:20:52PM -0400, Prarit Bhargava wrote:
> Heiko and Jessica,
>
> The issue doesn't appear to be with my patch AFAICT. The s390_trng fails to
> load and then the kernel occasionally hangs (as Heiko mentioned) calling
> synchronize_rcu().
>
> The call sequence is
>
> modu
On Sat, Apr 27, 2019 at 06:42:51AM -0400, Prarit Bhargava wrote:
> On 4/27/19 6:24 AM, Heiko Carstens wrote:
>
> >
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 410eeb7e4f1d..48748cfec991 100644
> > --- a/kernel/module.c
> > +++ b/kernel/modu
On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> Hi Linus,
>
> Third rc pull request
>
> Nothing particularly special here. There is a small merge conflict
> with Adrea's mm_still_valid patches which is resolved as below:
...
> Jason Gunthorpe (3):
> RDMA/mlx5: Do not allo
ne with the Reported-by tag. Thank you!
> >8<
> >
> >On a s390 z14 LAR with 2 cpus about stalls about 3% of the time while
> >loading the s390_trng.ko module.
> >
> >Add a reschedule point to the loop that waits for modules to complete
> >lo
> 1 file changed, 3 deletions(-)
Acked-by: Heiko Carstens
On Mon, Apr 15, 2019 at 10:35:51AM +0200, Arnd Bergmann wrote:
> llvm does does not understand -march=z9-109 and older target
> specifiers, so disable the respective Kconfig settings and
> the logic to make the boot code work on old systems when
> building with clang.
>
> Part of the early boot co
On Mon, Apr 15, 2019 at 09:12:06AM -0700, Nathan Chancellor wrote:
> On Mon, Apr 15, 2019 at 10:35:52AM +0200, Arnd Bergmann wrote:
> > The purgatory and boot Makefiles do not inherit the original cflags,
> > so clang falls back to the default target architecture when building it,
> > typically thi
On Mon, Apr 15, 2019 at 10:35:53AM +0200, Arnd Bergmann wrote:
> VIRT_TO_BUS is only used for legacy device PCI and ISA drivers using
> virt_to_bus() instead of the streaming DMA mapping API, and the
> remaining drivers generally don't work on 64-bit architectures.
>
> Two of these drivers also ca
On Tue, Apr 30, 2019 at 01:25:09PM -0700, Nick Desaulniers wrote:
> On Tue, Apr 23, 2019 at 2:01 PM Nick Desaulniers
> wrote:
> >
> > Towards the goal of removing cc-ldoption, it seems that --hash-style=
> > was added to binutils 2.17.50.0.2 in 2006. The minimal required version
> > of binutils fo
On Mon, Apr 15, 2019 at 10:35:54AM +0200, Arnd Bergmann wrote:
> The arch/s390/boot directory is built with its own set of compiler
> options that does not include -Wno-pointer-sign like the rest of
> the kernel does, this causes a lot of harmess but correct warnings
> when building with clang.
>
On Thu, Aug 08, 2019 at 06:17:39PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190807:
>
> I reverted a commit from the kbuild-current tree by request.
Hello Masahiro,
it looks like there is (another?) bug in kbuild. With your patch
commit 421a15c167b2d1f43f287da5b75ef27046506
gt; check, the caller does not have to keep track of whether this was
> called through .unlocked_ioctl() or .compat_ioctl().
>
> Signed-off-by: Arnd Bergmann
Besides the two minor things below
Acked-by: Heiko Carstens
> diff --git a/include/linux/mtio.h b/include/linux/mtio.h
&
On Wed, Jul 31, 2019 at 09:08:17PM +1000, Herbert Xu wrote:
> On Wed, Jul 31, 2019 at 10:58:20AM +0200, Heiko Carstens wrote:
> > On Wed, Jul 31, 2019 at 04:39:15PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20190730:
> >
>
On Wed, Jul 31, 2019 at 09:32:16PM +1000, Herbert Xu wrote:
> On Wed, Jul 31, 2019 at 01:15:20PM +0200, Heiko Carstens wrote:
> >
> > However that doesn't fix the simd.h header file breakage with the
> > second patch :)
>
> That fix should be there now too.
Yes, works now. Thank you!
On Wed, Jul 31, 2019 at 01:44:54PM +0200, Heiko Carstens wrote:
> On Wed, Jul 31, 2019 at 09:32:16PM +1000, Herbert Xu wrote:
> > On Wed, Jul 31, 2019 at 01:15:20PM +0200, Heiko Carstens wrote:
> > >
> > > However that doesn't fix the simd.h header file brea
On Thu, Aug 01, 2019 at 08:28:56PM +0300, Ard Biesheuvel wrote:
> On Thu, 1 Aug 2019 at 15:28, Heiko Carstens wrote:
> > Still not... with linux-next as of today I get this (s390 defconfig):
> >
> > ERROR: "crypto_aegis128_decrypt_chunk_simd" [crypto/ae
On Fri, Aug 02, 2019 at 02:48:44PM +1000, Stephen Rothwell wrote:
> Hi Herbert,
>
> On Fri, 2 Aug 2019 13:14:14 +1000 Herbert Xu
> wrote:
> >
> > For now I'm going to back out those two specific patches as the
> > rest seem to be valid by themselves.
>
> I have applied the top commit from your
On Wed, Jul 31, 2019 at 04:39:15PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190730:
Hello Ard,
two of your patches in the crypto tree cause build breakage on s390:
The patch ("crypto: aes - create AES library based on the fixed time AES code")
causes this:
arch/s390/crypto/
On Thu, Aug 08, 2019 at 03:18:17PM +0800, Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
> So convert atomic_t ref counters to refcount_t.
On Thu, Aug 08, 2019 at 03:18:26PM +0800, Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
> So convert atomic_t ref counters to refcount_t.
Hi Stephen,
On Wed, Jul 24, 2019 at 07:42:27AM +1000, Stephen Rothwell wrote:
> In commit
> 8b515be512a2 ("vfio-ccw: Fix memory leak and don't call cp_free in cp_init")
> Fixes tag
> Fixes: 812271b910 ("s390/cio: Squash cp_free() and cp_unpin_free()")
> - SHA1 should be at least 12 digits lo
On Sun, Jun 09, 2019 at 01:35:44PM -0700, Guenter Roeck wrote:
> s390:tinyconfig fails to build with gcc 8.3.0.
...
> Marking __ctl_set_bit and __ctl_clear_bit as __always_inline fixes the
> problem.
>
> Fixes: 9012d011660e ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING")
> Sig
On Tue, Jun 11, 2019 at 11:15:46AM +0200, Peter Zijlstra wrote:
> On Sat, Jun 08, 2019 at 01:08:52PM +0200, Heiko Carstens wrote:
> > --- a/arch/s390/kernel/processor.c
> > +++ b/arch/s390/kernel/processor.c
> > @@ -31,6 +31,7 @@ struct cpu_info {
> > };
> >
tell the hypervisor to run this next CPU instead of the
current one. If there is only a limited number of real CPUs backing
the virtual CPUs we end up with the real CPUs passed around in a
round-robin fashion.
Patches 1 and 3 are just possible cleanups; the interesting part is
patch 2.
Heiko
the
hypervisor to run this next CPU instead of the current one. If there
is only a limited number of real CPUs backing the virtual CPUs we
end up with the real CPUs passed around in a round-robin fashion.
Signed-off-by: Martin Schwidefsky
Signed-off-by: Heiko Carstens
---
arch/s390/include/asm
spin_cpu_yield is unused, therefore remove it.
Signed-off-by: Heiko Carstens
---
arch/powerpc/include/asm/processor.h | 2 --
include/linux/processor.h| 9 -
2 files changed, 11 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm
stop_machine is the only user left of cpu_relax_yield. Given that it
now has special semantics which are tied to stop_machine introduce a
weak stop_machine_yield function which architectures can override, and
get rid of the generic cpu_relax_yield implementation.
Signed-off-by: Heiko Carstens
Hello Linus,
please pull two bug fixes for s390.
Thanks,
Heiko
The following changes since commit f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a:
Linux 5.2-rc3 (2019-06-02 13:55:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s
.h | 35 +++--
> 1 file changed, 18 insertions(+), 17 deletions(-)
Applied, thanks!
I also added the patch below:
>From b312d5e2244f635f83cbf19b850e26c1c443f465 Mon Sep 17 00:00:00 2001
From: Heiko Carstens
Date: Mon, 22 Jul 2019 14:16:46 +0200
Subject: [PATC
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 f
On Thu, Feb 21, 2019 at 01:12:40PM +0100, Cornelia Huck wrote:
> On Thu, 21 Feb 2019 11:42:25 +0100
> Harald Freudenberger wrote:
>
> > On 30.01.19 19:32, Sebastian Ott wrote:
> > > On Wed, 30 Jan 2019, Tony Krowiak wrote:
>
> > >> /*
> > >> +* A config change has happened, Force an ap bus re
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 s
701 - 800 of 1090 matches
Mail list logo
