[PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

[PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

[PATCH V9 2/2] powerpc/nodes: Ensure enough nodes avail for operations

To: linuxppc-...@lists.ozlabs.org From: Michael Bringmann To: linux-kernel@vger.kernel.org Cc: Michael Ellerman Cc: Michael Bringmann Cc: John Allen Cc: Nathan Fontenot

[PATCH V9 2/2] powerpc/nodes: Ensure enough nodes avail for operations

To: linuxppc-...@lists.ozlabs.org From: Michael Bringmann To: linux-kernel@vger.kernel.org Cc: Michael Ellerman Cc: Michael Bringmann Cc: John Allen Cc: Nathan Fontenot Subject: [PATCH V9 2/2] powerpc/nodes: Ensure enough nodes avail for operations powerpc/nodes: On systems like PowerPC

[PATCH V9 0/2] powerpc/dlpar: Correct display of hot-add/hot-remove CPUs and memory

On Power systems with shared configurations of CPUs and memory, there are some issues with association of additional CPUs and memory to nodes when hot-adding resources. These patches address some of those problems. powerpc/numa: Correct the currently broken capability to set the topology for

[PATCH V9 0/2] powerpc/dlpar: Correct display of hot-add/hot-remove CPUs and memory

On Power systems with shared configurations of CPUs and memory, there are some issues with association of additional CPUs and memory to nodes when hot-adding resources. These patches address some of those problems. powerpc/numa: Correct the currently broken capability to set the topology for

Re: [patch] fs, proc: unconditional cond_resched when reading smaps

On Mon, Aug 21, 2017 at 02:06:45PM -0700, David Rientjes wrote: > If there are large numbers of hugepages to iterate while reading > /proc/pid/smaps, the page walk never does cond_resched(). On archs > without split pmd locks, there can be significant and observable > contention on

Re: [patch] fs, proc: unconditional cond_resched when reading smaps

On Mon, Aug 21, 2017 at 02:06:45PM -0700, David Rientjes wrote: > If there are large numbers of hugepages to iterate while reading > /proc/pid/smaps, the page walk never does cond_resched(). On archs > without split pmd locks, there can be significant and observable > contention on

Re: [PATCH] mt7601u: check memory allocation failure

On Mon, 21 Aug 2017 14:34:30 -0700, Jakub Kicinski wrote: > On Mon, 21 Aug 2017 22:59:56 +0200, Christophe JAILLET wrote: > > Check memory allocation failure and return -ENOMEM in such a case, as > > already done a few lines below > > > > Signed-off-by: Christophe JAILLET

Re: [PATCH] mt7601u: check memory allocation failure

On Mon, 21 Aug 2017 14:34:30 -0700, Jakub Kicinski wrote: > On Mon, 21 Aug 2017 22:59:56 +0200, Christophe JAILLET wrote: > > Check memory allocation failure and return -ENOMEM in such a case, as > > already done a few lines below > > > > Signed-off-by: Christophe JAILLET > > Acked-by: Jakub

Re: [PATCH] mt7601u: check memory allocation failure

On Mon, 21 Aug 2017 22:59:56 +0200, Christophe JAILLET wrote: > Check memory allocation failure and return -ENOMEM in such a case, as > already done a few lines below > > Signed-off-by: Christophe JAILLET Acked-by: Jakub Kicinski Thanks!

Re: [PATCH] mt7601u: check memory allocation failure

On Mon, 21 Aug 2017 22:59:56 +0200, Christophe JAILLET wrote: > Check memory allocation failure and return -ENOMEM in such a case, as > already done a few lines below > > Signed-off-by: Christophe JAILLET Acked-by: Jakub Kicinski Thanks!

Re: [PATCH v2] mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour

On 08/21/2017 11:07 AM, Catalin Marinas wrote: > On Fri, Aug 18, 2017 at 02:29:18PM -0700, Mike Kravetz wrote: >> On 08/18/2017 07:54 AM, Punit Agrawal wrote: >>> When walking the page tables to resolve an address that points to >>> !p*d_present() entry, huge_pte_offset() returns inconsistent

Re: [PATCH v2] mm/hugetlb.c: make huge_pte_offset() consistent and document behaviour

On 08/21/2017 11:07 AM, Catalin Marinas wrote: > On Fri, Aug 18, 2017 at 02:29:18PM -0700, Mike Kravetz wrote: >> On 08/18/2017 07:54 AM, Punit Agrawal wrote: >>> When walking the page tables to resolve an address that points to >>> !p*d_present() entry, huge_pte_offset() returns inconsistent

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

On Mon, Aug 21, 2017 at 11:14:00PM +0200, Peter Zijlstra wrote: > +static int > +find_idlest_cpu(struct sched_domain *sd, struct task_struct *p, int cpu, int > sd_flag) > +{ > + struct sched_domain *tmp; > + int new_cpu = cpu; > + > + while (sd) { > + struct sched_group

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

On Mon, Aug 21, 2017 at 11:14:00PM +0200, Peter Zijlstra wrote: > +static int > +find_idlest_cpu(struct sched_domain *sd, struct task_struct *p, int cpu, int > sd_flag) > +{ > + struct sched_domain *tmp; > + int new_cpu = cpu; > + > + while (sd) { > + struct sched_group

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 8/21/17 2:00 PM, Daniel Borkmann wrote: On 08/21/2017 10:44 PM, Edward Cree wrote: On 21/08/17 21:27, Daniel Borkmann wrote: On 08/21/2017 08:36 PM, Edward Cree wrote: On 19/08/17 00:37, Alexei Starovoitov wrote: [...] I'm tempted to just rip out env->varlen_map_value_access and always

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 8/21/17 2:00 PM, Daniel Borkmann wrote: On 08/21/2017 10:44 PM, Edward Cree wrote: On 21/08/17 21:27, Daniel Borkmann wrote: On 08/21/2017 08:36 PM, Edward Cree wrote: On 19/08/17 00:37, Alexei Starovoitov wrote: [...] I'm tempted to just rip out env->varlen_map_value_access and always

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 8/21/17 1:24 PM, Edward Cree wrote: On 18/08/17 15:16, Edward Cree wrote: On 18/08/17 04:21, Alexei Starovoitov wrote: It seems you're trying to sort-of do per-fake-basic block liveness analysis, but our state_list_marks are not correct if we go with canonical basic block definition, since

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 8/21/17 1:24 PM, Edward Cree wrote: On 18/08/17 15:16, Edward Cree wrote: On 18/08/17 04:21, Alexei Starovoitov wrote: It seems you're trying to sort-of do per-fake-basic block liveness analysis, but our state_list_marks are not correct if we go with canonical basic block definition, since

Re: [PATCH v3] livepatch: add (un)patch callbacks

On Fri, Aug 18, 2017 at 03:58:16PM +0200, Petr Mladek wrote: > On Wed 2017-08-16 15:17:04, Joe Lawrence wrote: > > Provide livepatch modules a klp_object (un)patching notification > > mechanism. Pre and post-(un)patch callbacks allow livepatch modules to > > setup or synchronize changes that

Re: [PATCH v3] livepatch: add (un)patch callbacks

On Fri, Aug 18, 2017 at 03:58:16PM +0200, Petr Mladek wrote: > On Wed 2017-08-16 15:17:04, Joe Lawrence wrote: > > Provide livepatch modules a klp_object (un)patching notification > > mechanism. Pre and post-(un)patch callbacks allow livepatch modules to > > setup or synchronize changes that

Re: [PATCH V3 2/4] ARM: dts: rockchip: rk322x add iommu nodes

Am Montag, 24. Juli 2017, 10:32:08 CEST schrieb Simon Xue: > Add VPU/VDEC/VOP/IEP iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 Thanks Heiko

Re: [PATCH V3 2/4] ARM: dts: rockchip: rk322x add iommu nodes

Am Montag, 24. Juli 2017, 10:32:08 CEST schrieb Simon Xue: > Add VPU/VDEC/VOP/IEP iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 Thanks Heiko

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

On Mon, Aug 21, 2017 at 04:21:28PM +0100, Brendan Jackman wrote: > The current use of returning NULL from find_idlest_group is broken in > two cases: > > a1) The local group is not allowed. > >In this case, we currently do not change this_runnable_load or >this_avg_load from its initial

Re: [PATCH V3 4/4] ARM64: dts: rockchip: rk3399 add iommu nodes

Am Montag, 24. Juli 2017, 10:32:10 CEST schrieb Simon Xue: > Add VPU/VDEC/IEP/VOPL/VOPB/ISP0/ISP1 iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 (after adapting the subject a bit, dropping the vop-mmus added via another patch) Thanks Heiko

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

On Mon, Aug 21, 2017 at 04:21:28PM +0100, Brendan Jackman wrote: > The current use of returning NULL from find_idlest_group is broken in > two cases: > > a1) The local group is not allowed. > >In this case, we currently do not change this_runnable_load or >this_avg_load from its initial

Re: [PATCH V3 4/4] ARM64: dts: rockchip: rk3399 add iommu nodes

Am Montag, 24. Juli 2017, 10:32:10 CEST schrieb Simon Xue: > Add VPU/VDEC/IEP/VOPL/VOPB/ISP0/ISP1 iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 (after adapting the subject a bit, dropping the vop-mmus added via another patch) Thanks Heiko

Re: [PATCH v11 2/4] PCI: Factor out pci_bus_wait_crs()

On Mon, Aug 21, 2017 at 04:32:26PM -0400, Sinan Kaya wrote: > On 8/21/2017 4:23 PM, Bjorn Helgaas wrote: > > On Mon, Aug 21, 2017 at 03:37:06PM -0400, Sinan Kaya wrote: > >> On 8/21/2017 3:18 PM, Bjorn Helgaas wrote: > >> ... > >> if (pci_bus_crs_pending(id)) > >>return

Re: [PATCH v11 2/4] PCI: Factor out pci_bus_wait_crs()

On Mon, Aug 21, 2017 at 04:32:26PM -0400, Sinan Kaya wrote: > On 8/21/2017 4:23 PM, Bjorn Helgaas wrote: > > On Mon, Aug 21, 2017 at 03:37:06PM -0400, Sinan Kaya wrote: > >> On 8/21/2017 3:18 PM, Bjorn Helgaas wrote: > >> ... > >> if (pci_bus_crs_pending(id)) > >>return

Re: [PATCH V3 3/4] ARM64: dts: rockchip: rk3368 add iommu nodes

Am Montag, 24. Juli 2017, 10:32:09 CEST schrieb Simon Xue: > Add IEP/ISP/VOP/HEVC/VPU iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 (after adapting the subject a bit) Thanks Heiko

Re: [PATCH V3 3/4] ARM64: dts: rockchip: rk3368 add iommu nodes

Am Montag, 24. Juli 2017, 10:32:09 CEST schrieb Simon Xue: > Add IEP/ISP/VOP/HEVC/VPU iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 (after adapting the subject a bit) Thanks Heiko

Re: [PATCH V3 1/4] ARM64: dts: rockchip: rk3328 add iommu nodes

Am Montag, 24. Juli 2017, 10:32:07 CEST schrieb Simon Xue: > Add H265e/VEPU/VPU/VDEC/VOP iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 (after adapting the subject a bit) Thanks Heiko

Re: [PATCH V3 1/4] ARM64: dts: rockchip: rk3328 add iommu nodes

Am Montag, 24. Juli 2017, 10:32:07 CEST schrieb Simon Xue: > Add H265e/VEPU/VPU/VDEC/VOP iommu nodes > > Signed-off-by: Simon Xue applied for 4.14 (after adapting the subject a bit) Thanks Heiko

Re: [PATCH v5 4/7] support user space to query RAS extension feature

On Fri, Aug 18, 2017 at 10:11:54PM +0800, Dongjiu Geng wrote: You should put KVM and arm64 in the subject here. > In armv8.2 RAS extension, it adds virtual SError exception > syndrome registeri(VSESR_EL2), user space will specify that > value. so user space will check whether CPU feature has RAS

Re: [PATCH v5 4/7] support user space to query RAS extension feature

On Fri, Aug 18, 2017 at 10:11:54PM +0800, Dongjiu Geng wrote: You should put KVM and arm64 in the subject here. > In armv8.2 RAS extension, it adds virtual SError exception > syndrome registeri(VSESR_EL2), user space will specify that > value. so user space will check whether CPU feature has RAS

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 22:31 +0200, Rafael J. Wysocki wrote: > On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov > wrote: > > On Mon, Aug 21, 2017 at 05:23:37PM +, Kani, Toshimitsu wrote: > > > > > 'data' here is private to the caller.  So, I do not think we > > > > > need to

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, 2017-08-21 at 22:31 +0200, Rafael J. Wysocki wrote: > On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov > wrote: > > On Mon, Aug 21, 2017 at 05:23:37PM +, Kani, Toshimitsu wrote: > > > > > 'data' here is private to the caller.  So, I do not think we > > > > > need to define the bits.  

[patch] fs, proc: unconditional cond_resched when reading smaps

If there are large numbers of hugepages to iterate while reading /proc/pid/smaps, the page walk never does cond_resched(). On archs without split pmd locks, there can be significant and observable contention on mm->page_table_lock which cause lengthy delays without rescheduling. Always

[patch] fs, proc: unconditional cond_resched when reading smaps

If there are large numbers of hugepages to iterate while reading /proc/pid/smaps, the page walk never does cond_resched(). On archs without split pmd locks, there can be significant and observable contention on mm->page_table_lock which cause lengthy delays without rescheduling. Always

[GIT] Sparc

Just a couple small fixes, two of which have to do with gcc-7: 1) Don't clobber kernel fixed registers in __multi4 libgcc helper. 2) Fix a new uninitialized variable warning on sparc32 with gcc-7, from Thomas Petazzoni. 3) Adjust pmd_t initializer on sparc32 to make gcc happy. 4) If ATU

[GIT] Sparc

Just a couple small fixes, two of which have to do with gcc-7: 1) Don't clobber kernel fixed registers in __multi4 libgcc helper. 2) Fix a new uninitialized variable warning on sparc32 with gcc-7, from Thomas Petazzoni. 3) Adjust pmd_t initializer on sparc32 to make gcc happy. 4) If ATU

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 08/21/2017 10:44 PM, Edward Cree wrote: On 21/08/17 21:27, Daniel Borkmann wrote: On 08/21/2017 08:36 PM, Edward Cree wrote: On 19/08/17 00:37, Alexei Starovoitov wrote: [...] I'm tempted to just rip out env->varlen_map_value_access and always check the whole thing, because honestly I

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 08/21/2017 10:44 PM, Edward Cree wrote: On 21/08/17 21:27, Daniel Borkmann wrote: On 08/21/2017 08:36 PM, Edward Cree wrote: On 19/08/17 00:37, Alexei Starovoitov wrote: [...] I'm tempted to just rip out env->varlen_map_value_access and always check the whole thing, because honestly I

[PATCH] mt7601u: check memory allocation failure

Check memory allocation failure and return -ENOMEM in such a case, as already done a few lines below Signed-off-by: Christophe JAILLET --- drivers/net/wireless/mediatek/mt7601u/dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] mt7601u: check memory allocation failure

Check memory allocation failure and return -ENOMEM in such a case, as already done a few lines below Signed-off-by: Christophe JAILLET --- drivers/net/wireless/mediatek/mt7601u/dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c

[PATCH 4/4] w1-masters: Improve a size determination in four functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:53:21 +0200 Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 4/4] w1-masters: Improve a size determination in four functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:53:21 +0200 Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 3/4] w1-masters: Delete an error message for a failed memory allocation in four functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:40:29 +0200 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 3/4] w1-masters: Delete an error message for a failed memory allocation in four functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:40:29 +0200 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/w1/masters/ds2490.c| 5 ++---

[PATCH] f2fs: issue discard commands if gc_urgent is set

It's time to issue all the discard commands, if user sets the idle time. Signed-off-by: Jaegeuk Kim --- fs/f2fs/segment.c | 6 +- fs/f2fs/sysfs.c | 5 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index

[PATCH] f2fs: issue discard commands if gc_urgent is set

It's time to issue all the discard commands, if user sets the idle time. Signed-off-by: Jaegeuk Kim --- fs/f2fs/segment.c | 6 +- fs/f2fs/sysfs.c | 5 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index

[PATCH 2/4] w1: Improve a size determination in two functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:17:01 +0200 Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/4] w1: Improve a size determination in two functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:17:01 +0200 Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 1/4] w1: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:05:42 +0200 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/4] w1: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Mon, 21 Aug 2017 21:05:42 +0200 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/w1/w1.c | 7 +-- drivers/w1/w1_int.c | 6 +- 2

[PATCH 0/4] w1: Adjustments for some function implementations

From: Markus Elfring Date: Mon, 21 Aug 2017 22:04:56 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete an error message for a failed memory allocation in two functions Improve a size

[PATCH 0/4] w1: Adjustments for some function implementations

From: Markus Elfring Date: Mon, 21 Aug 2017 22:04:56 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete an error message for a failed memory allocation in two functions Improve a size determination in two functions masters:

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 21/08/17 21:27, Daniel Borkmann wrote: > On 08/21/2017 08:36 PM, Edward Cree wrote: >> On 19/08/17 00:37, Alexei Starovoitov wrote: > [...] >> I'm tempted to just rip out env->varlen_map_value_access and always check >> the whole thing, because honestly I don't know what it was meant to do >>

Re: [PATCH] sched/fair: move definitions to fix !CONFIG_SMP

On Mon, Aug 21, 2017 at 10:06:53PM +0200, Peter Zijlstra wrote: > On Mon, Aug 21, 2017 at 04:03:05PM -0400, jo...@toxicpanda.com wrote: > > From: Josef Bacik > > > > The series of patches adding runnable_avg and subsequent supporting > > patches broke on !CONFIG_SMP. Fix this by

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 21/08/17 21:27, Daniel Borkmann wrote: > On 08/21/2017 08:36 PM, Edward Cree wrote: >> On 19/08/17 00:37, Alexei Starovoitov wrote: > [...] >> I'm tempted to just rip out env->varlen_map_value_access and always check >> the whole thing, because honestly I don't know what it was meant to do >>

Re: [PATCH] sched/fair: move definitions to fix !CONFIG_SMP

On Mon, Aug 21, 2017 at 10:06:53PM +0200, Peter Zijlstra wrote: > On Mon, Aug 21, 2017 at 04:03:05PM -0400, jo...@toxicpanda.com wrote: > > From: Josef Bacik > > > > The series of patches adding runnable_avg and subsequent supporting > > patches broke on !CONFIG_SMP. Fix this by moving the

Re: [PATCH 0/4] constify scsi/tty parisc_device_id

On 19.08.2017 19:54, Arvind Yadav wrote: > parisc_device_id are not supposed to change at runtime. All functions > working with parisc_device_id provided by work with > const parisc_device_id. So mark the non-const structs as const. > > Arvind Yadav (4): > [PATCH 1/4] scsi: lasi700: constify

Re: [PATCH 0/4] constify scsi/tty parisc_device_id

On 19.08.2017 19:54, Arvind Yadav wrote: > parisc_device_id are not supposed to change at runtime. All functions > working with parisc_device_id provided by work with > const parisc_device_id. So mark the non-const structs as const. > > Arvind Yadav (4): > [PATCH 1/4] scsi: lasi700: constify

Re: [PATCH 0/8] constify parisc parisc_device_id

Hi Arvind, On 19.08.2017 19:42, Arvind Yadav wrote: > parisc_device_id are not supposed to change at runtime. All functions > working with parisc_device_id provided by work with > const parisc_device_id. So mark the non-const structs as const. Basically your patches are correct, but those

Re: [PATCH 0/8] constify parisc parisc_device_id

Hi Arvind, On 19.08.2017 19:42, Arvind Yadav wrote: > parisc_device_id are not supposed to change at runtime. All functions > working with parisc_device_id provided by work with > const parisc_device_id. So mark the non-const structs as const. Basically your patches are correct, but those

Re: [PATCH v4] f2fs: introduce discard_granularity sysfs entry

On 08/18, Chao Yu wrote: > Hi Jaegeuk, > > Sorry for the delay, the modification looks good to me. ;) We must avoid waking up discard thread caused by # of pending commands which are never issued. >From a73f8807248c2f42328a2204eab16a3b8d32c83e Mon Sep 17 00:00:00 2001 From: Chao Yu

Re: [PATCH v4] f2fs: introduce discard_granularity sysfs entry

On 08/18, Chao Yu wrote: > Hi Jaegeuk, > > Sorry for the delay, the modification looks good to me. ;) We must avoid waking up discard thread caused by # of pending commands which are never issued. >From a73f8807248c2f42328a2204eab16a3b8d32c83e Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Mon,

[PATCH RFC v3 3/9] KVM: remember position in kvm->vcpus array

Signed-off-by: Radim Krčmář --- include/linux/kvm_host.h | 11 +++ virt/kvm/kvm_main.c | 5 - 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 6882538eda32..a8ff956616d2 100644 ---

[PATCH RFC v3 3/9] KVM: remember position in kvm->vcpus array

Signed-off-by: Radim Krčmář --- include/linux/kvm_host.h | 11 +++ virt/kvm/kvm_main.c | 5 - 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 6882538eda32..a8ff956616d2 100644 ---

[PATCH RFC v3 9/9] KVM: split kvm->vcpus into chunks

This allows us to have high KVM_VCPU_MAX without wasting too much space with small guests. RCU is a viable alternative now that we do not have to protect the kvm_for_each_vcpu() loop. Suggested-by: David Hildenbrand Signed-off-by: Radim Krčmář ---

[PATCH RFC v3 9/9] KVM: split kvm->vcpus into chunks

This allows us to have high KVM_VCPU_MAX without wasting too much space with small guests. RCU is a viable alternative now that we do not have to protect the kvm_for_each_vcpu() loop. Suggested-by: David Hildenbrand Signed-off-by: Radim Krčmář --- arch/mips/kvm/mips.c | 2 +-

[PATCH RFC v3 8/9] KVM: implement kvm_for_each_vcpu with a list

Going through all VCPUs is more natural with a list and the RCU list can work as lockless with our constraints. This makes kvm->vcpus lose most users, so it will be easier to make something out of it. A nice side-effect is that the first argument to the macro is gone. ARM code was changed a bit

[PATCH RFC v3 8/9] KVM: implement kvm_for_each_vcpu with a list

Going through all VCPUs is more natural with a list and the RCU list can work as lockless with our constraints. This makes kvm->vcpus lose most users, so it will be easier to make something out of it. A nice side-effect is that the first argument to the macro is gone. ARM code was changed a bit

[PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus

We can add a variable instead of scanning all online VCPUs to know how many are started. We can't trivially tell which VCPU is the last one, though. Suggested-by: Cornelia Huck Signed-off-by: Radim Krčmář --- arch/s390/include/asm/kvm_host.h | 1 +

[PATCH RFC v3 7/9] KVM: add kvm_free_vcpus and kvm_arch_free_vcpus

Generalize clearing of kvm->vcpus. This should not be needed at all as all accesses to VCPUs in the destruction path are bugs, but maybe helps to catch them. The call path crosses arch/common code way too much, so extra untangling patch is welcome. Doing the clearing later seems be ok. I don't

[PATCH RFC v3 4/9] KVM: arm/arm64: use locking helpers in kvm_vgic_create()

No new VCPUs can be created because we are holding the kvm->lock. This means that if we successfuly lock all VCPUs, we'll be unlocking the same set and there is no need to do extra bookkeeping. Signed-off-by: Radim Krčmář --- virt/kvm/arm/vgic/vgic-init.c | 24

[PATCH RFC v3 4/9] KVM: arm/arm64: use locking helpers in kvm_vgic_create()

No new VCPUs can be created because we are holding the kvm->lock. This means that if we successfuly lock all VCPUs, we'll be unlocking the same set and there is no need to do extra bookkeeping. Signed-off-by: Radim Krčmář --- virt/kvm/arm/vgic/vgic-init.c | 24 +---

[PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus

We can add a variable instead of scanning all online VCPUs to know how many are started. We can't trivially tell which VCPU is the last one, though. Suggested-by: Cornelia Huck Signed-off-by: Radim Krčmář --- arch/s390/include/asm/kvm_host.h | 1 + arch/s390/kvm/kvm-s390.c | 39

[PATCH RFC v3 7/9] KVM: add kvm_free_vcpus and kvm_arch_free_vcpus

Generalize clearing of kvm->vcpus. This should not be needed at all as all accesses to VCPUs in the destruction path are bugs, but maybe helps to catch them. The call path crosses arch/common code way too much, so extra untangling patch is welcome. Doing the clearing later seems be ok. I don't

[PATCH RFC v3 6/9] KVM: rework kvm_vcpu_on_spin loop

The original code managed to obfuscate a straightforward idea: start iterating from the selected index and reset the index to 0 when reaching the end of online vcpus, then iterate until reaching the index that we started at. The resulting code is a bit better, IMO. (Still horrible, though.)

[PATCH RFC v3 6/9] KVM: rework kvm_vcpu_on_spin loop

The original code managed to obfuscate a straightforward idea: start iterating from the selected index and reset the index to 0 when reaching the end of online vcpus, then iterate until reaching the index that we started at. The resulting code is a bit better, IMO. (Still horrible, though.)

[PATCH RFC v3 5/9] KVM: remove unused __KVM_HAVE_ARCH_VM_ALLOC

Moving it to generic code will allow us to extend it with ease. Christian noted that it was only used in the removed ia64. Reviewed-by: David Hildenbrand Reviewed-by: Christian Borntraeger Signed-off-by: Radim Krčmář ---

[PATCH RFC v3 5/9] KVM: remove unused __KVM_HAVE_ARCH_VM_ALLOC

Moving it to generic code will allow us to extend it with ease. Christian noted that it was only used in the removed ia64. Reviewed-by: David Hildenbrand Reviewed-by: Christian Borntraeger Signed-off-by: Radim Krčmář --- include/linux/kvm_host.h | 12 virt/kvm/kvm_main.c |

[PATCH RFC v3 2/9] KVM: arm/arm64: fix vcpu self-detection in vgic_v3_dispatch_sgi()

The index in kvm->vcpus array and vcpu->vcpu_id are very different things. Comparing struct kvm_vcpu pointers is a sure way to know. Signed-off-by: Radim Krčmář --- virt/kvm/arm/vgic/vgic-mmio-v3.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH RFC v3 2/9] KVM: arm/arm64: fix vcpu self-detection in vgic_v3_dispatch_sgi()

The index in kvm->vcpus array and vcpu->vcpu_id are very different things. Comparing struct kvm_vcpu pointers is a sure way to know. Signed-off-by: Radim Krčmář --- virt/kvm/arm/vgic/vgic-mmio-v3.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH RFC v3 0/9] KVM: allow dynamic kvm->vcpus array

The only common part with v2 is [v3 5/9]. The crucial part of this series is adding a separate mechanism for kvm_for_each_vcpu() [v3 8/9] and with that change, I think that the dynamic array [v3 9/9] would be nicer if protected by RCU, like in v2: The protection can be nicely hidden in

[PATCH RFC v3 0/9] KVM: allow dynamic kvm->vcpus array

The only common part with v2 is [v3 5/9]. The crucial part of this series is adding a separate mechanism for kvm_for_each_vcpu() [v3 8/9] and with that change, I think that the dynamic array [v3 9/9] would be nicer if protected by RCU, like in v2: The protection can be nicely hidden in

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

From: mr...@linux.ee Date: Mon, 21 Aug 2017 22:20:22 +0300 (EEST) >> I think with this patch from -rc6 the symptoms should be cured: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7 >> >> if that theory is right. > >

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

From: mr...@linux.ee Date: Mon, 21 Aug 2017 22:20:22 +0300 (EEST) >> I think with this patch from -rc6 the symptoms should be cured: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7 >> >> if that theory is right. > >

Re: [PATCH v11 2/4] PCI: Factor out pci_bus_wait_crs()

On 8/21/2017 4:23 PM, Bjorn Helgaas wrote: > On Mon, Aug 21, 2017 at 03:37:06PM -0400, Sinan Kaya wrote: >> On 8/21/2017 3:18 PM, Bjorn Helgaas wrote: >> ... >> if (pci_bus_crs_pending(id)) >> return pci_bus_wait_crs(dev->bus, dev->devfn, , 6); >> >>> I think that makes sense. We'd want

Re: [PATCH v11 2/4] PCI: Factor out pci_bus_wait_crs()

On 8/21/2017 4:23 PM, Bjorn Helgaas wrote: > On Mon, Aug 21, 2017 at 03:37:06PM -0400, Sinan Kaya wrote: >> On 8/21/2017 3:18 PM, Bjorn Helgaas wrote: >> ... >> if (pci_bus_crs_pending(id)) >> return pci_bus_wait_crs(dev->bus, dev->devfn, , 6); >> >>> I think that makes sense. We'd want

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov wrote: > On Mon, Aug 21, 2017 at 05:23:37PM +, Kani, Toshimitsu wrote: >> > > 'data' here is private to the caller. So, I do not think we need >> > > to define the bits. Shall I change the name to 'driver_data' to >> > > make

Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list()

On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov wrote: > On Mon, Aug 21, 2017 at 05:23:37PM +, Kani, Toshimitsu wrote: >> > > 'data' here is private to the caller. So, I do not think we need >> > > to define the bits. Shall I change the name to 'driver_data' to >> > > make it more

Re: [PATCH v2 1/2] Input: Add driver for Cypress Generation 5 touchscreen

On Fri, Aug 18, 2017 at 08:20:44AM +0200, Mylène Josserand wrote: > This is the basic driver for the Cypress TrueTouch Gen5 touchscreen > controllers. This driver supports only the I2C bus but it uses regmap > so SPI support could be added later. > The touchscreen can retrieve some defined zone

Re: [PATCH v2 1/2] Input: Add driver for Cypress Generation 5 touchscreen

On Fri, Aug 18, 2017 at 08:20:44AM +0200, Mylène Josserand wrote: > This is the basic driver for the Cypress TrueTouch Gen5 touchscreen > controllers. This driver supports only the I2C bus but it uses regmap > so SPI support could be added later. > The touchscreen can retrieve some defined zone

Re: [PATCH] XEN/xen-kbdfront: Enable auto repeat for xen keyboard front driver

On Mon, Aug 21, 2017 at 12:30 PM, Boris Ostrovsky wrote: > > Adding maintainer (Dmitry). I can't seem to find the original in my mailbox nor in patchwork. Can you please resend? > > > -boris > > On 08/21/2017 11:41 AM, Liang Yan wrote: > > Long pressed key could not

Re: [PATCH] XEN/xen-kbdfront: Enable auto repeat for xen keyboard front driver

On Mon, Aug 21, 2017 at 12:30 PM, Boris Ostrovsky wrote: > > Adding maintainer (Dmitry). I can't seem to find the original in my mailbox nor in patchwork. Can you please resend? > > > -boris > > On 08/21/2017 11:41 AM, Liang Yan wrote: > > Long pressed key could not show right in XEN vncviewer

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 08/21/2017 08:36 PM, Edward Cree wrote: On 19/08/17 00:37, Alexei Starovoitov wrote: [...] I'm tempted to just rip out env->varlen_map_value_access and always check the whole thing, because honestly I don't know what it was meant to do originally or how it can ever do any useful

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 08/21/2017 08:36 PM, Edward Cree wrote: On 19/08/17 00:37, Alexei Starovoitov wrote: [...] I'm tempted to just rip out env->varlen_map_value_access and always check the whole thing, because honestly I don't know what it was meant to do originally or how it can ever do any useful

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