Re: [PATCH] cpufreq: powernv: Use node ID in init_chip_info

+ few IBM guys who have been working on this. On 19-10-16, 15:02, Emily Shaffer wrote: > Fixed assumption that node_id==chip_id in powernv-cpufreq.c:init_chip_info; > explicitly use node ID where necessary. > > Tested: All CPUs report in /sys/devices/system/cpu*/cpufreq/throttle_stats > >

[PATCH] KVM: PPC: Book3S HV: Fix build error when SMP=n

Commit 5d375199ea96 ("KVM: PPC: Book3S HV: Set server for passed-through interrupts") broke the SMP=n build: arch/powerpc/kvm/book3s_hv_rm_xics.c:758:2: error: implicit declaration of function 'get_hard_smp_processor_id' That is because we lost the implicit include of asm/smp.h, so include it

Re: [PATCH 6/7] powerpc: switch to using thin archives if COMPILE_TEST is set

On Wed, 19 Oct 2016 22:00:06 +1100 Michael Ellerman wrote: > Nicholas Piggin writes: > > > Enable thin archives build for powerpc when COMPILE_TEST is set. > > Thin archives are explained in this commit: > > > > a5967db9af51a84f5e181600954714a9e4c69f1f

Re: [PATCH v4 3/5] powerpc/mm: allow memory hotplug into a memoryless node

On 07/10/16 05:36, Reza Arbab wrote: > Remove the check which prevents us from hotplugging into an empty node. > > This limitation has been questioned before [1], and judging by the > response, there doesn't seem to be a reason we can't remove it. No issues > have been found in light testing. >

[PATCH kernel v3 3/4] vfio/spapr: Cache mm in tce_container

In some situations the userspace memory context may live longer than the userspace process itself so if we need to do proper memory context cleanup, we better cache @mm and use it later when the process is gone (@current or @current->mm is NULL). This references mm and stores the pointer in the

[PATCH kernel v3 2/4] powerpc/iommu: Stop using @current in mm_iommu_xxx

This changes mm_iommu_xxx helpers to take mm_struct as a parameter instead of getting it from @current which in some situations may not have a valid reference to mm. This changes helpers to receive @mm and moves all references to @current to the caller, including checks for !current and

[PATCH kernel v3 1/4] powerpc/iommu: Pass mm_struct to init/cleanup helpers

We are going to get rid of @current references in mmu_context_boos3s64.c and cache mm_struct in the VFIO container. Since mm_context_t does not have reference counting, we will be using mm_struct which does have the reference counter. This changes mm_iommu_init/mm_iommu_cleanup to receive

[PATCH kernel v3 4/4] powerpc/mm/iommu, vfio/spapr: Put pages on VFIO container shutdown

At the moment the userspace tool is expected to request pinning of the entire guest RAM when VFIO IOMMU SPAPR v2 driver is present. When the userspace process finishes, all the pinned pages need to be put; this is done as a part of the userspace memory context (MM) destruction which happens on the

[PATCH kernel v3 0/4] powerpc/spapr/vfio: Put pages on VFIO container shutdown

These patches are to fix a bug when pages stay pinned hours after QEMU which requested pinning exited. This time 4 patches for easier reviewing. Please comment. Thanks. Alexey Kardashevskiy (4): powerpc/iommu: Pass mm_struct to init/cleanup helpers powerpc/iommu: Stop using @current in

[PATCH] cpufreq: powernv: Use node ID in init_chip_info

Fixed assumption that node_id==chip_id in powernv-cpufreq.c:init_chip_info; explicitly use node ID where necessary. Tested: All CPUs report in /sys/devices/system/cpu*/cpufreq/throttle_stats Effort: platforms/arch-powerpc Google-Bug-Id: 26979978 Signed-off-by: Emily Shaffer

Re: [PATCH v4 5/5] x86, kvm: support vcpu preempted check

在 2016/10/20 01:24, Radim Krčmář 写道: 2016-10-19 06:20-0400, Pan Xinhui: This is to fix some lock holder preemption issues. Some other locks implementation do a spin loop before acquiring the lock itself. Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It takes the cpu as

Re: [PATCH v4 5/5] x86, kvm: support vcpu preempted check

2016-10-19 06:20-0400, Pan Xinhui: > This is to fix some lock holder preemption issues. Some other locks > implementation do a spin loop before acquiring the lock itself. > Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It > takes the cpu as parameter and return true if the

Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On 10/19/2016 10:01 AM, Michal Hocko wrote: > The question I had earlier was whether this has to be an explicit FOLL > flag used by g-u-p users or we can just use it internally when mm != > current->mm The reason I chose not to do that was that deferred work gets run under a basically random

Re: [PATCH v4 0/5] implement vcpu preempted check

在 2016/10/19 23:58, Juergen Gross 写道: On 19/10/16 12:20, Pan Xinhui wrote: change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip

Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On Wed 19-10-16 09:49:43, Dave Hansen wrote: > On 10/19/2016 02:07 AM, Michal Hocko wrote: > > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: > >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > >>> I am wondering whether we can go further. E.g. it is not really clear to > >>> me

Re: [PATCH v4 0/5] implement vcpu preempted check

在 2016/10/19 14:47, Christian Borntraeger 写道: On 10/19/2016 12:20 PM, Pan Xinhui wrote: change from v3: add x86 vcpu preempted check patch If you want you could add the s390 patch that I provided for your last version. I also gave my Acked-by for all previous patches. hi,

Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On 10/19/2016 02:07 AM, Michal Hocko wrote: > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: >>> I am wondering whether we can go further. E.g. it is not really clear to >>> me whether we need an explicit FOLL_REMOTE when we can in

[PATCH wq/for-4.10] workqueue: move wq_numa_init() to workqueue_init()

Hello, Michael. I simplified the patch a bit and applied the following to for-4.10 and updated for-next accordingly. The coming next snapshot should be fine. Thanks! -- 8< -- >From 2186d9f940b6a04f263a3bacd48f2a7ba96df4cf Mon Sep 17 00:00:00 2001 From: Tejun Heo Date:

Re: [PATCH v4 0/5] implement vcpu preempted check

On 19/10/16 12:20, Pan Xinhui wrote: > change from v3: > add x86 vcpu preempted check patch > change from v2: > no code change, fix typos, update some comments > change from v1: > a simplier definition of default vcpu_is_preempted > skip mahcine type check on ppc, and add

RE: [RFC PATCH 2/3] powerpc/pseries: Define & use a type for the plpar_hcall() retvals

From: Balbir Singh > Sent: 19 October 2016 15:00 ... > Here is an example > > - *slot = retbuf[0]; > + *slot = retvals.v[0]; > > Could we hide retvals.v[0] under a macro like > > *slot = hcalls_ret_val(retvals, 0); Ugg.. > Since we could end up with similar issues if > someone

Re: [PATCH] net: fs_enet: Use net_device_stats from struct net_device

From: Tobias Klauser Date: Wed, 19 Oct 2016 11:24:57 +0200 > Instead of using a private copy of struct net_device_stats in struct > fs_enet_private, use stats from struct net_device. Also remove the now > unnecessary .ndo_get_stats function. > > Signed-off-by: Tobias

Re: [RFC PATCH 2/3] powerpc/pseries: Define & use a type for the plpar_hcall() retvals

On 19/10/16 22:47, Michael Ellerman wrote: > Balbir Singh writes: > >> On 18/10/16 19:40, Michael Ellerman wrote: >>> We have now had two nasty stack corruption bugs caused by incorrect >>> sizing of the return buffer for plpar_hcall()/plpar_hcall9(). >>> >>> To avoid

RE: [PATCH] powerpc: link error on orphan sections

From: Michael Ellerman [mailto:m...@ellerman.id.au] > > In the past I've caused orphan sections to error by assigning them > > to the same address as something that exists. > > Works with all linkers, even if the error message isn't as useful. > > How do you assign them an address without knowing

Re: [PATCH v2] powerpc/hash64: Be more careful when generating tlbiel

Michael Ellerman writes: > From: Balbir Singh ... > > Although there may be very old toolchains which don't understand tlbiel, we > have > other code in the tree which has been using tlbiel for over five years, and no > one has reported any build

RE: [PATCH] powerpc: link error on orphan sections

David Laight writes: > From: Michael Ellerman >> Sent: 14 October 2016 01:46 > ... >> > +LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y) --orphan-handling=error >> >> At least some old(er) toolchains don't support that: >> >>

Re: [Patch v5 06/12] powerpc/virtex: Use generic xilinx irqchip driver

Zubair Lutfullah Kakakhel writes: > The Xilinx interrupt controller driver is now available in drivers/irqchip. > Switch to using that driver. > > Signed-off-by: Zubair Lutfullah Kakakhel > > --- > V5 New patch > > Tested on

Re: [RFC PATCH 2/3] powerpc/pseries: Define & use a type for the plpar_hcall() retvals

Balbir Singh writes: > On 18/10/16 19:40, Michael Ellerman wrote: >> We have now had two nasty stack corruption bugs caused by incorrect >> sizing of the return buffer for plpar_hcall()/plpar_hcall9(). >> >> To avoid any more such bugs, define a type which encodes the

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Tejun Heo writes: > Hello, Michael. > > On Tue, Oct 18, 2016 at 03:37:42PM +1100, Michael Ellerman wrote: >> That doesn't compile, wq doesn't exist. >> >> I guessed that you meant: >> >> + wq_numa_init(); >> + list_for_each_entry(wq, , list) >> +

Re: [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

Lorenzo Stoakes writes: > diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c > index f52b7db3..010b7b3 100644 > --- a/arch/powerpc/kernel/ptrace32.c > +++ b/arch/powerpc/kernel/ptrace32.c > @@ -74,7 +74,7 @@ long compat_arch_ptrace(struct task_struct

Re: [PATCH 6/7] powerpc: switch to using thin archives if COMPILE_TEST is set

Nicholas Piggin writes: > Enable thin archives build for powerpc when COMPILE_TEST is set. > Thin archives are explained in this commit: > > a5967db9af51a84f5e181600954714a9e4c69f1f > > This is a gradual way to introduce the option to testers. I think I'd rather this was

Re: [PATCH 3/7] powerpc/64s: tool to flag direct branches from unrelocated interrupt vectors

Nicholas Piggin writes: > Direct banches from code below __end_interrupts to code above > __end_interrupts when built with CONFIG_RELOCATABLE are disallowed > because they will break when the kernel is not located at 0. > > Sample output: > > WARNING: Unrelocated relative

[PATCH] net: fs_enet: Use net_device_stats from struct net_device

Instead of using a private copy of struct net_device_stats in struct fs_enet_private, use stats from struct net_device. Also remove the now unnecessary .ndo_get_stats function. Signed-off-by: Tobias Klauser --- .../net/ethernet/freescale/fs_enet/fs_enet-main.c | 43

Re: [PATCH 6/7] powerpc: switch to using thin archives if COMPILE_TEST is set

On Wed, 19 Oct 2016 16:57:23 +1100 Stephen Rothwell wrote: > Hi Nick, > > On Wed, 19 Oct 2016 14:15:59 +1100 Nicholas Piggin wrote: > > > > Enable thin archives build for powerpc when COMPILE_TEST is set. > > Thin archives are explained in this commit:

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

On Wed 19-10-16 10:06:46, Lorenzo Stoakes wrote: > On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote: > > yes this is the desirable and expected behavior. > > > > > wonder if this is desirable behaviour or whether this ought to be limited > > > to > > > ptrace system calls. Regardless,

Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: > On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > > I am wondering whether we can go further. E.g. it is not really clear to > > me whether we need an explicit FOLL_REMOTE when we can in fact check > > mm != current->mm and imply

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote: > yes this is the desirable and expected behavior. > > > wonder if this is desirable behaviour or whether this ought to be limited to > > ptrace system calls. Regardless, by making the flag more visible it makes it > > easier to see

Re: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > I am wondering whether we can go further. E.g. it is not really clear to > me whether we need an explicit FOLL_REMOTE when we can in fact check > mm != current->mm and imply that. Maybe there are some contexts which > wouldn't work, I

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

On Wed 19-10-16 09:40:45, Lorenzo Stoakes wrote: > On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote: > > On Wed 19-10-16 09:59:03, Jan Kara wrote: > > > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote: > > > > This patch removes the write parameter from __access_remote_vm() and > > >

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote: > On Wed 19-10-16 09:59:03, Jan Kara wrote: > > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote: > > > This patch removes the write parameter from __access_remote_vm() and > > > replaces it > > > with a gup_flags parameter as use of

Re: [v12, 0/8] Fix eSDHC host version register bug

On Wed, Oct 19, 2016 at 02:47:07AM +, Y.B. Lu wrote: > + Greg > > Hi Greg, > > I submitted this patchset for a MMC bug fix, and introduce the below patch > which needs your ACK. > > > Arnd Bergmann (1): > > > base: soc: introduce soc_device_match() interface >

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

On Wed 19-10-16 09:59:03, Jan Kara wrote: > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote: > > This patch removes the write parameter from __access_remote_vm() and > > replaces it > > with a gup_flags parameter as use of this function previously _implied_ > > FOLL_FORCE, whereas after this

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote: > This patch removes the write parameter from __access_remote_vm() and replaces > it > with a gup_flags parameter as use of this function previously _implied_ > FOLL_FORCE, whereas after this patch callers explicitly pass this flag. > > We make

Re: [PATCH 07/10] mm: replace get_user_pages_remote() write/force parameters with gup_flags

On Thu 13-10-16 01:20:17, Lorenzo Stoakes wrote: > This patch removes the write and force parameters from get_user_pages_remote() > and replaces them with a gup_flags parameter to make the use of FOLL_FORCE > explicit in callers as use of this flag can result in surprising behaviour > (and >

Re: [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

On Thu 13-10-16 01:20:16, Lorenzo Stoakes wrote: > This patch removes the write and force parameters from get_user_pages() and > replaces them with a gup_flags parameter to make the use of FOLL_FORCE > explicit > in callers as use of this flag can result in surprising behaviour (and hence > bugs)

Re: [PATCH 0/7] build updates

On Wed, 19 Oct 2016 14:15:53 +1100 Nicholas Piggin wrote: > [*] Building allyesconfig still requires KALLSYMS_EXTRA_PASS=1, which > I'm yet to look into. Oh, it's because the kallsyms payload increases kernel image size and that causes more linker stubs to be generated,

Re: [PATCH 05/10] mm: replace get_vaddr_frames() write/force parameters with gup_flags

On Thu 13-10-16 01:20:15, Lorenzo Stoakes wrote: > This patch removes the write and force parameters from get_vaddr_frames() and > replaces them with a gup_flags parameter to make the use of FOLL_FORCE > explicit > in callers as use of this flag can result in surprising behaviour (and hence >

Re: [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

On Thu 13-10-16 01:20:14, Lorenzo Stoakes wrote: > This patch removes the write and force parameters from get_user_pages_locked() > and replaces them with a gup_flags parameter to make the use of FOLL_FORCE > explicit in callers as use of this flag can result in surprising behaviour > (and >

Re: [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

On Tue 18-10-16 14:56:09, Lorenzo Stoakes wrote: > On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote: > > > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned > > > long nr_pages, > > > int write, int force, struct page **pages, > > >

Re: [PATCH v4 0/5] implement vcpu preempted check

On 10/19/2016 12:20 PM, Pan Xinhui wrote: > change from v3: > add x86 vcpu preempted check patch If you want you could add the s390 patch that I provided for your last version. I also gave my Acked-by for all previous patches. > change from v2: > no code change, fix typos, update

[PATCH v4 5/5] x86, kvm: support vcpu preempted check

This is to fix some lock holder preemption issues. Some other locks implementation do a spin loop before acquiring the lock itself. Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It takes the cpu as parameter and return true if the cpu is preempted. Then kernel can break

[PATCH v4 4/5] powerpc/spinlock: support vcpu preempted check

This is to fix some lock holder preemption issues. Some other locks implementation do a spin loop before acquiring the lock itself. Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It takes the cpu as parameter and return true if the cpu is preempted. Then kernel can break the

[PATCH v4 3/5] kernel/locking: Drop the overload of {mutex, rwsem}_spin_on_owner

An over-committed guest with more vCPUs than pCPUs has a heavy overload in the two spin_on_owner. This blames on the lock holder preemption issue. Kernel has an interface bool vcpu_is_preempted(int cpu) to see if a vCPU is currently running or not. So break the spin loops on true condition.

[PATCH v4 2/5] locking/osq: Drop the overload of osq_lock()

An over-committed guest with more vCPUs than pCPUs has a heavy overload in osq_lock(). This is because vCPU A hold the osq lock and yield out, vCPU B wait per_cpu node->locked to be set. IOW, vCPU B wait vCPU A to run and unlock the osq lock. Kernel has an interface bool vcpu_is_preempted(int

[PATCH v4 0/5] implement vcpu preempted check

change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc, and add config. remove dedicated macro. add

[PATCH v4 1/5] kernel/sched: introduce vcpu preempted check interface

This patch support to fix lock holder preemption issue. For kernel users, we could use bool vcpu_is_preempted(int cpu) to detech if one vcpu is preempted or not. The default implementation is a macro defined by false. So compiler can wrap it out if arch dose not support such vcpu pteempted

Re: [PATCH 3/7] powerpc/64s: tool to flag direct branches from unrelocated interrupt vectors

On Wed, 19 Oct 2016 15:28:40 +1100 Balbir Singh wrote: > On 19/10/16 14:15, Nicholas Piggin wrote: > > Direct banches from code below __end_interrupts to code above > > __end_interrupts when built with CONFIG_RELOCATABLE are disallowed > > because they will break when the