Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Wed, 22 Nov 2017 09:43:19 -0800 schrieb Kees Cook <keesc...@chromium.org>: > On Wed, Nov 22, 2017 at 1:28 AM, Michael Holzheu > <holz...@linux.vnet.ibm.com> wrote: > > Am Mon, 13 Nov 2017 11:19:38 +0100 > > schrieb Michael Holzheu <holz...@linux.vnet.ibm.com&

Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Wed, 22 Nov 2017 09:43:19 -0800 schrieb Kees Cook : > On Wed, Nov 22, 2017 at 1:28 AM, Michael Holzheu > wrote: > > Am Mon, 13 Nov 2017 11:19:38 +0100 > > schrieb Michael Holzheu : > > > >> Am Fri, 10 Nov 2017 10:46:49 -0800 > >> schrieb Kees Cook : &

Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Mon, 13 Nov 2017 11:19:38 +0100 schrieb Michael Holzheu <holz...@linux.vnet.ibm.com>: > Am Fri, 10 Nov 2017 10:46:49 -0800 > schrieb Kees Cook <keesc...@chromium.org>: > > > On Fri, Nov 10, 2017 at 7:45 AM, Michael Holzheu > > <holz...@linux.v

Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Mon, 13 Nov 2017 11:19:38 +0100 schrieb Michael Holzheu : > Am Fri, 10 Nov 2017 10:46:49 -0800 > schrieb Kees Cook : > > > On Fri, Nov 10, 2017 at 7:45 AM, Michael Holzheu > > wrote: > > > Hello Kees, > > > > > > When I try to run the

Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Fri, 10 Nov 2017 10:46:49 -0800 schrieb Kees Cook <keesc...@chromium.org>: > On Fri, Nov 10, 2017 at 7:45 AM, Michael Holzheu > <holz...@linux.vnet.ibm.com> wrote: > > Hello Kees, > > > > When I try to run the crash tool on my s390 live system I get a

Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Am Fri, 10 Nov 2017 10:46:49 -0800 schrieb Kees Cook : > On Fri, Nov 10, 2017 at 7:45 AM, Michael Holzheu > wrote: > > Hello Kees, > > > > When I try to run the crash tool on my s390 live system I get a kernel panic > > when reading memory within the

Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Hello Kees, When I try to run the crash tool on my s390 live system I get a kernel panic when reading memory within the kernel image: # uname -a Linux r3545011 4.14.0-rc8-00066-g1c9dbd4615fd #45 SMP PREEMPT Fri Nov 10 16:16:22 CET 2017 s390x s390x s390x GNU/Linux # crash

Does CONFIG_HARDENED_USERCOPY break /dev/mem?

Hello Kees, When I try to run the crash tool on my s390 live system I get a kernel panic when reading memory within the kernel image: # uname -a Linux r3545011 4.14.0-rc8-00066-g1c9dbd4615fd #45 SMP PREEMPT Fri Nov 10 16:16:22 CET 2017 s390x s390x s390x GNU/Linux # crash

Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition

6a4c19 ("crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE") the KEXEC_NOTE_BYTES macro is not used anymore and for s390 we create the ELF header in the new kernel anyway. Therefore remove the macro. Reported-by: Xunlei Pang <xp...@redhat.com> Reviewe

Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition

ELF header in the new kernel anyway. Therefore remove the macro. Reported-by: Xunlei Pang Reviewed-by: Mikhail Zaslonko Signed-off-by: Michael Holzheu --- arch/s390/include/asm/kexec.h | 18 -- include/linux/crash_core.h| 5 + include/linux/kexec.h | 9 -

Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition

Hi Xunlei, Sorry for the late reply - I was on vacation up to now. Give us some time to look into this issue. Michael Am Fri, 9 Jun 2017 10:17:05 +0800 schrieb Xunlei Pang : > S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which > is now defined as follows: >

Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition

Hi Xunlei, Sorry for the late reply - I was on vacation up to now. Give us some time to look into this issue. Michael Am Fri, 9 Jun 2017 10:17:05 +0800 schrieb Xunlei Pang : > S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which > is now defined as follows: > typedef u32

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

ch allocates extra pages for these vmcoreinfo_XXX variables, > one advantage is that it enhances some safety of vmcoreinfo, because > vmcoreinfo now is kept far away from other kernel data structures. > > Suggested-by: Eric Biederman <ebied...@xmission.com> > Cc: Michael Hol

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

s for these vmcoreinfo_XXX variables, > one advantage is that it enhances some safety of vmcoreinfo, because > vmcoreinfo now is kept far away from other kernel data structures. > > Suggested-by: Eric Biederman > Cc: Michael Holzheu > Cc: Juergen Gross > Signed-off-by: Xunle

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Am Thu, 23 Mar 2017 17:23:53 +0800 schrieb Xunlei Pang <xp...@redhat.com>: > On 03/23/2017 at 04:48 AM, Michael Holzheu wrote: > > Am Wed, 22 Mar 2017 12:30:04 +0800 > > schrieb Dave Young <dyo...@redhat.com>: > > > >> On 03/21/17 at 10:18pm, Eric

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Am Thu, 23 Mar 2017 17:23:53 +0800 schrieb Xunlei Pang : > On 03/23/2017 at 04:48 AM, Michael Holzheu wrote: > > Am Wed, 22 Mar 2017 12:30:04 +0800 > > schrieb Dave Young : > > > >> On 03/21/17 at 10:18pm, Eric W. Biederman wrote: > >>> Dave Young w

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Am Wed, 22 Mar 2017 12:30:04 +0800 schrieb Dave Young : > On 03/21/17 at 10:18pm, Eric W. Biederman wrote: > > Dave Young writes: > > [snip] > > > I think makedumpfile is using it, but I also vote to remove the > > > CRASHTIME. It is better not to do this

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Am Wed, 22 Mar 2017 12:30:04 +0800 schrieb Dave Young : > On 03/21/17 at 10:18pm, Eric W. Biederman wrote: > > Dave Young writes: > > [snip] > > > I think makedumpfile is using it, but I also vote to remove the > > > CRASHTIME. It is better not to do this while crashing and a makedumpfile > >

[PATCH] bpf/samples: Fix PT_REGS_IP on s390x and use it

ko Kosic <zvonko.ko...@de.ibm.com> Signed-off-by: Michael Holzheu <holz...@linux.vnet.ibm.com> --- samples/bpf/bpf_helpers.h | 2 +- samples/bpf/sampleip_kern.c| 2 +- samples/bpf/trace_event_kern.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/samples/

[PATCH] bpf/samples: Fix PT_REGS_IP on s390x and use it

The files "sampleip_kern.c" and "trace_event_kern.c" directly access "ctx->regs.ip" which is not available on s390x. Fix this and use the PT_REGS_IP() macro instead. Besides of that also fix the macro for s390x and use psw.addr from pt_regs. Reported-by: Zvo

Re: [PATCH] s390/hypfs: Use kmalloc_array() in diag0c_store()

Am Thu, 1 Sep 2016 17:39:02 +0200 schrieb Paolo Bonzini : > > > On 01/09/2016 12:32, Heiko Carstens wrote: > > On Thu, Sep 01, 2016 at 11:38:15AM +0200, SF Markus Elfring wrote: > >> From: Markus Elfring > >> Date: Thu, 1 Sep 2016 11:30:58

Re: [PATCH] s390/hypfs: Use kmalloc_array() in diag0c_store()

Am Thu, 1 Sep 2016 17:39:02 +0200 schrieb Paolo Bonzini : > > > On 01/09/2016 12:32, Heiko Carstens wrote: > > On Thu, Sep 01, 2016 at 11:38:15AM +0200, SF Markus Elfring wrote: > >> From: Markus Elfring > >> Date: Thu, 1 Sep 2016 11:30:58 +0200 > >> > >> A multiplication for the size

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Am Thu, 18 Aug 2016 10:42:08 -0400 schrieb Tejun Heo <t...@kernel.org>: > Hello, Michael. > > On Thu, Aug 18, 2016 at 11:30:51AM +0200, Michael Holzheu wrote: > > Well, "no requirement" this is not 100% correct. Currently we use > > the CPU topology in

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Am Thu, 18 Aug 2016 10:42:08 -0400 schrieb Tejun Heo : > Hello, Michael. > > On Thu, Aug 18, 2016 at 11:30:51AM +0200, Michael Holzheu wrote: > > Well, "no requirement" this is not 100% correct. Currently we use > > the CPU topology information to assign new

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Am Wed, 17 Aug 2016 09:58:55 -0400 schrieb Tejun Heo : > Hello, Heiko. > > On Wed, Aug 17, 2016 at 12:19:53AM +0200, Heiko Carstens wrote: > > I think the easiest solution would be to simply assign all cpus, > > for which we do not have any topology information, to an arbitrary

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Am Wed, 17 Aug 2016 09:58:55 -0400 schrieb Tejun Heo : > Hello, Heiko. > > On Wed, Aug 17, 2016 at 12:19:53AM +0200, Heiko Carstens wrote: > > I think the easiest solution would be to simply assign all cpus, > > for which we do not have any topology information, to an arbitrary > > node; e.g.

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Am Wed, 17 Aug 2016 00:19:53 +0200 schrieb Heiko Carstens : > On Tue, Aug 16, 2016 at 11:42:05AM -0400, Tejun Heo wrote: > > Hello, Peter. > > > > On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote: > > > On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Am Wed, 17 Aug 2016 00:19:53 +0200 schrieb Heiko Carstens : > On Tue, Aug 16, 2016 at 11:42:05AM -0400, Tejun Heo wrote: > > Hello, Peter. > > > > On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote: > > > On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote: > > > > As long as

Re: [PATCH v2] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

)_crashkres() to replace former > crash_map/unmap_reserved_pages() which by now has been only > used by S390. > > The consolidation work needs the crash memory to be mapped > initially, so get rid of S390 crash kernel memblock removal > in reserve_crashkernel(). If you fix this comment

Re: [PATCH v2] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

; crash_map/unmap_reserved_pages() which by now has been only > used by S390. > > The consolidation work needs the crash memory to be mapped > initially, so get rid of S390 crash kernel memblock removal > in reserve_crashkernel(). If you fix this comment, I am fine with your patch. Acked-by: Michael Holzheu

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hello Xunlei, On Sat, 2 Apr 2016 09:23:50 +0800 Xunlei Pang <xp...@redhat.com> wrote: > On 2016/04/02 at 01:41, Michael Holzheu wrote: > > Hello Xunlei again, > > > > Some initial comments below... > > > > On Wed, 30 Mar 2016 19:47:21 +0800 > > Xunl

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hello Xunlei, On Sat, 2 Apr 2016 09:23:50 +0800 Xunlei Pang wrote: > On 2016/04/02 at 01:41, Michael Holzheu wrote: > > Hello Xunlei again, > > > > Some initial comments below... > > > > On Wed, 30 Mar 2016 19:47:21 +0800 &

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

0x88) > ([<001c49b0>] crash_shrink_memory+0xb8/0x1a0) > ([<0015bcae>] kexec_crash_size_store+0x46/0x60) > ([<0033d326>] kernfs_fop_write+0x136/0x180) > ([<002b253c>] __vfs_write+0x3c/0x100) > ([<002b35ce>

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

49b0>] crash_shrink_memory+0xb8/0x1a0) > ([<0015bcae>] kexec_crash_size_store+0x46/0x60) > ([<0033d326>] kernfs_fop_write+0x136/0x180) > ([<0000002b253c>] __vfs_write+0x3c/0x100) > ([<002b35ce>] vfs_write+0x8e/0x190) > ([<000

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

bcae>] kexec_crash_size_store+0x46/0x60) > ([<0033d326>] kernfs_fop_write+0x136/0x180) > ([<002b253c>] __vfs_write+0x3c/0x100) > ([<002b35ce>] vfs_write+0x8e/0x190) > ([<002b4ca0>] SyS_write+0x60/0xd0) &

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

e+0x46/0x60) > ([<0033d326>] kernfs_fop_write+0x136/0x180) > ([<0000002b253c>] __vfs_write+0x3c/0x100) > ([<002b35ce>] vfs_write+0x8e/0x190) > ([<002b4ca0>] SyS_write+0x60/0xd0) > ([<0063067c>] system_cal

Re: [PATCH] kexec: unmap reserved pages for each error-return way

On Thu, 28 Jan 2016 21:12:54 +0800 Xunlei Pang wrote: > On 2016/01/28 at 20:44, Michael Holzheu wrote: > > On Thu, 28 Jan 2016 19:56:56 +0800 > > Xunlei Pang wrote: > > > >> On 2016/01/28 at 18:32, Michael Holzheu wrote: > >>> On Wed, 27 Jan 2016

Re: [PATCH] kexec: unmap reserved pages for each error-return way

On Thu, 28 Jan 2016 19:56:56 +0800 Xunlei Pang wrote: > On 2016/01/28 at 18:32, Michael Holzheu wrote: > > On Wed, 27 Jan 2016 11:15:46 -0800 > > Andrew Morton wrote: > > > >> On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov > >> wrote: >

Re: [PATCH] kexec: unmap reserved pages for each error-return way

On Wed, 27 Jan 2016 11:15:46 -0800 Andrew Morton wrote: > On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov > wrote: > > > For allocation of kimage failure or kexec_prepare or load segments > > errors there is no need to keep crashkernel memory mapped. > > It will affect only s390 as

Re: [PATCH] kexec: unmap reserved pages for each error-return way

On Thu, 28 Jan 2016 19:56:56 +0800 Xunlei Pang <xp...@redhat.com> wrote: > On 2016/01/28 at 18:32, Michael Holzheu wrote: > > On Wed, 27 Jan 2016 11:15:46 -0800 > > Andrew Morton <a...@linux-foundation.org> wrote: > > > >> On Wed, 27 Jan 2016 14:48:31 +0

Re: [PATCH] kexec: unmap reserved pages for each error-return way

On Wed, 27 Jan 2016 11:15:46 -0800 Andrew Morton wrote: > On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov > wrote: > > > For allocation of kimage failure or kexec_prepare or load segments > > errors there is no need to keep crashkernel

Re: [PATCH] kexec: unmap reserved pages for each error-return way

On Thu, 28 Jan 2016 21:12:54 +0800 Xunlei Pang <xp...@redhat.com> wrote: > On 2016/01/28 at 20:44, Michael Holzheu wrote: > > On Thu, 28 Jan 2016 19:56:56 +0800 > > Xunlei Pang <xp...@redhat.com> wrote: > > > >> On 2016/01/28 at 18:32, Michael Holzheu

Re: [PATCH] numa: fix /proc//numa_maps for hugetlbfs on s390

On Mon, 25 Jan 2016 14:51:16 -0800 Andrew Morton wrote: > On Mon, 25 Jan 2016 17:30:42 +0100 Michael Holzheu > wrote: > > > When working with hugetlbfs ptes (which are actually pmds) is not > > valid to directly use pte functions like pte_present() because the > >

Re: [PATCH] numa: fix /proc//numa_maps for hugetlbfs on s390

On Mon, 25 Jan 2016 14:51:16 -0800 Andrew Morton <a...@linux-foundation.org> wrote: > On Mon, 25 Jan 2016 17:30:42 +0100 Michael Holzheu > <holz...@linux.vnet.ibm.com> wrote: > > > When working with hugetlbfs ptes (which are actually pmds) is not > > valid t

[PATCH] numa: fix /proc//numa_maps for hugetlbfs on s390

in the "numa_maps" output. 2) The pte_dirty() function always returns false for all hugetlb ptes. Therefore these pages are reported as "mapped=xxx" instead of "dirty=xxx". Therefore use huge_ptep_get() to correctly convert the hugetlb ptes. Reviewed-by: Gerald Sc

[PATCH] numa: fix /proc//numa_maps for hugetlbfs on s390

Gerald Schaefer <gerald.schae...@de.ibm.com> Signed-off-by: Michael Holzheu <holz...@linux.vnet.ibm.com> --- fs/proc/task_mmu.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 85d16c6..4a0c31f 100644 --- a/fs/proc/task_

[PATCH] numa: fix /proc//numa_maps on s390

the two missing functions calls to do this. Reviewed-by: Gerald Schaefer Signed-off-by: Michael Holzheu --- fs/proc/task_mmu.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 65a1b6c..e287e32 100644 --- a/fs/proc

[PATCH] numa: fix /proc//numa_maps on s390

the two missing functions calls to do this. Reviewed-by: Gerald Schaefer <gerald.schae...@de.ibm.com> Signed-off-by: Michael Holzheu <holz...@linux.vnet.ibm.com> --- fs/proc/task_mmu.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/proc/task_mmu

Re: [RFC][PATCH] sched: Start stopper early

> > > > > [ FWIW, I will be offline for the next two weeks ] > > > > So the series from Oleg would be good to try; I can make a git tree for > > you, or otherwise stuff the lot into a single patch. > > > > Should I be talking to someone else whilst you're

Re: [RFC][PATCH] sched: Start stopper early

eems_ to be reproducible. > > > > > > [ FWIW, I will be offline for the next two weeks ] > > > > So the series from Oleg would be good to try; I can make a git tree for > > you, or otherwise stuff the lot into a single patch. > > > > Should I be

Re: [RFC PATCH] drivers/base: use cpu->node_id for from_nid

On Wed, 5 Aug 2015 13:51:21 -0700 Greg Kroah-Hartman wrote: > On Thu, Jul 30, 2015 at 08:35:51PM +0200, Michael Holzheu wrote: > > Hello Greg, > > > > Is it possible to use "from_nid = cpu->node_id"? > > > > Background: > > > &

Re: [RFC PATCH] drivers/base: use cpu-node_id for from_nid

On Wed, 5 Aug 2015 13:51:21 -0700 Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Jul 30, 2015 at 08:35:51PM +0200, Michael Holzheu wrote: Hello Greg, Is it possible to use from_nid = cpu-node_id? Background: I am currently working on (fake) NUMA support for s390

[RFC PATCH] drivers/base: use cpu->node_id for from_nid

that each CPU that was deconfigured at boot time stays in node 0 because cpu_to_node() returns the same node before and after setting the CPU online. Using "cpu->node_id" for "from_nid" instead of calling cpu_to_node() would help in our case. Signed-off-by: Michael Holzh

[RFC PATCH] drivers/base: use cpu-node_id for from_nid

cpu_to_node() returns the same node before and after setting the CPU online. Using cpu-node_id for from_nid instead of calling cpu_to_node() would help in our case. Signed-off-by: Michael Holzheu holz...@linux.vnet.ibm.com --- drivers/base/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Tue, 14 Jul 2015 10:09:20 -0400 Vivek Goyal wrote: > On Fri, Jul 10, 2015 at 11:14:06AM +0200, Michael Holzheu wrote: > > [..] > > What about the following patch: > > --- > > diff --git a/kernel/kexec.c b/kernel/kexec.c > > index 7a36fdc..7837c4e 100644 &

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Tue, 14 Jul 2015 10:09:20 -0400 Vivek Goyal vgo...@redhat.com wrote: On Fri, Jul 10, 2015 at 11:14:06AM +0200, Michael Holzheu wrote: [..] What about the following patch: --- diff --git a/kernel/kexec.c b/kernel/kexec.c index 7a36fdc..7837c4e 100644 --- a/kernel/kexec.c +++ b

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 11:14:06 +0200 Michael Holzheu wrote: > On Fri, 10 Jul 2015 17:03:22 +0800 > Minfei Huang wrote: [snip] > +static int __kexec_load(unsigned long entry, unsigned long nr_segments, > + struct kexec_segment __us

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 17:03:22 +0800 Minfei Huang wrote: > On 07/10/15 at 10:54P, Michael Holzheu wrote: > > On Fri, 10 Jul 2015 13:12:17 +0800 > > Minfei Huang wrote: > > > > > For some arch, kexec shall map the reserved pages, then use them, when > >

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 13:12:17 +0800 Minfei Huang wrote: > For some arch, kexec shall map the reserved pages, then use them, when > we try to start the kdump service. > > Now kexec will never unmap the reserved pages, once it fails to continue > starting the kdump service. So we make a pair of

Re: [PATCH v3] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 12:05:27 +0800 Minfei Huang wrote: > On 07/09/15 at 05:54P, Michael Holzheu wrote: > > On Tue, 7 Jul 2015 17:18:40 -0400 > > Vivek Goyal wrote: > > > > > On Thu, Jul 02, 2015 at 09:45:52AM +0800, Minfei Huang wrote: > > > > [snip]

Re: [PATCH v3] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 12:05:27 +0800 Minfei Huang mnfhu...@gmail.com wrote: On 07/09/15 at 05:54P, Michael Holzheu wrote: On Tue, 7 Jul 2015 17:18:40 -0400 Vivek Goyal vgo...@redhat.com wrote: On Thu, Jul 02, 2015 at 09:45:52AM +0800, Minfei Huang wrote: [snip] I am thinking

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 13:12:17 +0800 Minfei Huang mnfhu...@gmail.com wrote: For some arch, kexec shall map the reserved pages, then use them, when we try to start the kdump service. Now kexec will never unmap the reserved pages, once it fails to continue starting the kdump service. So we make

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 17:03:22 +0800 Minfei Huang mnfhu...@gmail.com wrote: On 07/10/15 at 10:54P, Michael Holzheu wrote: On Fri, 10 Jul 2015 13:12:17 +0800 Minfei Huang mnfhu...@gmail.com wrote: For some arch, kexec shall map the reserved pages, then use them, when we try to start

Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Fri, 10 Jul 2015 11:14:06 +0200 Michael Holzheu holz...@linux.vnet.ibm.com wrote: On Fri, 10 Jul 2015 17:03:22 +0800 Minfei Huang mnfhu...@gmail.com wrote: [snip] +static int __kexec_load(unsigned long entry, unsigned long nr_segments, + struct kexec_segment __user

Re: [PATCH v3] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Tue, 7 Jul 2015 17:18:40 -0400 Vivek Goyal wrote: > On Thu, Jul 02, 2015 at 09:45:52AM +0800, Minfei Huang wrote: [snip] > I am thinking of moving kernel loading code in a separate function to > make things little simpler. Right now it is confusing. > > Can you please test attached patch.

Re: [PATCH v3] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

On Tue, 7 Jul 2015 17:18:40 -0400 Vivek Goyal vgo...@redhat.com wrote: On Thu, Jul 02, 2015 at 09:45:52AM +0800, Minfei Huang wrote: [snip] I am thinking of moving kernel loading code in a separate function to make things little simpler. Right now it is confusing. Can you please test

Re: [PATCH v2] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

Hello Minfei, Regarding functionality your patch looks ok for me. But the code is not easy to read. What about replacing the "failure" label with "fail_unmap_pages"? Michael On Tue, 30 Jun 2015 13:44:46 +0800 Minfei Huang wrote: > For some arch, kexec shall map the reserved pages, then use

Re: [PATCH v2] kexec: Make a pair of map and unmap reserved pages when kdump fails to start

Hello Minfei, Regarding functionality your patch looks ok for me. But the code is not easy to read. What about replacing the failure label with fail_unmap_pages? Michael On Tue, 30 Jun 2015 13:44:46 +0800 Minfei Huang mnfhu...@gmail.com wrote: For some arch, kexec shall map the reserved

Re: [PATCH RFC] s390/sclp: pass timeout as HZ independent value

On Fri, 29 May 2015 13:49:36 +0200 Nicholas Mc Guire wrote: > On Fri, 29 May 2015, Heiko Carstens wrote: > > > On Fri, May 29, 2015 at 11:51:54AM +0200, Nicholas Mc Guire wrote: > > > On Fri, 29 May 2015, Heiko Carstens wrote: > > > > Yes, the orginal code seems to be broken. Since I've no idea

Re: [PATCH RFC] s390/sclp: pass timeout as HZ independent value

On Fri, 29 May 2015 13:49:36 +0200 Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 29 May 2015, Heiko Carstens wrote: On Fri, May 29, 2015 at 11:51:54AM +0200, Nicholas Mc Guire wrote: On Fri, 29 May 2015, Heiko Carstens wrote: Yes, the orginal code seems to be broken. Since I've no

Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

On Thu, 22 Jan 2015 09:32:43 -0800 Alexei Starovoitov wrote: > On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu > wrote: > > Looks like the "test_maps" test case expects to get the keys in > > the wrong order when iterating over the elements: > > > &g

Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

On Thu, 22 Jan 2015 09:32:43 -0800 Alexei Starovoitov alexei.starovoi...@gmail.com wrote: On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu holz...@linux.vnet.ibm.com wrote: Looks like the test_maps test case expects to get the keys in the wrong order when iterating over the elements

Re: [PATCH] bpf: Call rcu_read_unlock() before copy_to_user()

On Thu, 22 Jan 2015 09:27:21 -0800 Alexei Starovoitov wrote: > On Thu, Jan 22, 2015 at 7:57 AM, Michael Holzheu > wrote: > > We must not hold locks when calling copy_to_user(): > > > > BUG: sleeping function called from invalid context at mm/memory.c:3732 > > in_a

[PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

the correct order. Signed-off-by: Michael Holzheu --- samples/bpf/test_maps.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/samples/bpf/test_maps.c +++ b/samples/bpf/test_maps.c @@ -69,9 +69,9 @@ static void test_hashmap_sanity(int i, v /* iterate

[PATCH] bpf: Call rcu_read_unlock() before copy_to_user()

he lock earlier because it is not needed for copy_to_user(). Signed-off-by: Michael Holzheu --- kernel/bpf/syscall.c |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -172,17 +172,16 @@ static int map_lookup_elem(union bpf_att

[PATCH] bpf: Call rcu_read_unlock() before copy_to_user()

[03fffd15f566] 0x3fffd15f566 1 lock held by test_maps/671: #0: (rcu_read_lock){..}, at: [00264190] map_lookup_elem+0xe8/0x260 So call rcu_read_unlock() before copy_to_user(). We can release the lock earlier because it is not needed for copy_to_user(). Signed-off-by: Michael Holzheu holz

[PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

order. Signed-off-by: Michael Holzheu holz...@linux.vnet.ibm.com --- samples/bpf/test_maps.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/samples/bpf/test_maps.c +++ b/samples/bpf/test_maps.c @@ -69,9 +69,9 @@ static void test_hashmap_sanity(int i, v /* iterate

Re: [PATCH] bpf: Call rcu_read_unlock() before copy_to_user()

On Thu, 22 Jan 2015 09:27:21 -0800 Alexei Starovoitov alexei.starovoi...@gmail.com wrote: On Thu, Jan 22, 2015 at 7:57 AM, Michael Holzheu holz...@linux.vnet.ibm.com wrote: We must not hold locks when calling copy_to_user(): BUG: sleeping function called from invalid context at mm

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

On Mon, 25 Nov 2013 10:36:20 -0500 Vivek Goyal wrote: > On Mon, Nov 25, 2013 at 11:04:28AM +0100, Michael Holzheu wrote: > > On Fri, 22 Nov 2013 05:34:03 -0800 > > ebied...@xmission.com (Eric W. Biederman) wrote: > > > > > Vivek Goyal writes: > > > &g

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

On Fri, 22 Nov 2013 05:34:03 -0800 ebied...@xmission.com (Eric W. Biederman) wrote: > Vivek Goyal writes: > >> There is also a huge missing piece of this in that your purgatory is not > >> checking a hash of the loaded image before jumping too it. Without that > >> this is a huge regression at

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

On Fri, 22 Nov 2013 05:34:03 -0800 ebied...@xmission.com (Eric W. Biederman) wrote: Vivek Goyal vgo...@redhat.com writes: There is also a huge missing piece of this in that your purgatory is not checking a hash of the loaded image before jumping too it. Without that this is a huge

Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

On Mon, 25 Nov 2013 10:36:20 -0500 Vivek Goyal vgo...@redhat.com wrote: On Mon, Nov 25, 2013 at 11:04:28AM +0100, Michael Holzheu wrote: On Fri, 22 Nov 2013 05:34:03 -0800 ebied...@xmission.com (Eric W. Biederman) wrote: Vivek Goyal vgo...@redhat.com writes: There is also a huge

Re: [PATCH 0/3] procfs, vmcore: fix regression of mmap on /proc/vmcore since v3.12-rc1

Hello Hatayama, We successfully tested your patches on s390, mmap for /proc/vmcore seems to work again. Thanks! Michael On Mon, 14 Oct 2013 18:36:06 +0900 HATAYAMA Daisuke wrote: > This patch set fixes regression of mmap on /proc/vmcore since > v3.12-rc1. The primary one is the 2nd patch.

Re: [PATCH 0/3] procfs, vmcore: fix regression of mmap on /proc/vmcore since v3.12-rc1

Hello Hatayama, We successfully tested your patches on s390, mmap for /proc/vmcore seems to work again. Thanks! Michael On Mon, 14 Oct 2013 18:36:06 +0900 HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote: This patch set fixes regression of mmap on /proc/vmcore since v3.12-rc1. The primary

mmap for /proc/vmcore broken since 3.12-rc1

Hello Alexey, Looks like the following commit broke mmap for /proc/vmcore: commit c4fe24485729fc2cbff324c111e67a1cc2f9adea Author: Alexey Dobriyan Date: Tue Aug 20 22:17:24 2013 +0300 sparc: fix PCI device proc file mmap(2) Because /proc/vmcore (fs/proc/vmcore.c) does not implement the

mmap for /proc/vmcore broken since 3.12-rc1

Hello Alexey, Looks like the following commit broke mmap for /proc/vmcore: commit c4fe24485729fc2cbff324c111e67a1cc2f9adea Author: Alexey Dobriyan adobri...@gmail.com Date: Tue Aug 20 22:17:24 2013 +0300 sparc: fix PCI device proc file mmap(2) Because /proc/vmcore (fs/proc/vmcore.c) does

[PATCH] mm: Fix bootmem error handling in pcpu_page_first_chunk()

] [<00b14814>] setup_per_cpu_areas+0x5c/0x28c Signed-off-by: Michael Holzheu --- mm/percpu.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/percpu.c +++ b/mm/percpu.c @@ -1705,9 +1705,12 @@ int __init pcpu_embed_first_chunk(size_t goto out_free;

[PATCH] mm: Fix bootmem error handling in pcpu_page_first_chunk()

-by: Michael Holzheu holz...@linux.vnet.ibm.com --- mm/percpu.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/percpu.c +++ b/mm/percpu.c @@ -1705,9 +1705,12 @@ int __init pcpu_embed_first_chunk(size_t goto out_free; out_free_areas: - for (group = 0; group

[PATCH v8 0/6] kdump: Allow ELF header creation in new kernel

ory above HSA_SIZE Jan Willeke (1): s390/vmcore: Implement remap_oldmem_pfn_range for s390 Michael Holzheu (5): vmcore: Introduce ELF header in new memory feature s390/vmcore: Use ELF header in new memory feature vmcore: Introduce remap_oldmem_pfn_range() vmcore: Enable /proc/vmcore m

[PATCH v8 1/6] vmcore: Introduce ELF header in new memory feature

by the architecture backend code to read from new memory: * elfcorehdr_alloc: Allocate ELF header * elfcorehdr_free: Free the memory of the ELF header * elfcorehdr_read: Read from ELF header * elfcorehdr_read_notes: Read from ELF notes Signed-off-by: Michael Holzheu Acked-by: Vivek Goyal --- fs

[PATCH v8 4/6] s390/vmcore: Implement remap_oldmem_pfn_range for s390

From: Jan Willeke This patch introduces the s390 specific way to map pages from oldmem. The memory area below OLDMEM_SIZE is mapped with offset OLDMEM_BASE. The other old memory is mapped directly. Signed-off-by: Jan Willeke Signed-off-by: Michael Holzheu --- arch/s390/kernel/crash_dump.c

[PATCH v8 3/6] vmcore: Introduce remap_oldmem_pfn_range()

. This handler works as follows: * Get already available or new page from page cache (find_or_create_page) * Check if /proc/vmcore page is filled with data (PageUptodate) * If yes: Return that page * If no: Fill page using __vmcore_read(), set PageUptodate, and return page Signed-off-by: Michael Holzheu

[PATCH v8 6/6] s390/vmcore: Use vmcore for zfcpdump

This patch modifies the s390 copy_oldmem_page() and remap_oldmem_pfn_range() function for zfcpdump to read from the HSA memory if memory below HSA_SIZE bytes is requested. Otherwise real memory is used. Signed-off-by: Michael Holzheu --- arch/s390/Kconfig | 3 +- arch/s390/include

[PATCH v8 5/6] vmcore: Enable /proc/vmcore mmap for s390

The patch "s390/vmcore: Implement remap_oldmem_pfn_range for s390" allows now to use mmap also on s390. So enable mmap for s390 again. Signed-off-by: Michael Holzheu --- fs/proc/vmcore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/vmcore.c b/fs/pro

[PATCH v8 2/6] s390/vmcore: Use ELF header in new memory feature

This patch now exchanges the old relocate mechanism with the new arch function call override mechanism that allows to create the ELF core header in the 2nd kernel. Signed-off-by: Michael Holzheu --- arch/s390/kernel/crash_dump.c | 81 --- 1 file changed

[PATCH v8 2/6] s390/vmcore: Use ELF header in new memory feature

This patch now exchanges the old relocate mechanism with the new arch function call override mechanism that allows to create the ELF core header in the 2nd kernel. Signed-off-by: Michael Holzheu holz...@linux.vnet.ibm.com --- arch/s390/kernel/crash_dump.c | 81

[PATCH v8 6/6] s390/vmcore: Use vmcore for zfcpdump

This patch modifies the s390 copy_oldmem_page() and remap_oldmem_pfn_range() function for zfcpdump to read from the HSA memory if memory below HSA_SIZE bytes is requested. Otherwise real memory is used. Signed-off-by: Michael Holzheu holz...@linux.vnet.ibm.com --- arch/s390/Kconfig

[PATCH v8 5/6] vmcore: Enable /proc/vmcore mmap for s390

The patch s390/vmcore: Implement remap_oldmem_pfn_range for s390 allows now to use mmap also on s390. So enable mmap for s390 again. Signed-off-by: Michael Holzheu holz...@linux.vnet.ibm.com --- fs/proc/vmcore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc

[PATCH v8 3/6] vmcore: Introduce remap_oldmem_pfn_range()

. This handler works as follows: * Get already available or new page from page cache (find_or_create_page) * Check if /proc/vmcore page is filled with data (PageUptodate) * If yes: Return that page * If no: Fill page using __vmcore_read(), set PageUptodate, and return page Signed-off-by: Michael Holzheu

[PATCH v8 4/6] s390/vmcore: Implement remap_oldmem_pfn_range for s390

From: Jan Willeke will...@de.ibm.com This patch introduces the s390 specific way to map pages from oldmem. The memory area below OLDMEM_SIZE is mapped with offset OLDMEM_BASE. The other old memory is mapped directly. Signed-off-by: Jan Willeke will...@de.ibm.com Signed-off-by: Michael Holzheu

  1   2   3   >