Re: drivers/s390/char/keyboard.c kernel stack infoleak

On Fri, Aug 04, 2017 at 11:09:24AM +0200, Thomas Huth wrote: > Hi, > > On 03.08.2017 15:59, sohu0106 wrote: > > > > The stack object "kbdiacr" has a total size of 4 bytes. Its last 1 bytes > > are padding bytes after "result" which are not initialized and leaked to > > userland via

Re: [PATCH 06/11] s390/topology: Remove the unused parent_node() macro

t for cleanup. > > Reported-by: Michael Ellerman <m...@ellerman.id.au> > Signed-off-by: Dou Liyang <douly.f...@cn.fujitsu.com> > Cc: Martin Schwidefsky <schwidef...@de.ibm.com> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> > Cc: Michael Holzheu <hol

Re: [PATCH 06/11] s390/topology: Remove the unused parent_node() macro

t for cleanup. > > Reported-by: Michael Ellerman > Signed-off-by: Dou Liyang > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Cc: Michael Holzheu > Cc: linux-s...@vger.kernel.org > --- Are arch maintainers supposed to pick these patches up? In any case: Acked-by: Heiko Carstens

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 01:45:39PM +0200, Heiko Carstens wrote: > > Please note that only the memory hotplug is currently using this > > allocation scheme. The boot time memmap allocation could use the same > > trick as well but this is not done yet. > > Which kernel are t

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 01:45:39PM +0200, Heiko Carstens wrote: > > Please note that only the memory hotplug is currently using this > > allocation scheme. The boot time memmap allocation could use the same > > trick as well but this is not done yet. > > Which kernel are t

Re: [PATCH] mm: take memory hotplug lock within numa_zonelist_order_handler()

On Wed, Jul 26, 2017 at 01:31:12PM +0200, Michal Hocko wrote: > On Wed 26-07-17 13:17:38, Heiko Carstens wrote: > [...] > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 6d30e914afb6..fc32aa81f359 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c

Re: [PATCH] mm: take memory hotplug lock within numa_zonelist_order_handler()

On Wed, Jul 26, 2017 at 01:31:12PM +0200, Michal Hocko wrote: > On Wed 26-07-17 13:17:38, Heiko Carstens wrote: > [...] > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 6d30e914afb6..fc32aa81f359 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 10:33:31AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Physical memory hotadd has to allocate a memmap (struct page array) for > the newly added memory section. kmalloc is currantly used for those > allocations. > > This has some disadvantages a)

Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap

On Wed, Jul 26, 2017 at 10:33:31AM +0200, Michal Hocko wrote: > From: Michal Hocko > > Physical memory hotadd has to allocate a memmap (struct page array) for > the newly added memory section. kmalloc is currantly used for those > allocations. > > This has some disadvantages a) an existing

[PATCH] mm: take memory hotplug lock within numa_zonelist_order_handler()

.@linux.vnet.ibm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Michal Hocko <mho...@suse.com> Cc: Vlastimil Babka <vba...@suse.cz> Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- mm/page_alloc.

[PATCH] mm: take memory hotplug lock within numa_zonelist_order_handler()

MEZAWA Hiroyuki Cc: Thomas Gleixner Cc: Michal Hocko Cc: Vlastimil Babka Signed-off-by: Heiko Carstens --- mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6d30e914afb6..fc32aa81f359 100644 --- a/mm/page_alloc.c +++ b/mm

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

> > > Hmm, I though that NIAI is a NOP on older machines. A runtime check for > > > the facility bit is out of the question as the NIAI-7 gets inlined in > > > the spin_unlock code. So yes, the only available fix is to make the > > > NIAI hinting conditional on zEC12. Which is quite ugly as we

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

> > > Hmm, I though that NIAI is a NOP on older machines. A runtime check for > > > the facility bit is out of the question as the NIAI-7 gets inlined in > > > the spin_unlock code. So yes, the only available fix is to make the > > > NIAI hinting conditional on zEC12. Which is quite ugly as we

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

On Wed, Jul 26, 2017 at 07:40:44AM +0200, Martin Schwidefsky wrote: > On Wed, 26 Jul 2017 07:00:33 +0200 > Heiko Carstens <heiko.carst...@de.ibm.com> wrote: > > > On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote: > > > Hi Martin, > > > > &g

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

On Wed, Jul 26, 2017 at 07:40:44AM +0200, Martin Schwidefsky wrote: > On Wed, 26 Jul 2017 07:00:33 +0200 > Heiko Carstens wrote: > > > On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote: > > > Hi Martin, > > > > > > my s390 qemu tests in

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote: > Hi Martin, > > my s390 qemu tests in linux-next stopped working a few days ago. > Bisect points to commit 's390/spinlock: add niai spinlock hints'. > > Looking at the patch, this isn't really surprising; at least to me it looks >

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote: > Hi Martin, > > my s390 qemu tests in linux-next stopped working a few days ago. > Bisect points to commit 's390/spinlock: add niai spinlock hints'. > > Looking at the patch, this isn't really surprising; at least to me it looks >

Re: BUG: using __this_cpu_read() in preemptible [00000000] code: mm_percpu_wq/7

On Wed, Jul 12, 2017 at 10:44:54AM -0500, Christopher Lameter wrote: > On Wed, 7 Jun 2017, Andre Wild wrote: > > > I'm currently seeing the following message running kernel version 4.11.0. > > It looks like it was introduced with the patch > > 4037d452202e34214e8a939fa5621b2b3bbb45b7. > > A 2007

Re: BUG: using __this_cpu_read() in preemptible [00000000] code: mm_percpu_wq/7

On Wed, Jul 12, 2017 at 10:44:54AM -0500, Christopher Lameter wrote: > On Wed, 7 Jun 2017, Andre Wild wrote: > > > I'm currently seeing the following message running kernel version 4.11.0. > > It looks like it was introduced with the patch > > 4037d452202e34214e8a939fa5621b2b3bbb45b7. > > A 2007

Re: [PATCH 12/18] drivers: s390: Move static and inline before return type

On Thu, Jul 06, 2017 at 03:57:19AM -0700, Joe Perches wrote: > On Thu, 2017-07-06 at 12:29 +0200, Heiko Carstens wrote: > > On Wed, Jul 05, 2017 at 01:02:21PM -0700, Joe Perches wrote: > > > Make the code like the rest of the kernel. > [] > > > diff --git a/drivers/s3

Re: [PATCH 12/18] drivers: s390: Move static and inline before return type

On Thu, Jul 06, 2017 at 03:57:19AM -0700, Joe Perches wrote: > On Thu, 2017-07-06 at 12:29 +0200, Heiko Carstens wrote: > > On Wed, Jul 05, 2017 at 01:02:21PM -0700, Joe Perches wrote: > > > Make the code like the rest of the kernel. > [] > > > diff --git a/drivers/s3

Re: [PATCH 12/18] drivers: s390: Move static and inline before return type

On Wed, Jul 05, 2017 at 01:02:21PM -0700, Joe Perches wrote: > Make the code like the rest of the kernel. > > Signed-off-by: Joe Perches > --- > drivers/s390/net/ctcm_main.c| 2 +- > drivers/s390/net/qeth_l3_main.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH 12/18] drivers: s390: Move static and inline before return type

On Wed, Jul 05, 2017 at 01:02:21PM -0700, Joe Perches wrote: > Make the code like the rest of the kernel. > > Signed-off-by: Joe Perches > --- > drivers/s390/net/ctcm_main.c| 2 +- > drivers/s390/net/qeth_l3_main.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > diff --git

Re: [PATCH 10/11] s390: drivers: convert to use DRIVER_ATTR_RO/WO

On Fri, Jun 09, 2017 at 11:03:13AM +0200, Greg Kroah-Hartman wrote: > We are trying to get rid of DRIVER_ATTR(), and the s390 drivers' > attributes can be trivially changed to use DRIVER_ATTR_RO() and > DRIVER_ATTR_WO(). > > Cc: Martin Schwidefsky <schwidef...@de.ibm.com>

Re: [PATCH 10/11] s390: drivers: convert to use DRIVER_ATTR_RO/WO

On Fri, Jun 09, 2017 at 11:03:13AM +0200, Greg Kroah-Hartman wrote: > We are trying to get rid of DRIVER_ATTR(), and the s390 drivers' > attributes can be trivially changed to use DRIVER_ATTR_RO() and > DRIVER_ATTR_WO(). > > Cc: Martin Schwidefsky > Cc: Heiko Carstens >

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 08, 2017 at 01:24:01PM +0200, Martin Schwidefsky wrote: > On Thu, 8 Jun 2017 08:25:31 +0200 > Heiko Carstens <heiko.carst...@de.ibm.com> wrote: > > It would be more consistent, since right now a 32-bit ELF file with > > PT_S390_REQUEST_PGSTE will be exectuted, b

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 08, 2017 at 01:24:01PM +0200, Martin Schwidefsky wrote: > On Thu, 8 Jun 2017 08:25:31 +0200 > Heiko Carstens wrote: > > It would be more consistent, since right now a 32-bit ELF file with > > PT_S390_REQUEST_PGSTE will be exectuted, but the page tables won't h

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 08, 2017 at 07:35:28AM +0200, Martin Schwidefsky wrote: > On Wed, 7 Jun 2017 22:47:56 +0200 > Heiko Carstens <heiko.carst...@de.ibm.com> wrote: > > On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote: > > > +#define arch_elf_pt_proc(ehd

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 08, 2017 at 07:35:28AM +0200, Martin Schwidefsky wrote: > On Wed, 7 Jun 2017 22:47:56 +0200 > Heiko Carstens wrote: > > On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote: > > > +#define arch_elf_pt_proc(ehdr, phd

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote: > +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) \ > +({ \ > + struct elf64_hdr *_ehdr = (void *) ehdr;\ > + struct elf64_phdr *_phdr

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote: > +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) \ > +({ \ > + struct elf64_hdr *_ehdr = (void *) ehdr;\ > + struct elf64_phdr *_phdr

Re: [PATCH RFC tip/core/rcu 1/2] srcu: Allow use of Tiny/Tree SRCU from both process and interrupt context

On Tue, Jun 06, 2017 at 06:15:51PM +0200, Peter Zijlstra wrote: > On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote: > > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote: > > > > As a side note, I am asking myself, though, why we do need the

Re: [PATCH RFC tip/core/rcu 1/2] srcu: Allow use of Tiny/Tree SRCU from both process and interrupt context

On Tue, Jun 06, 2017 at 06:15:51PM +0200, Peter Zijlstra wrote: > On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote: > > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote: > > > > As a side note, I am asking myself, though, why we do need the

Re: [PATCH RFC tip/core/rcu 1/2] srcu: Allow use of Tiny/Tree SRCU from both process and interrupt context

On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote: > Adding s390 folks and list > >> Only s390 is TSO, arm64 is very much a weak arch. > > > > Right, and thus arm64 can implement a fast this_cpu_inc using LL/SC. > > s390 cannot because its atomic_inc has implicit memory

Re: [PATCH RFC tip/core/rcu 1/2] srcu: Allow use of Tiny/Tree SRCU from both process and interrupt context

On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote: > Adding s390 folks and list > >> Only s390 is TSO, arm64 is very much a weak arch. > > > > Right, and thus arm64 can implement a fast this_cpu_inc using LL/SC. > > s390 cannot because its atomic_inc has implicit memory

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Fri, Jun 02, 2017 at 11:46:47AM +0200, Martin Schwidefsky wrote: > On Fri, 2 Jun 2017 09:02:10 +0200 > Heiko Carstens <heiko.carst...@de.ibm.com> wrote: > > Maybe this is a bit over-simplified, but might work. > This is not over-simplified at all, that does wo

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Fri, Jun 02, 2017 at 11:46:47AM +0200, Martin Schwidefsky wrote: > On Fri, 2 Jun 2017 09:02:10 +0200 > Heiko Carstens wrote: > > Maybe this is a bit over-simplified, but might work. > This is not over-simplified at all, that does work: Good! > +struct arch_elf_state { &g

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 01, 2017 at 01:27:28PM +0200, David Hildenbrand wrote: > An alternative: Have some process that enables PGSTE for all of its > future children. Fork+execv qemu. However, such a process in between > will most likely confuse tooling like libvirt when it comes to process ids. That would

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 01, 2017 at 01:27:28PM +0200, David Hildenbrand wrote: > An alternative: Have some process that enables PGSTE for all of its > future children. Fork+execv qemu. However, such a process in between > will most likely confuse tooling like libvirt when it comes to process ids. That would

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: > > Unfortunately, converting all page tables to 4k pgste page tables is > > not possible without provoking various race conditions. > > That is one approach we tried and was found to be buggy. The point is that > you are not

Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste

On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: > > Unfortunately, converting all page tables to 4k pgste page tables is > > not possible without provoking various race conditions. > > That is one approach we tried and was found to be buggy. The point is that > you are not

Re: [-next] memory hotplug regression

mail. Tested with your patches on top of linux-next as of yesterday, however starting at commit fa812e869a6fe7495a17150bb2639075081ef709 ("mm/zswap.c: delete an error message for a failed memory allocation in zswap_dstmem_prepare()"), since the "mm: per-lruvec slab stats" patch series breaks everything ;) Tested-by: Heiko Carstens <heiko.carst...@de.ibm.com>

Re: [-next] memory hotplug regression

mail. Tested with your patches on top of linux-next as of yesterday, however starting at commit fa812e869a6fe7495a17150bb2639075081ef709 ("mm/zswap.c: delete an error message for a failed memory allocation in zswap_dstmem_prepare()"), since the "mm: per-lruvec slab stats" patch series breaks everything ;) Tested-by: Heiko Carstens

Re: [PATCH 2/6] mm: vmstat: move slab statistics from zone to node counters

On Wed, May 31, 2017 at 11:12:56AM +0200, Heiko Carstens wrote: > On Tue, May 30, 2017 at 02:17:20PM -0400, Johannes Weiner wrote: > > To re-implement slab cache vs. page cache balancing, we'll need the > > slab counters at the lruvec level, which, ever since lru reclaim was

Re: [PATCH 2/6] mm: vmstat: move slab statistics from zone to node counters

On Wed, May 31, 2017 at 11:12:56AM +0200, Heiko Carstens wrote: > On Tue, May 30, 2017 at 02:17:20PM -0400, Johannes Weiner wrote: > > To re-implement slab cache vs. page cache balancing, we'll need the > > slab counters at the lruvec level, which, ever since lru reclaim was

Re: [PATCH 2/6] mm: vmstat: move slab statistics from zone to node counters

On Tue, May 30, 2017 at 02:17:20PM -0400, Johannes Weiner wrote: > To re-implement slab cache vs. page cache balancing, we'll need the > slab counters at the lruvec level, which, ever since lru reclaim was > moved from the zone to the node, is the intersection of the node, not > the zone, and the

Re: [PATCH 2/6] mm: vmstat: move slab statistics from zone to node counters

On Tue, May 30, 2017 at 02:17:20PM -0400, Johannes Weiner wrote: > To re-implement slab cache vs. page cache balancing, we'll need the > slab counters at the lruvec level, which, ever since lru reclaim was > moved from the zone to the node, is the intersection of the node, not > the zone, and the

Re: [-next] memory hotplug regression

On Tue, May 30, 2017 at 04:32:47PM +0200, Michal Hocko wrote: > On Tue 30-05-17 14:37:24, Heiko Carstens wrote: > > On Tue, May 30, 2017 at 02:18:06PM +0200, Michal Hocko wrote: > > > > So ZONE_DMA ends within ZONE_NORMAL. This shouldn't be possible, unless > > &

Re: [-next] memory hotplug regression

On Tue, May 30, 2017 at 04:32:47PM +0200, Michal Hocko wrote: > On Tue 30-05-17 14:37:24, Heiko Carstens wrote: > > On Tue, May 30, 2017 at 02:18:06PM +0200, Michal Hocko wrote: > > > > So ZONE_DMA ends within ZONE_NORMAL. This shouldn't be possible, unless > > &

Re: [-next] memory hotplug regression

On Tue, May 30, 2017 at 02:18:06PM +0200, Michal Hocko wrote: > > So ZONE_DMA ends within ZONE_NORMAL. This shouldn't be possible, unless > > this restriction is gone? > > The patch below should help. It does fix this specific problem, but introduces a new one: # echo online_movable >

Re: [-next] memory hotplug regression

On Tue, May 30, 2017 at 02:18:06PM +0200, Michal Hocko wrote: > > So ZONE_DMA ends within ZONE_NORMAL. This shouldn't be possible, unless > > this restriction is gone? > > The patch below should help. It does fix this specific problem, but introduces a new one: # echo online_movable >

Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

On Fri, May 26, 2017 at 09:09:04PM +0200, Dmitry Vyukov wrote: > Some 64-bit atomic operations use 'long long' as operand/return type > (e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h); > while others use 'long' (e.g. arch/x86/include/asm/atomic64_64.h). > This makes it impossible

Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

On Fri, May 26, 2017 at 09:09:04PM +0200, Dmitry Vyukov wrote: > Some 64-bit atomic operations use 'long long' as operand/return type > (e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h); > while others use 'long' (e.g. arch/x86/include/asm/atomic64_64.h). > This makes it impossible

Re: [-next] memory hotplug regression

On Mon, May 29, 2017 at 10:52:31AM +0200, Michal Hocko wrote: > > Why is it a problem to change the default for 'online'? As far as I can see > > that doesn't have too much to do with the order of zones, no? > > `online' (aka MMOP_ONLINE_KEEP) should always inherit its current zone. > The

Re: [-next] memory hotplug regression

On Mon, May 29, 2017 at 10:52:31AM +0200, Michal Hocko wrote: > > Why is it a problem to change the default for 'online'? As far as I can see > > that doesn't have too much to do with the order of zones, no? > > `online' (aka MMOP_ONLINE_KEEP) should always inherit its current zone. > The

Re: [PATCH] s390: provide default ioremap and iounmap declaration

CONFIG_PCI set, but it is needed to compile. Thus, > if the function is ever hit it returns NULL. > > Signed-off-by: Logan Gunthorpe <log...@deltatee.com> > Cc: Martin Schwidefsky <schwidef...@de.ibm.com> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> > Cc: Al Viro <

Re: [PATCH] s390: provide default ioremap and iounmap declaration

CONFIG_PCI set, but it is needed to compile. Thus, > if the function is ever hit it returns NULL. > > Signed-off-by: Logan Gunthorpe > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Cc: Al Viro > --- > > Thanks to Al Viro for pointing out this corner case in s390. > >

Re: [-next] memory hotplug regression

On Wed, May 24, 2017 at 10:39:57AM +0200, Michal Hocko wrote: > On Wed 24-05-17 10:20:22, Heiko Carstens wrote: > > Having the ZONE_MOVABLE default was actually the only point why s390's > > arch_add_memory() was rather complex compared to other architectures. > > > > W

Re: [-next] memory hotplug regression

On Wed, May 24, 2017 at 10:39:57AM +0200, Michal Hocko wrote: > On Wed 24-05-17 10:20:22, Heiko Carstens wrote: > > Having the ZONE_MOVABLE default was actually the only point why s390's > > arch_add_memory() was rather complex compared to other architectures. > > > > W

Re: [PATCH V2] x86/ftrace: Make sure that ftrace trampolines are not RWX

On Fri, May 26, 2017 at 09:03:13AM +0200, Thomas Gleixner wrote: > > It seems like it really should. That would put it in a single place > > and avoid this mistake again in the future. Does module_memfree() have > > access to the allocation size, or does that need to get plumbed? > > No, it

Re: [PATCH V2] x86/ftrace: Make sure that ftrace trampolines are not RWX

On Fri, May 26, 2017 at 09:03:13AM +0200, Thomas Gleixner wrote: > > It seems like it really should. That would put it in a single place > > and avoid this mistake again in the future. Does module_memfree() have > > access to the allocation size, or does that need to get plumbed? > > No, it

Re: [patch V3 28/32] s390: Prevent hotplug rwsem recursion

plug > rwsem. stop_machine_cpuslocked() contains a lockdep assertion to catch any > unprotected callers. > > Signed-off-by: Thomas Gleixner <t...@linutronix.de> > Cc: Martin Schwidefsky <schwidef...@de.ibm.com> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> > Cc: l

Re: [patch V3 28/32] s390: Prevent hotplug rwsem recursion

plug > rwsem. stop_machine_cpuslocked() contains a lockdep assertion to catch any > unprotected callers. > > Signed-off-by: Thomas Gleixner > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Cc: linux-s...@vger.kernel.org > --- > arch/s390/kernel/jump_label.c |2 +- > arch/s390/

Re: [patch V3 15/32] s390/kernel: Use stop_machine_cpuslocked()

Thomas Gleixner <t...@linutronix.de> > Cc: linux-s...@vger.kernel.org > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> > Cc: Steven Rostedt <rost...@goodmis.org> > Cc: David Hildenbrand <d...@linux.vnet.ibm.com>

Re: [patch V3 15/32] s390/kernel: Use stop_machine_cpuslocked()

he hotplug locking to a percpu rwsem. > > Use stop_machine_cpuslocked() to avoid the nested call. Convert > *_online_cpus() to the new interfaces while at it. > > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Thomas Gleixner > Cc: linux-s...@vger.kernel.org >

[-next] memory hotplug regression

Hello Michal, I just re-tested linux-next with respect to your memory hotplug changes and actually (finally) figured out that your patch ("mm, memory_hotplug: do not associate hotadded memory to zones until online)" changes behaviour on s390: before your patch memory blocks that were offline and

[-next] memory hotplug regression

Hello Michal, I just re-tested linux-next with respect to your memory hotplug changes and actually (finally) figured out that your patch ("mm, memory_hotplug: do not associate hotadded memory to zones until online)" changes behaviour on s390: before your patch memory blocks that were offline and

Re: [PATCH] s390: use generic fb.h

On Wed, May 17, 2017 at 10:34:49AM +0200, Tobias Klauser wrote: > The arch uses a verbatim copy of the asm-generic version and does not > add any own implemntations to the header, so use asm-generic/fb.h > instead of duplicating code. > > Signed-off-by: Tobias Klauser > ---

Re: [PATCH] s390: use generic fb.h

On Wed, May 17, 2017 at 10:34:49AM +0200, Tobias Klauser wrote: > The arch uses a verbatim copy of the asm-generic version and does not > add any own implemntations to the header, so use asm-generic/fb.h > instead of duplicating code. > > Signed-off-by: Tobias Klauser > --- >

Re: [v3 9/9] s390: teach platforms not to zero struct pages memory

his table is allocated zeroed, but now it won't > be zeroed. The page table, if needed, is allocated and populated a couple of lines above. See the vmem_pte_alloc() call. So my request to include the hunk below is still valid ;) > >If you add the hunk below then this is > > >

Re: [v3 9/9] s390: teach platforms not to zero struct pages memory

his table is allocated zeroed, but now it won't > be zeroed. The page table, if needed, is allocated and populated a couple of lines above. See the vmem_pte_alloc() call. So my request to include the hunk below is still valid ;) > >If you add the hunk below then this is > > > >

Re: [v3 9/9] s390: teach platforms not to zero struct pages memory

ge = vmemmap_alloc_block(PMD_SIZE, node, > -true); > +VMEMMAP_ZERO); > if (!new_page) > goto out; > p

Re: [v3 9/9] s390: teach platforms not to zero struct pages memory

true); > +VMEMMAP_ZERO); > if (!new_page) > goto out; > pmd_val(*pm_dir) = __pa(new_page) | sgt_prot; If you add the h

Re: [PATCH 0/6] mm: make movable onlining suck less

uld take a look at patch 4 and the > arch_add_memory because I am not sure I've grokked what they wanted to > achieve there completely. [adding Gerald Schaefer] This seems to work fine on s390. So for the s390 bits: Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com>

Re: [PATCH 0/6] mm: make movable onlining suck less

uld take a look at patch 4 and the > arch_add_memory because I am not sure I've grokked what they wanted to > achieve there completely. [adding Gerald Schaefer] This seems to work fine on s390. So for the s390 bits: Acked-by: Heiko Carstens

Re: [PATCH] mm: fix section name for .data..ro_after_init

kernel/extable.c). > > Cc: Jakub Kicinski <jakub.kicin...@netronome.com> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> > Cc: Eddie Kovsky <e...@edkovsky.org> > Signed-off-by: Kees Cook <keesc...@chromium.org> > --- > arch/s390/include/asm/sections.h | 1 - &

Re: [PATCH] mm: fix section name for .data..ro_after_init

ro_after_init") > > The latter adds incorrect wrapping around the existing s390 section, > and came later. I'd prefer the s390 naming, so this moves the > s390-specific name up to the asm-generic/sections.h and renames the > section as used by kmemleak (and in the future, kernel/e

Re: [v2 5/5] mm: teach platforms not to zero struct pages memory

On Fri, Mar 24, 2017 at 03:19:52PM -0400, Pavel Tatashin wrote: > If we are using deferred struct page initialization feature, most of > "struct page"es are getting initialized after other CPUs are started, and > hence we are benefiting from doing this job in parallel. However, we are > still

Re: [v2 5/5] mm: teach platforms not to zero struct pages memory

On Fri, Mar 24, 2017 at 03:19:52PM -0400, Pavel Tatashin wrote: > If we are using deferred struct page initialization feature, most of > "struct page"es are getting initialized after other CPUs are started, and > hence we are benefiting from doing this job in parallel. However, we are > still

Re: [v1 0/5] parallelized "struct page" zeroing

On Fri, Mar 24, 2017 at 09:51:09AM +0100, Christian Borntraeger wrote: > On 03/24/2017 12:01 AM, Pavel Tatashin wrote: > > When deferred struct page initialization feature is enabled, we get a > > performance gain of initializing vmemmap in parallel after other CPUs are > > started. However, we

Re: [v1 0/5] parallelized "struct page" zeroing

On Fri, Mar 24, 2017 at 09:51:09AM +0100, Christian Borntraeger wrote: > On 03/24/2017 12:01 AM, Pavel Tatashin wrote: > > When deferred struct page initialization feature is enabled, we get a > > performance gain of initializing vmemmap in parallel after other CPUs are > > started. However, we

Re: [PATCH] lkdtm: add bad USER_DS test

On Thu, Mar 23, 2017 at 01:34:19PM -0700, Kees Cook wrote: > This adds CORRUPT_USER_DS to check that the get_fs() test on syscall return > still sees USER_DS during the new VERIFY_PRE_USERMODE_STATE checks. > > Signed-off-by: Kees Cook ... > +void

Re: [PATCH] lkdtm: add bad USER_DS test

On Thu, Mar 23, 2017 at 01:34:19PM -0700, Kees Cook wrote: > This adds CORRUPT_USER_DS to check that the get_fs() test on syscall return > still sees USER_DS during the new VERIFY_PRE_USERMODE_STATE checks. > > Signed-off-by: Kees Cook ... > +void lkdtm_CORRUPT_USER_DS(void) > +{ > + /* >

Re: [BUG 4.9/4.10] crash in __d_lookup() due to corrupted dentry_hashtable

On Fri, Mar 03, 2017 at 02:31:50PM +0100, Heiko Carstens wrote: > Hello Al, > > Gustavo reported the crash below within __d_lookup() on s390. I'm wondering > if you can make any sense of it: > > Unable to handle kernel pointer dereference in virtual kernel address space

Re: [BUG 4.9/4.10] crash in __d_lookup() due to corrupted dentry_hashtable

On Fri, Mar 03, 2017 at 02:31:50PM +0100, Heiko Carstens wrote: > Hello Al, > > Gustavo reported the crash below within __d_lookup() on s390. I'm wondering > if you can make any sense of it: > > Unable to handle kernel pointer dereference in virtual kernel address space

Re: [PATCH] s390/decompressor: fix initrd corruption caused by bss clear

On Mon, Mar 13, 2017 at 12:14:58PM -0300, Marcelo Henrique Cerri wrote: > Reorder the operations in decompress_kernel() to ensure initrd is moved > to a safe location before the bss section is zeroed. > > During decompression bss can overlap with the initrd and this can > corrupt the initrd

Re: [PATCH] s390/decompressor: fix initrd corruption caused by bss clear

On Mon, Mar 13, 2017 at 12:14:58PM -0300, Marcelo Henrique Cerri wrote: > Reorder the operations in decompress_kernel() to ensure initrd is moved > to a safe location before the bss section is zeroed. > > During decompression bss can overlap with the initrd and this can > corrupt the initrd

[PATCHv2 0/2] mm: add private lock to serialize memory hotplug operations

v1->v2: Add Acks from Dan and Raphael. Otherwise the patches are identical to v1. v1: These two patches are supposed to hopefully fix a memory hotplug problem reported by Sebastian Ott. Heiko Carstens (2): mm: add private lock to serialize memory hotplug operations drivers core: rem

[PATCHv2 0/2] mm: add private lock to serialize memory hotplug operations

v1->v2: Add Acks from Dan and Raphael. Otherwise the patches are identical to v1. v1: These two patches are supposed to hopefully fix a memory hotplug problem reported by Sebastian Ott. Heiko Carstens (2): mm: add private lock to serialize memory hotplug operations drivers core: rem

[PATCHv2 2/2] drivers core: remove assert_held_device_hotplug()

utchings <b...@decadent.org.uk> Cc: Gerald Schaefer <gerald.schae...@de.ibm.com> Cc: Martin Schwidefsky <schwidef...@de.ibm.com> Cc: Sebastian Ott <seb...@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- drivers/base/core.c| 5 -

[PATCHv2 2/2] drivers core: remove assert_held_device_hotplug()

The last caller of assert_held_device_hotplug() is gone, so remove it again. Acked-by: Dan Williams Cc: Michal Hocko Cc: "Rafael J. Wysocki" Cc: Vladimir Davydov Cc: Ben Hutchings Cc: Gerald Schaefer Cc: Martin Schwidefsky Cc: Sebastian Ott Signed-off-by: Heiko Carstens --- dr

[PATCHv2 1/2] mm: add private lock to serialize memory hotplug operations

ov@gmail.com> Cc: Ben Hutchings <b...@decadent.org.uk> Cc: Gerald Schaefer <gerald.schae...@de.ibm.com> Cc: Martin Schwidefsky <schwidef...@de.ibm.com> Reported-by: Sebastian Ott <seb...@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --

[PATCHv2 1/2] mm: add private lock to serialize memory hotplug operations

p things hopefully a bit easier the lock will be locked and unlocked within the mem_hotplug_begin/end() functions. Acked-by: Dan Williams Acked-by: Rafael J. Wysocki Cc: Michal Hocko Cc: Vladimir Davydov Cc: Ben Hutchings Cc: Gerald Schaefer Cc: Martin Schwidefsky Reported-by: Sebastian Ott Si

Re: [PATCH 1/2] mm: add private lock to serialize memory hotplug operations

On Thu, Mar 09, 2017 at 11:34:44PM +0100, Rafael J. Wysocki wrote: > > The memory described by devm_memremap_pages() is never "onlined" to > > the core mm. We're only using arch_add_memory() to get a linear > > mapping and page structures. The rest of memory hotplug is skipped, > > and this

Re: [PATCH 1/2] mm: add private lock to serialize memory hotplug operations

On Thu, Mar 09, 2017 at 11:34:44PM +0100, Rafael J. Wysocki wrote: > > The memory described by devm_memremap_pages() is never "onlined" to > > the core mm. We're only using arch_add_memory() to get a linear > > mapping and page structures. The rest of memory hotplug is skipped, > > and this

Re: [PATCH] s390/decompressor: fix initrd corruption caused by bss clear

On Mon, Mar 13, 2017 at 12:14:58PM -0300, Marcelo Henrique Cerri wrote: > Reorder the operations in decompress_kernel() to ensure initrd is moved > to a safe location before the bss section is zeroed. > > During decompression bss can overlap with the initrd and this can > corrupt the initrd

Re: [PATCH] s390/decompressor: fix initrd corruption caused by bss clear

On Mon, Mar 13, 2017 at 12:14:58PM -0300, Marcelo Henrique Cerri wrote: > Reorder the operations in decompress_kernel() to ensure initrd is moved > to a safe location before the bss section is zeroed. > > During decompression bss can overlap with the initrd and this can > corrupt the initrd

[PATCH 1/2] mm: add private lock to serialize memory hotplug operations

gmail.com> Cc: Ben Hutchings <b...@decadent.org.uk> Cc: Gerald Schaefer <gerald.schae...@de.ibm.com> Cc: Martin Schwidefsky <schwidef...@de.ibm.com> Reported-by: Sebastian Ott <seb...@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- ker

[PATCH 2/2] drivers core: remove assert_held_device_hotplug()

utchings <b...@decadent.org.uk> Cc: Gerald Schaefer <gerald.schae...@de.ibm.com> Cc: Martin Schwidefsky <schwidef...@de.ibm.com> Cc: Sebastian Ott <seb...@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- drivers/base/core.c| 5 - inc

[PATCH 1/2] mm: add private lock to serialize memory hotplug operations

p things hopefully a bit easier the lock will be locked and unlocked within the mem_hotplug_begin/end() functions. Cc: Dan Williams Cc: Michal Hocko Cc: "Rafael J. Wysocki" Cc: Vladimir Davydov Cc: Ben Hutchings Cc: Gerald Schaefer Cc: Martin Schwidefsky Reported-by: Sebastian Ott Signed-of

<    1   2   3   4   5   6   7   8   9   10   >