[RFC 1/2] powerpc/fsl-pci: atomic get_user when pagefault_disabled

Whenever we have pagefaults disabled, we have to use the atomic variants of (set|get)_user and copy_(from|to)_user. Signed-off-by: David Hildenbrand d...@linux.vnet.ibm.com --- arch/powerpc/sysdev/fsl_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev

[RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

checks 5. .*_inatomic variants don't call might_fault() 6. If common code uses the __.* variants, it has to trigger access_ok() and call might_fault() 7. For pagefault_disable(), the inatomic variants are to be used Comments? Opinions? David Hildenbrand (2): powerpc/fsl-pci: atomic get_user

[RFC 2/2] mm, sched: trigger might_sleep() in might_fault() when atomic

is to be accessed while pagefault_disabled() is set, the atomic variants of copy_(to|from)_user can be used. This patch reverts commit 662bbcb2747c2422cf98d3d97619509379eee466 taking care of the !MMU optimization. Signed-off-by: David Hildenbrand d...@linux.vnet.ibm.com --- include/linux/kernel.h | 8

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

. On Tue, Nov 25, 2014 at 12:43:24PM +0100, David Hildenbrand wrote: I recently discovered that commit 662bbcb2747c2422cf98d3d97619509379eee466 removed/skipped all might_sleep checks for might_fault() calls when in atomic. Yes. You can add e.g. might_sleep in your code if, for some reason

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

On Wed, Nov 26, 2014 at 05:17:29PM +0200, Michael S. Tsirkin wrote: On Wed, Nov 26, 2014 at 11:05:04AM +0100, David Hildenbrand wrote: What's the path you are trying to debug? Well, we had a problem where we held a spin_lock and called copy_(from|to)_user(). We experienced very

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

This is what happened on our side (very recent kernel): spin_lock(lock) copy_to_user(...) spin_unlock(lock) That's a deadlock even without copy_to_user - it's enough for the thread to be preempted and another one to try taking the lock. 1. s390 locks/unlocks a spin lock with

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

Code like spin_lock(lock); if (copy_to_user(...)) rc = ... spin_unlock(lock); really *should* generate warnings like it did before. And *only* code like spin_lock(lock); Is only code like this valid or also with the spin_lock() dropped? (e.g. the

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote: Code like spin_lock(lock); if (copy_to_user(...)) rc = ... spin_unlock(lock); really *should* generate warnings like it did before. And *only* code like spin_lock(lock); Is only

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

OTOH, there is no reason why we need to disable preemption over that page_fault_disabled() region. There are code pathes which really do not require to disable preemption for that. We have that seperated in preempt-rt for obvious reasons and IIRC Peter Zijlstra tried to distangle it in

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

From: David Hildenbrand ... Although it might not be optimal, but keeping a separate counter for pagefault_disable() as part of the preemption counter seems to be the only doable thing right now. I am not sure if a completely separated counter is even possible, increasing the size

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

From: David Hildenbrand [mailto:d...@linux.vnet.ibm.com] From: David Hildenbrand ... Although it might not be optimal, but keeping a separate counter for pagefault_disable() as part of the preemption counter seems to be the only doable thing right now. I am not sure

[PATCH RFC 1/2] preempt: track pagefault_disable() calls in the preempt counter

atomic context or in pagefault_disable() context. Cleanup the PREEMPT_ACTIVE defines and fix the preempt count documentation on the way. Signed-off-by: David Hildenbrand d...@linux.vnet.ibm.com --- include/linux/preempt_mask.h | 24 +++- include/linux/uaccess.h | 21

[PATCH RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

- Change documentation of user access methods to reflect the real behavior - Don't touch the preempt counter, only the pagefault disable counter (future work) David Hildenbrand (2): preempt: track pagefault_disable() calls in the preempt counter mm, sched: trigger might_sleep() in might_fault

[PATCH RFC 2/2] mm, sched: trigger might_sleep() in might_fault() when pagefaults are disabled

optimization and the new pagefault_disabled() check. Signed-off-by: David Hildenbrand d...@linux.vnet.ibm.com --- include/linux/kernel.h | 9 +++-- mm/memory.c| 15 --- 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/include/linux/kernel.h b/include/linux

Re: [PATCH RFC 2/2] mm, sched: trigger might_sleep() in might_fault() when pagefaults are disabled

- - __might_sleep(__FILE__, __LINE__, 0); + if (unlikely(!pagefault_disabled())) + __might_sleep(__FILE__, __LINE__, 0); Same here: so maybe make might_fault a wrapper around __might_fault as well. Yes, I also noticed that. It was part of the original code. For now

Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

On Thu, 27 Nov 2014, David Hildenbrand wrote: OTOH, there is no reason why we need to disable preemption over that page_fault_disabled() region. There are code pathes which really do not require to disable preemption for that. We have that seperated in preempt-rt for obvious

Re: [RFC,1/2] powerpc/fsl-pci: atomic get_user when pagefault_disabled

On Tue, Nov 25, 2014 at 12:43:25PM +0100, David Hildenbrand wrote: Whenever we have pagefaults disabled, we have to use the atomic variants of (set|get)_user and copy_(from|to)_user. Signed-off-by: David Hildenbrand d...@linux.vnet.ibm.com --- arch/powerpc/sysdev/fsl_pci.c | 2

Re: [PATCH v4 02/12] KVM: define common KVM_GUESTDBG_USE_SW/HW_BP bits

Am 15.05.2015 um 16:27 schrieb Alex Bennée: +++ b/arch/s390/include/uapi/asm/kvm.h @@ -114,8 +114,6 @@ struct kvm_fpu { __u64 fprs[16]; }; -#define KVM_GUESTDBG_USE_HW_BP 0x0001 [...] +++ b/include/uapi/linux/kvm.h [...] +#define KVM_GUESTDBG_USE_SW_BP

Re: [PATCH 1/1] sched: provide common cpu_relax_yield definition

Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> Looks good to me! Reviewed-by: David Hildenbrand <da...@redhat.com> David

Re: [PATCH] fix memory leak on kvm_vm_ioctl_create_spapr_tce

On 22.08.2017 17:15, David Hildenbrand wrote: > On 22.08.2017 16:28, nixiaoming wrote: >> miss kfree(stt) when anon_inode_getfd return fail >> so add check anon_inode_getfd return val, and kfree stt >> >> Signed-off-by: nixiaoming <nixiaom...@huawei.com> >> -

Re: [PATCH] fix memory leak on kvm_vm_ioctl_create_spapr_tce

On 22.08.2017 16:28, nixiaoming wrote: > miss kfree(stt) when anon_inode_getfd return fail > so add check anon_inode_getfd return val, and kfree stt > > Signed-off-by: nixiaoming > --- > arch/powerpc/kvm/book3s_64_vio.c | 5 - > 1 file changed, 4 insertions(+), 1

Re: [PATCH] fix memory leak on kvm_vm_ioctl_create_spapr_tce

>>> + mutex_unlock(>lock); >>> + kvm_put_kvm(kvm); >>> + goto fail; >>> + } >>> + return ret; > > of simply > > if (!ret) if (ret >= 0) return ret; is of course what I meant :) > return 0; > > mutex_lock(>lock); >

Re: [PATCH] fix memory leak on kvm_vm_ioctl_create_spapr_tce

On 23.08.2017 08:06, Paul Mackerras wrote: > On Wed, Aug 23, 2017 at 01:43:08AM +, Nixiaoming wrote: >>> On 22.08.2017 17:15, David Hildenbrand wrote: >>>> On 22.08.2017 16:28, nixiaoming wrote: >>>>> miss kfree(stt) when anon_inode_getfd return fail so a

Re: [PATCH] Revert "KVM: Don't accept obviously wrong gsi values via KVM_IRQFD"

-EINVAL; > > if (args->flags & KVM_IRQFD_FLAG_DEASSIGN) > return kvm_irqfd_deassign(kvm, args); > Makes sense and shouldn't do any harm as you also mentioned. Reviewed-by: David Hildenbrand <da...@redhat.com> -- Thanks, David

Re: [PATCH really v2] KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()

or the iommu > tables. In addition, we have already incremented the process's > count of locked memory pages, and this doesn't get restored on > error. > > David Hildenbrand pointed out that there is a race in that the > function checks early on that there is not already an entry i

[PATCH RFC 0/2] mm: online/offline_pages called w.o. mem_hotplug_lock

natural. Second patch could maybe split up. But let's first hear if this is actually a problem and if there migh be alternatives (or cleanups). Only tested with DIMM-based hotplug. David Hildenbrand (1): mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock Vi

Re: [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

On 17.08.2018 10:41, Greg Kroah-Hartman wrote: > On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote: >> From: Vitaly Kuznetsov >> >> Well require to call add_memory()/add_memory_resource() with >> device_hotplug_lock held, to avoid a lock inversion. All

[PATCH RFC 2/2] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

tly based on a patch by Vitaly Kuznetsov. Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 3 ++ drivers/acpi/acpi_memhotplug.c| 1 + drivers/base/memory.c | 18 +- drivers/hv/hv_balloon.c | 4 +++ drivers/

[PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

patch description] Signed-off-by: David Hildenbrand --- drivers/base/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 04bbcd779e11..9010b9e942b5 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -700,11 +700,13 @@ void

Re: [PATCH RFC 2/2] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

On 17.08.2018 10:20, Rafael J. Wysocki wrote: > On Fri, Aug 17, 2018 at 9:59 AM David Hildenbrand wrote: >> >> There seem to be some problems as result of 30467e0b3be ("mm, hotplug: >> fix concurrent memory hot-add deadlock"), which tried to fix a possible >>

Re: [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

On 17.08.2018 12:06, Greg Kroah-Hartman wrote: > On Fri, Aug 17, 2018 at 11:41:24AM +0200, David Hildenbrand wrote: >> On 17.08.2018 11:03, Rafael J. Wysocki wrote: >>> On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote: >>>> >>>> On 17.08.2018 10:

Re: [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

On 17.08.2018 11:03, Rafael J. Wysocki wrote: > On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote: >> >> On 17.08.2018 10:41, Greg Kroah-Hartman wrote: >>> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote: >>>> From: Vitaly Kuzne

Re: [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

On 17.08.2018 13:28, Heiko Carstens wrote: > On Fri, Aug 17, 2018 at 01:04:58PM +0200, David Hildenbrand wrote: >>>> If there are no objections, I'll go into that direction. But I'll wait >>>> for more comments regarding the general concept first. >>> >

[PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

s a bit. - Try to improve powernv memtrace locking - Add some documentation for locking that matches my knowledge David Hildenbrand (6): mm/memory_hotplug: make remove_memory() take the device_hotplug_lock mm/memory_hotplug: make add_memory() take the device_hotplug_lock mm/memory_hotplug:

[PATCH RFCv2 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

hael Neuling Cc: Balbir Singh Cc: Kate Stewart Cc: Thomas Gleixner Cc: Philippe Ombredanne Cc: Andrew Morton Cc: Michal Hocko Cc: Pavel Tatashin Cc: Vlastimil Babka Cc: Dan Williams Cc: Oscar Salvador Cc: YASUAKI ISHIMATSU Cc: Mathieu Malaterre Signed-off-by: David Hildenbrand -

[PATCH RFCv2 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock

trovsky Cc: Juergen Gross Cc: Nathan Fontenot Cc: John Allen Cc: Andrew Morton Cc: Michal Hocko Cc: Dan Williams Cc: Joonsoo Kim Cc: Vlastimil Babka Cc: Oscar Salvador Cc: Mathieu Malaterre Cc: Pavel Tatashin Cc: YASUAKI ISHIMATSU Signed-off-by: David Hildenbrand --- .../platforms/pser

[PATCH RFCv2 6/6] memory-hotplug.txt: Add some details about locking internals

Let's document the magic a bit, especially why device_hotplug_lock is required when adding/removing memory and how it all play together with requests to online/offline memory from user space. Cc: Jonathan Corbet Cc: Michal Hocko Cc: Andrew Morton Signed-off-by: David Hildenbrand

[PATCH RFCv2 5/6] powerpc/powernv: hold device_hotplug_lock in memtrace_offline_pages()

Let's perform all checking + offlining + removing under device_hotplug_lock, so nobody can mess with these devices via sysfs concurrently. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Signed-off-by: David

[PATCH RFCv2 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

c: YASUAKI ISHIMATSU Cc: Mathieu Malaterre Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 2 -- arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++--- drivers/acpi/acpi_memhotplug.c | 2 +- include/linux/memory_hotplug.h

[PATCH RFCv2 4/6] powerpc/powernv: hold device_hotplug_lock when calling device_online()

device_online() should be called with device_hotplug_lock() held. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 2 ++ 1 file

Re: [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

On 31.08.2018 22:54, Oscar Salvador wrote: > On Tue, Aug 21, 2018 at 12:44:12PM +0200, David Hildenbrand wrote: >> This is the same approach as in the first RFC, but this time without >> exporting device_hotplug_lock (requested by Greg) and with some more >> details and do

Re: [PATCH RFCv2 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

On 30.08.2018 21:35, Pasha Tatashin wrote: >> + >> +void __ref remove_memory(int nid, u64 start, u64 size) > > Remove __ref, otherwise looks good: Indeed, will do. Thanks for the review. Will resend in two weeks when I'm back from vacation. Cheers! > > Reviewed-by: Pavel Tatashin > >> +{

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 04/10/2018 17:28, Michal Suchánek wrote: > On Thu, 4 Oct 2018 10:13:48 +0200 > David Hildenbrand wrote: > > ok, so what is the problem here? > > Handling the hotplug in userspace through udev may be suboptimal and > kernel handling might be faster but that's orth

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 03/10/2018 16:24, Michal Hocko wrote: > On Wed 03-10-18 15:52:24, Vitaly Kuznetsov wrote: > [...] >>> As David said some of the memory cannot be onlined without further steps >>> (e.g. when it is standby as David called it) and then I fail to see how >>> eBPF help in any way. >> >> and also, we

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 03/10/2018 16:34, Vitaly Kuznetsov wrote: > Dave Hansen writes: > >> On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote: >>> It is more than just memmaps (e.g. forking udev process doing memory >>> onlining also needs memory) but yes, the main idea is to make the >>> onlining synchronous with

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 03/10/2018 15:54, Michal Hocko wrote: > On Tue 02-10-18 17:25:19, David Hildenbrand wrote: >> On 02/10/2018 15:47, Michal Hocko wrote: > [...] >>> Zone imbalance is an inherent problem of the highmem zone. It is >>> essentially the highmem zone we all loved so

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 04/10/2018 19:50, Michal Suchánek wrote: > On Thu, 4 Oct 2018 17:45:13 +0200 > David Hildenbrand wrote: > >> On 04/10/2018 17:28, Michal Suchánek wrote: > >>> >>> The state of the art is to determine what to do with hotplugged >>> memory in usersp

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 28/09/2018 19:02, Dave Hansen wrote: > It's really nice if these kinds of things are broken up. First, replace > the old want_memblock parameter, then add the parameter to the > __add_page() calls. Definitely, once we agree that is is not nuts, I will split it up for the next version :) >

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 01/10/2018 10:40, Michal Hocko wrote: > On Fri 28-09-18 17:03:57, David Hildenbrand wrote: > [...] > > I haven't read the patch itself but I just wanted to note one thing > about this part > >> For paravirtualized devices it is relevant that memory is onlined as >

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 02/10/2018 15:47, Michal Hocko wrote: > On Mon 01-10-18 11:34:25, David Hildenbrand wrote: >> On 01/10/2018 10:40, Michal Hocko wrote: >>> On Fri 28-09-18 17:03:57, David Hildenbrand wrote: >>> [...] >>> >>> I haven't read the patch itself but I just

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 01/10/2018 18:24, Dave Hansen wrote: >> How should a policy in user space look like when new memory gets added >> - on s390x? Not onlining paravirtualized memory is very wrong. > > Because we're going to balloon it away in a moment anyway? No, rether somebody wanted this VM to have more

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 04/10/2018 08:19, Michal Hocko wrote: > On Wed 03-10-18 19:14:05, David Hildenbrand wrote: >> On 03/10/2018 16:34, Vitaly Kuznetsov wrote: >>> Dave Hansen writes: >>> >>>> On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote: >>>>> It is more tha

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 04/10/2018 08:28, Michal Hocko wrote: > On Wed 03-10-18 19:00:29, David Hildenbrand wrote: > [...] >> Let me rephrase: You state that user space has to make the decision and >> that user should be able to set/reconfigure rules. That is perfectly fine. >> >> But

Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 03/10/2018 16:24, Michal Hocko wrote: > On Wed 03-10-18 15:52:24, Vitaly Kuznetsov wrote: > [...] >>> As David said some of the memory cannot be onlined without further steps >>> (e.g. when it is standby as David called it) and then I fail to see how >>> eBPF help in any way. >> >> and also, we

Re: [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

On 21.08.2018 12:44, David Hildenbrand wrote: > This is the same approach as in the first RFC, but this time without > exporting device_hotplug_lock (requested by Greg) and with some more > details and documentation regarding locking. Tested only on x86 so far. > I'll be on vaca

Re: [PATCH v2 5/6] powerpc/powernv: hold device_hotplug_lock when calling memtrace_offline_pages()

On 25/09/2018 14:15, Balbir Singh wrote: > On Tue, Sep 25, 2018 at 11:14:56AM +0200, David Hildenbrand wrote: >> Let's perform all checking + offlining + removing under >> device_hotplug_lock, so nobody can mess with these devices via >> sysfs concurrently. >> >>

[PATCH v2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

d_memory wrappers. - Split up the patches a bit. - Try to improve powernv memtrace locking - Add some documentation for locking that matches my knowledge David Hildenbrand (6): mm/memory_hotplug: make remove_memory() take the device_hotplug_lock mm/memory_hotplug: make add_memory() take the device_h

[PATCH v2 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

: Rashmica Gupta Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 2 +- arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++--- drivers/acpi/acpi_memhotplug.c | 2 +- include/linux/memory_hotplug.h | 3 ++- mm/memory

[PATCH v2 6/6] memory-hotplug.txt: Add some details about locking internals

-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- Documentation/memory-hotplug.txt | 42 +++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 7f49ebf3ddb2..ce4faa5530fa 100644

[PATCH v2 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock

J. Wysocki Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- .../platforms/pseries/hotplug-memory.c| 2 +- drivers/acpi/acpi_memhotplug.c| 2 +- drivers/base/memory.c | 9 ++-- drivers/xen/balloon.c |

[PATCH v2 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

n Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 13 + mm/memory_hotplug.c | 28 2 files changed, 21 insertions(+), 20 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 40c

[PATCH v2 4/6] powerpc/powernv: hold device_hotplug_lock when calling device_online()

device_online() should be called with device_hotplug_lock() held. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Reviewed-by: Pavel Tatashin Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- arch

[PATCH v2 5/6] powerpc/powernv: hold device_hotplug_lock when calling memtrace_offline_pages()

Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c index fdd48f1a39f7..d84d09c56af9

[PATCH v3 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

ve_memory() in patch #1 - Minor patch description fixes. - Added rb's RFC -> RFCv2: - Don't export device_hotplug_lock, provide proper remove_memory/add_memory wrappers. - Split up the patches a bit. - Try to improve powernv memtrace locking - Add some documentation for locking that matches my kno

[PATCH v3 4/6] powerpc/powernv: hold device_hotplug_lock when calling device_online()

device_online() should be called with device_hotplug_lock() held. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Reviewed-by: Pavel Tatashin Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- arch

[PATCH v3 5/6] powerpc/powernv: hold device_hotplug_lock when calling memtrace_offline_pages()

Reviewed-by: Rashmica Gupta Acked-by: Balbir Singh Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c index

[PATCH v3 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

: Rashmica Gupta Signed-off-by: David Hildenbrand --- arch/powerpc/platforms/powernv/memtrace.c | 2 +- arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++--- drivers/acpi/acpi_memhotplug.c | 2 +- include/linux/memory_hotplug.h | 3 ++- mm/memory

[PATCH v3 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

n Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 13 + mm/memory_hotplug.c | 28 2 files changed, 21 insertions(+), 20 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 40c

[PATCH v3 6/6] memory-hotplug.txt: Add some details about locking internals

-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- Documentation/memory-hotplug.txt | 42 +++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 7f49ebf3ddb2..ce4faa5530fa 100644

[PATCH v3 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock

J. Wysocki Reviewed-by: Rashmica Gupta Signed-off-by: David Hildenbrand --- .../platforms/pseries/hotplug-memory.c| 2 +- drivers/acpi/acpi_memhotplug.c| 2 +- drivers/base/memory.c | 9 ++-- drivers/xen/balloon.c |

[PATCH RFC] mm/memory_hotplug: Introduce memory block types

Kroah-Hartman Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Boris Ostrovsky Cc: Juergen Gross Cc: "Jérôme Glisse" Cc: Andrew Morton Cc: Mike Rapoport Cc: Dan Williams Cc: Stephen Rothwell Cc: Michal Hocko Cc: "Kirill A. Shutemov" Cc: David

Re: [PATCH v2 0/9] mm: PG_reserved cleanups and documentation

On 15.01.19 16:38, Christoph Hellwig wrote: > On Mon, Jan 14, 2019 at 01:58:54PM +0100, David Hildenbrand wrote: >> Nothing major changed since the last version. I would be happy about >> additional ACKs. If there are no further comments, can this go via the >> mm-tree

Re: [PATCH v2 0/9] mm: PG_reserved cleanups and documentation

On 14.01.19 13:58, David Hildenbrand wrote: > Nothing major changed since the last version. I would be happy about > additional ACKs. If there are no further comments, can this go via the > mm-tree in one chunk? For the time being, I will not add further patches to this series (as

Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types

On 20.12.18 14:08, Michal Hocko wrote: > On Thu 20-12-18 13:58:16, David Hildenbrand wrote: >> On 30.11.18 18:59, David Hildenbrand wrote: >>> This is the second approach, introducing more meaningful memory block >>> types and not changing online behavior in the kernel

Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types

On 30.11.18 18:59, David Hildenbrand wrote: > This is the second approach, introducing more meaningful memory block > types and not changing online behavior in the kernel. It is based on > latest linux-next. > > As we found out during dicussion, user space should always

Re: [PATCH v1 9/9] mm: better document PG_reserved

On 15.12.18 01:12, Randy Dunlap wrote: > On 12/14/18 3:10 AM, David Hildenbrand wrote: >> The usage of PG_reserved and how PG_reserved pages are to be treated is >> buried deep down in different parts of the kernel. Let's shine some light >> onto these details by docu

[PATCH v1 0/9] mm: PG_reserved cleanups and documentation

crashkernel pages manually PG_reserved" - Add "ia64: perfmon: Don't mark buffer pages as PG_reserved" - Added ACKs David Hildenbrand (9): agp: efficeon: no need to set PG_reserved on GATT tables s390/vdso: don't clear PG_reserved powerpc/vdso: don't clear PG_reserved ri

[PATCH v1 6/9] arm64: kexec: no need to ClearPageReserved()

This will be done by free_reserved_page(). Cc: Catalin Marinas Cc: Will Deacon Cc: Bhupesh Sharma Cc: James Morse Cc: Marc Zyngier Cc: Dave Kleikamp Cc: Mark Rutland Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Acked-by: James Morse Signed-off-by: David Hildenbrand --- arch

[PATCH v1 9/9] mm: better document PG_reserved

tashin Cc: Michal Hocko Cc: Alexander Duyck Cc: Matthew Wilcox Cc: Anthony Yznaga Cc: Miles Chen Cc: yi.z.zh...@linux.intel.com Cc: Dan Williams Signed-off-by: David Hildenbrand --- include/linux/page-flags.h | 33 +++-- 1 file changed, 31 insertions(+), 2

[PATCH v1 2/9] s390/vdso: don't clear PG_reserved

Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Matthew Wilcox Cc: Mike Rapoport Cc: Michal Hocko Cc: Vasily Gorbik Cc: Kees Cook Cc: Souptick Joarder Cc: Andrew Morton Cc: Michal Hocko Signed-off-by: David Hildenbrand --- arch/s390/kernel/vdso.c | 2 -- 1 file changed, 2 deletions

[PATCH v1 5/9] m68k/mm: use __ClearPageReserved()

The PG_reserved flag is cleared from memory that is part of the kernel image (and therefore marked as PG_reserved). Avoid using PG_reserved directly. Cc: Geert Uytterhoeven Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/m68k/mm/memory.c | 2

[PATCH v1 1/9] agp: efficeon: no need to set PG_reserved on GATT tables

from that, these pages are not exposed or ioremap'ed. We can stop setting them reserved (propably copied from generic code). Cc: David Airlie Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- drivers/char/agp

[PATCH v1 4/9] riscv/vdso: don't clear PG_reserved

Cc: Tobias Klauser Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Acked-by: Palmer Dabbelt Signed-off-by: David Hildenbrand --- arch/riscv/kernel/vdso.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c index 582cb153eb24

[PATCH v1 8/9] ia64: perfmon: Don't mark buffer pages as PG_reserved

()/vfree() instead. Note that before calling vzalloc(), size has already been aligned to PAGE_SIZE, no need to align again. Cc: Tony Luck Cc: Fenghua Yu Cc: Oleg Nesterov Cc: Andrew Morton Cc: David Hildenbrand Cc: David Howells Cc: Mike Rapoport Cc: Michal Hocko Signed-off-by: David Hildenbrand

[PATCH v1 3/9] powerpc/vdso: don't clear PG_reserved

: Paul Mackerras Cc: Michael Ellerman Cc: Christophe Leroy Cc: Kees Cook Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/powerpc/kernel/vdso.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel

[PATCH v1 7/9] arm64: kdump: No need to mark crashkernel pages manually PG_reserved

they would have been handed over to the buddy as free pages and bad things would happen). Cc: Catalin Marinas Cc: Will Deacon Cc: James Morse Cc: Bhupesh Sharma Cc: David Hildenbrand Cc: Mark Rutland Cc: Dave Kleikamp Cc: Andrew Morton Cc: Mike Rapoport Cc: Michal Hocko Cc: Florian

[PATCH RFCv2 2/4] mm/memory_hotplug: Replace "bool want_memblock" by "int type"

b Herring Cc: Pavel Tatashin Cc: "mike.tra...@hpe.com" Cc: Joonsoo Kim Cc: Wei Yang Cc: Logan Gunthorpe Cc: "Jérôme Glisse" Cc: "Jan H. Schönherr" Cc: Dave Jiang Cc: Matthew Wilcox Cc: Mathieu Malaterre Signed-off-by: David Hildenbrand --- arch/ia64/mm/

[PATCH RFCv2 1/4] mm/memory_hotplug: Introduce memory block types

c: Heiko Carstens Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 38 +++--- include/linux/memory.h | 27 +++ 2 files changed, 62 insertions(+), 3 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 0c29

[PATCH RFCv2 4/4] mm/memory_hotplug: Drop MEMORY_TYPE_UNSPECIFIED

Cc: Michal Hocko Cc: Michal Suchánek Cc: Vitaly Kuznetsov Cc: Dan Williams Cc: Pavel Tatashin Signed-off-by: David Hildenbrand --- drivers/base/memory.c | 3 --- include/linux/memory.h | 5 - 2 files changed, 8 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.

[PATCH RFCv2 3/4] mm/memory_hotplug: Introduce and use more memory types

athan Fontenot Cc: YueHaibing Cc: Vasily Gorbik Cc: Ingo Molnar Cc: Stephen Rothwell Cc: "mike.tra...@hpe.com" Cc: Oscar Salvador Cc: Joonsoo Kim Cc: Mathieu Malaterre Cc: Michal Hocko Cc: Arun KS Cc: Andrew Banman Cc: Dave Hansen Cc: Michal Suchánek Cc: Vitaly Kuznetsov

Re: [PATCH RFCv2 3/4] mm/memory_hotplug: Introduce and use more memory types

On 04.12.18 10:44, Michal Suchánek wrote: > On Fri, 30 Nov 2018 18:59:21 +0100 > David Hildenbrand wrote: > >> Let's introduce new types for different kinds of memory blocks and use >> them in existing code. As I don't see an easy way to split this up, >> do it in o

[PATCH RFC 2/7] s390/vdso: don't clear PG_reserved

Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Matthew Wilcox Cc: Mike Rapoport Cc: Michal Hocko Cc: Vasily Gorbik Cc: Kees Cook Cc: Souptick Joarder Cc: Andrew Morton Cc: Michal Hocko Signed-off-by: David Hildenbrand --- arch/s390/kernel/vdso.c | 2 -- 1 file changed, 2 deletions

[PATCH RFC 1/7] agp: efficeon: no need to set PG_reserved on GATT tables

from that, these pages are not exposed or ioremap'ed. We can stop setting them reserved (propably copied from generic code). Cc: David Airlie Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- drivers/char/agp

[PATCH RFC 5/7] m68k/mm: use __ClearPageReserved()

The PG_reserved flag is cleared from memory that is part of the kernel image (and therefore marked as PG_reserved). Avoid using PG_reserved directly. Cc: Geert Uytterhoeven Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/m68k/mm/memory.c | 2

[PATCH RFC 0/7] mm: PG_reserved cleanups and documentation

, for device memory we can hopefully soon stop setting it PG_reserved I only briefly tested this on s390x. David Hildenbrand (7): agp: efficeon: no need to set PG_reserved on GATT tables s390/vdso: don't clear PG_reserved powerpc/vdso: don't clear PG_reserved riscv/vdso: don't clear PG_reserved

[PATCH RFC 3/7] powerpc/vdso: don't clear PG_reserved

: Paul Mackerras Cc: Michael Ellerman Cc: Christophe Leroy Cc: Kees Cook Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/powerpc/kernel/vdso.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel

[PATCH RFC 7/7] mm: better document PG_reserved

Cc: Michal Hocko Cc: Alexander Duyck Cc: Matthew Wilcox Cc: Anthony Yznaga Cc: Miles Chen Cc: yi.z.zh...@linux.intel.com Cc: Dan Williams Signed-off-by: David Hildenbrand --- include/linux/page-flags.h | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/inc

Re: [PATCH RFC 0/7] mm: PG_reserved cleanups and documentation

On 05.12.18 13:56, Michal Hocko wrote: > On Wed 05-12-18 13:28:44, David Hildenbrand wrote: > [...] >> Most notably, for device memory we can hopefully soon stop setting >> it PG_reserved > > I am busy as hell so I am not likely to look at specific patche this >

[PATCH RFC 6/7] arm64: kexec: no need to ClearPageReserved()

This will already be done by free_reserved_page(). Cc: Catalin Marinas Cc: Will Deacon Cc: Bhupesh Sharma Cc: James Morse Cc: Marc Zyngier Cc: Dave Kleikamp Cc: Mark Rutland Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/arm64/kernel

[PATCH RFC 4/7] riscv/vdso: don't clear PG_reserved

Cc: Tobias Klauser Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/riscv/kernel/vdso.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c index 582cb153eb24..0cd044122234 100644 --- a/arch

  1   2   3   4   5   6   7   8   9   10   >