Re: [PATCH 03/17] pci: Add a generic, weakly-linked pcibios_fixup_bus

On Mon, Jul 10, 2017 at 06:39:10PM -0700, Palmer Dabbelt wrote: > Multiple architectures define this as an empty function, and I'm adding > another one as part of the RISC-V port. This adds a __weak version of > pci_fixup_bios and deletes the now obselete ones in a handful of ports. > > The only

Re: [PATCH 03/17] pci: Add a generic, weakly-linked pcibios_fixup_bus

On Mon, Jul 10, 2017 at 06:39:10PM -0700, Palmer Dabbelt wrote: > Multiple architectures define this as an empty function, and I'm adding > another one as part of the RISC-V port. This adds a __weak version of > pci_fixup_bios and deletes the now obselete ones in a handful of ports. > > The only

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On Tue, Jul 11, 2017 at 11:42:20AM -0700, Evgeny Baskakov wrote: > On 7/11/17 11:29 AM, Jerome Glisse wrote: > > Can you test if attached patch helps ? I am having trouble reproducing > > this > > from inside a vm. > > > > My theory is that 2 concurrent CPU page fault happens. First one manage to

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On Tue, Jul 11, 2017 at 11:42:20AM -0700, Evgeny Baskakov wrote: > On 7/11/17 11:29 AM, Jerome Glisse wrote: > > Can you test if attached patch helps ? I am having trouble reproducing > > this > > from inside a vm. > > > > My theory is that 2 concurrent CPU page fault happens. First one manage to

Re: [PATCH v2] integrity: track mtime in addition to i_version for assessment

On Tue, 2017-07-11 at 12:13 -0400, J. Bruce Fields wrote: > On Fri, Jul 07, 2017 at 10:05:30AM -0400, Jeff Layton wrote: > > From: Jeff Layton > > > > The IMA assessment code tries to use the i_version counter to detect > > when changes to a file have occurred. Many

Re: [PATCH v2] integrity: track mtime in addition to i_version for assessment

On Tue, 2017-07-11 at 12:13 -0400, J. Bruce Fields wrote: > On Fri, Jul 07, 2017 at 10:05:30AM -0400, Jeff Layton wrote: > > From: Jeff Layton > > > > The IMA assessment code tries to use the i_version counter to detect > > when changes to a file have occurred. Many filesystems don't increment >

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On 7/11/17 11:29 AM, Jerome Glisse wrote: Can you test if attached patch helps ? I am having trouble reproducing this from inside a vm. My theory is that 2 concurrent CPU page fault happens. First one manage to start the migration back to system memory but second one see the migration special

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On 7/11/17 11:29 AM, Jerome Glisse wrote: Can you test if attached patch helps ? I am having trouble reproducing this from inside a vm. My theory is that 2 concurrent CPU page fault happens. First one manage to start the migration back to system memory but second one see the migration special

[PATCH] pinctrl: qcom: ssbi-gpio: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

[PATCH] pinctrl: qcom: ssbi-gpio: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

Re: RISC-V Linux Port v5

On Mon, Jul 10, 2017 at 06:39:07PM -0700, Palmer Dabbelt wrote: > Thanks to everyone who has participated in the review process so far. I've > based this patch set on the current master. Things have really started to > calmn down, so this is fairly similar to the v4 patch set. The most >

Re: RISC-V Linux Port v5

On Mon, Jul 10, 2017 at 06:39:07PM -0700, Palmer Dabbelt wrote: > Thanks to everyone who has participated in the review process so far. I've > based this patch set on the current master. Things have really started to > calmn down, so this is fairly similar to the v4 patch set. The most >

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Jim Mattson writes: ... >>> I can find the definition for an vmexit in case of index >= >>> VMFUNC_EPTP_ENTRIES, but not for !vmcs12->eptp_list_address in the SDM. >>> >>> Can you give me a hint? >> >> I don't think there is. Since, we are basically emulating eptp switching

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Jim Mattson writes: ... >>> I can find the definition for an vmexit in case of index >= >>> VMFUNC_EPTP_ENTRIES, but not for !vmcs12->eptp_list_address in the SDM. >>> >>> Can you give me a hint? >> >> I don't think there is. Since, we are basically emulating eptp switching >> for L2, this is a

[PATCH] pinctrl: qcom: msm: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

[PATCH] pinctrl: qcom: msm: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On Mon, Jul 10, 2017 at 04:44:38PM -0700, Evgeny Baskakov wrote: > On 6/30/17 5:57 PM, Jerome Glisse wrote: > > ... > > Hi Jerome, > > I am working on a sporadic data corruption seen in highly contented use > cases. So far, I've been able to re-create a sporadic hang that happens when >

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On Mon, Jul 10, 2017 at 04:44:38PM -0700, Evgeny Baskakov wrote: > On 6/30/17 5:57 PM, Jerome Glisse wrote: > > ... > > Hi Jerome, > > I am working on a sporadic data corruption seen in highly contented use > cases. So far, I've been able to re-create a sporadic hang that happens when >

[PATCH] pinctrl: vt8500: wmt: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

[PATCH] pinctrl: vt8500: wmt: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

Re: [PATCH -mm -v2 2/6] mm, swap: Add swap readahead hit statistics

On 06/29/2017 06:44 PM, Huang, Ying wrote: > > static atomic_t swapin_readahead_hits = ATOMIC_INIT(4); > +static atomic_long_t swapin_readahead_hits_total = ATOMIC_INIT(0); > +static atomic_long_t swapin_readahead_total = ATOMIC_INIT(0); > > void show_swap_cache_info(void) > { > @@ -305,8

Re: [PATCH -mm -v2 2/6] mm, swap: Add swap readahead hit statistics

On 06/29/2017 06:44 PM, Huang, Ying wrote: > > static atomic_t swapin_readahead_hits = ATOMIC_INIT(4); > +static atomic_long_t swapin_readahead_hits_total = ATOMIC_INIT(0); > +static atomic_long_t swapin_readahead_total = ATOMIC_INIT(0); > > void show_swap_cache_info(void) > { > @@ -305,8

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Bandan Das writes: >>> + /* >>> +* If the (L2) guest does a vmfunc to the currently >>> +* active ept pointer, we don't have to do anything else >>> +*/ >>> + if (vmcs12->ept_pointer != address) { >>> + if (address >> cpuid_maxphyaddr(vcpu) || >>> +

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Bandan Das writes: >>> + /* >>> +* If the (L2) guest does a vmfunc to the currently >>> +* active ept pointer, we don't have to do anything else >>> +*/ >>> + if (vmcs12->ept_pointer != address) { >>> + if (address >> cpuid_maxphyaddr(vcpu) || >>> +

Re: [RFC PATCH 1/1] mm/mremap: add MREMAP_MIRROR flag for existing mirroring functionality

On 07/11/2017 05:36 AM, Michal Hocko wrote: > On Thu 06-07-17 09:17:26, Mike Kravetz wrote: >> The mremap system call has the ability to 'mirror' parts of an existing >> mapping. To do so, it creates a new mapping that maps the same pages as >> the original mapping, just at a different virtual

Re: [RFC PATCH 1/1] mm/mremap: add MREMAP_MIRROR flag for existing mirroring functionality

On 07/11/2017 05:36 AM, Michal Hocko wrote: > On Thu 06-07-17 09:17:26, Mike Kravetz wrote: >> The mremap system call has the ability to 'mirror' parts of an existing >> mapping. To do so, it creates a new mapping that maps the same pages as >> the original mapping, just at a different virtual

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

On Tue, Jul 11, 2017 at 10:58 AM, Bandan Das wrote: > David Hildenbrand writes: > >> On 10.07.2017 22:49, Bandan Das wrote: >>> When L2 uses vmfunc, L0 utilizes the associated vmexit to >>> emulate a switching of the ept pointer by reloading the >>> guest MMU.

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

On Tue, Jul 11, 2017 at 10:58 AM, Bandan Das wrote: > David Hildenbrand writes: > >> On 10.07.2017 22:49, Bandan Das wrote: >>> When L2 uses vmfunc, L0 utilizes the associated vmexit to >>> emulate a switching of the ept pointer by reloading the >>> guest MMU. >>> >>> Signed-off-by: Paolo

[PATCH] pinctrl: rza1: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

[PATCH] pinctrl: rza1: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

Re: [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys

On 07/05/2017 02:22 PM, Ram Pai wrote: > Add documentation updates that capture PowerPC specific changes. > > Signed-off-by: Ram Pai > --- > Documentation/vm/protection-keys.txt | 85 > ++ > 1 files changed, 65 insertions(+), 20

Re: [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys

On 07/05/2017 02:22 PM, Ram Pai wrote: > Add documentation updates that capture PowerPC specific changes. > > Signed-off-by: Ram Pai > --- > Documentation/vm/protection-keys.txt | 85 > ++ > 1 files changed, 65 insertions(+), 20 deletions(-) > > diff --git

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce >

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce > GTX 980]

Re: [PATCH] staging: unisys: visorbus: fix function open braces

On Mon, Jul 10, 2017 at 11:48:26PM -0400, Mitchell Tasman wrote: > Resolve multiple checkpatch errors by relocating open braces > following function definitions to the next line. > > Signed-off-by: Mitchell Tasman > --- > drivers/staging/unisys/visorbus/visorbus_main.c | 18

Re: [PATCH] staging: unisys: visorbus: fix function open braces

On Mon, Jul 10, 2017 at 11:48:26PM -0400, Mitchell Tasman wrote: > Resolve multiple checkpatch errors by relocating open braces > following function definitions to the next line. > > Signed-off-by: Mitchell Tasman > --- > drivers/staging/unisys/visorbus/visorbus_main.c | 18 -- >

Re: [GIT pull] irq updates for 4.13

On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner wrote: > > Not completely, because of the free path issues. See the other mail. Tony > confirmed that it works. I wait for Sebastian and queue it with a proper > changelog, ok? Ugh, I absolutely detest your ugly "bool buslock"

Re: [GIT pull] irq updates for 4.13

On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner wrote: > > Not completely, because of the free path issues. See the other mail. Tony > confirmed that it works. I wait for Sebastian and queue it with a proper > changelog, ok? Ugh, I absolutely detest your ugly "bool buslock" parameter to

[PATCH] pinctrl: st: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

[PATCH] pinctrl: st: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma

On 07/05/2017 02:22 PM, Ram Pai wrote: > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma) > +{ > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > +} > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */ This seems like

Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma

On 07/05/2017 02:22 PM, Ram Pai wrote: > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma) > +{ > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > +} > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */ This seems like

Re: [RFC v5 13/38] x86: disallow pkey creation with PKEY_DISABLE_EXECUTE

On 07/05/2017 02:21 PM, Ram Pai wrote: > x86 does not support disabling execute permissions on a pkey. > > Signed-off-by: Ram Pai > --- > arch/x86/kernel/fpu/xstate.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git

Re: [RFC v5 13/38] x86: disallow pkey creation with PKEY_DISABLE_EXECUTE

On 07/05/2017 02:21 PM, Ram Pai wrote: > x86 does not support disabling execute permissions on a pkey. > > Signed-off-by: Ram Pai > --- > arch/x86/kernel/fpu/xstate.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kernel/fpu/xstate.c

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

On 07/05/2017 02:21 PM, Ram Pai wrote: > Currently sys_pkey_create() provides the ability to disable read > and write permission on the key, at creation. powerpc has the > hardware support to disable execute on a pkey as well.This patch > enhances the interface to let disable execute at key

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

On 07/05/2017 02:21 PM, Ram Pai wrote: > Currently sys_pkey_create() provides the ability to disable read > and write permission on the key, at creation. powerpc has the > hardware support to disable execute on a pkey as well.This patch > enhances the interface to let disable execute at key

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote: > On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote: > > On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote: > > > From: Aubrey Li > > > > > > The system will enter a fast idle

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote: > On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote: > > On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote: > > > From: Aubrey Li > > > > > > The system will enter a fast idle loop if the predicted idle

Re: [RFC v5 11/38] mm: introduce an additional vma bit for powerpc pkey

On 07/05/2017 02:21 PM, Ram Pai wrote: > Currently there are only 4bits in the vma flags to support 16 keys > on x86. powerpc supports 32 keys, which needs 5bits. This patch > introduces an addition bit in the vma flags. > > Signed-off-by: Ram Pai > --- >

Re: [RFC v5 11/38] mm: introduce an additional vma bit for powerpc pkey

On 07/05/2017 02:21 PM, Ram Pai wrote: > Currently there are only 4bits in the vma flags to support 16 keys > on x86. powerpc supports 32 keys, which needs 5bits. This patch > introduces an addition bit in the vma flags. > > Signed-off-by: Ram Pai > --- > fs/proc/task_mmu.c |6 +- >

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, Jul 11, 2017 at 06:34:22PM +0200, Peter Zijlstra wrote: > On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote: > > > > > - tick_nohz_idle_enter costs 7058ns - 10726ns > > > > - tick_nohz_idle_exit costs 8372ns - 20850ns > > > > > > Right, those are horrible expensive, but

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, Jul 11, 2017 at 06:34:22PM +0200, Peter Zijlstra wrote: > On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote: > > > > > - tick_nohz_idle_enter costs 7058ns - 10726ns > > > > - tick_nohz_idle_exit costs 8372ns - 20850ns > > > > > > Right, those are horrible expensive, but

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: > Some details that may be useful in analysis of the bug: > > 1. lspci -nn -d 10de: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: > Some details that may be useful in analysis of the bug: > > 1. lspci -nn -d 10de: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation

Re: [PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

On Tue, 11 Jul 2017, Johannes Weiner wrote: > Hi Michael, > > On Tue, Jul 11, 2017 at 04:25:58PM +0200, Michal Hocko wrote: > > Ohh, scratch that. The patch is bogus. I have completely missed that > > vmemmap_populate_hugepages already falls back to > > vmemmap_populate_basepages. I have to

Re: [PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

On Tue, 11 Jul 2017, Johannes Weiner wrote: > Hi Michael, > > On Tue, Jul 11, 2017 at 04:25:58PM +0200, Michal Hocko wrote: > > Ohh, scratch that. The patch is bogus. I have completely missed that > > vmemmap_populate_hugepages already falls back to > > vmemmap_populate_basepages. I have to

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > [David did a great review, so I'll just point out things I noticed.] > > 2017-07-11 09:51+0200, David Hildenbrand: >> On 10.07.2017 22:49, Bandan Das wrote: >> > When L2 uses vmfunc, L0 utilizes the associated vmexit to >> > emulate a switching of the

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

Radim Krčmář writes: > [David did a great review, so I'll just point out things I noticed.] > > 2017-07-11 09:51+0200, David Hildenbrand: >> On 10.07.2017 22:49, Bandan Das wrote: >> > When L2 uses vmfunc, L0 utilizes the associated vmexit to >> > emulate a switching of the ept pointer by

Re: [PATCH] Staging: android/ion: fix sparse warnings

On Wed, Jul 05, 2017 at 12:12:24AM +, Joseph Wright wrote: > ion_carveout_heap.c:115:17: warning: symbol 'ion_carveout_heap_create' \ > was not declared. Should it be static? > ion_chunk_heap.c:120:17: warning: symbol 'ion_chunk_heap_create' \ > was not declared. Should it be

Re: [PATCH] Staging: android/ion: fix sparse warnings

On Wed, Jul 05, 2017 at 12:12:24AM +, Joseph Wright wrote: > ion_carveout_heap.c:115:17: warning: symbol 'ion_carveout_heap_create' \ > was not declared. Should it be static? > ion_chunk_heap.c:120:17: warning: symbol 'ion_chunk_heap_create' \ > was not declared. Should it be

[PATCH] Clean up lirc zilog error codes

According the coding style guidelines, the ENOSYS error code must be returned in case of a non existent system call. This code has been replaced with the ENOTTY error code indicating, a missing functionality. Signed-off-by: Yves Lemée ---

[PATCH] Clean up lirc zilog error codes

According the coding style guidelines, the ENOSYS error code must be returned in case of a non existent system call. This code has been replaced with the ENOTTY error code indicating, a missing functionality. Signed-off-by: Yves Lemée --- drivers/staging/media/lirc/lirc_zilog.c | 10 +-

[PATCH] pinctrl: bcm2835: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

[PATCH] pinctrl: bcm2835: constify gpio_chip structure

This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e;

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, 11 Jul 2017, Frederic Weisbecker wrote: > > --- a/kernel/time/tick-sched.c > > +++ b/kernel/time/tick-sched.c > > @@ -787,6 +787,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct > > tick_sched *ts, > > if (!ts->tick_stopped) { > > calc_load_nohz_start(); > >

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, 11 Jul 2017, Frederic Weisbecker wrote: > > --- a/kernel/time/tick-sched.c > > +++ b/kernel/time/tick-sched.c > > @@ -787,6 +787,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct > > tick_sched *ts, > > if (!ts->tick_stopped) { > > calc_load_nohz_start(); > >

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

David Hildenbrand writes: > On 10.07.2017 22:49, Bandan Das wrote: >> When L2 uses vmfunc, L0 utilizes the associated vmexit to >> emulate a switching of the ept pointer by reloading the >> guest MMU. >> >> Signed-off-by: Paolo Bonzini >> Signed-off-by:

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

David Hildenbrand writes: > On 10.07.2017 22:49, Bandan Das wrote: >> When L2 uses vmfunc, L0 utilizes the associated vmexit to >> emulate a switching of the ept pointer by reloading the >> guest MMU. >> >> Signed-off-by: Paolo Bonzini >> Signed-off-by: Bandan Das >> --- >>

Re: [PATCH] cisco: enic: Fic an error handling path in 'vnic_dev_init_devcmd2()'

From: Christophe JAILLET Date: Sat, 8 Jul 2017 06:51:35 +0200 > if 'ioread32()' returns 0xFFF, we have to go through the error > handling path as done everywhere else in this function. > > Move the 'err_free_wq' label to better match its name and its location

Re: [PATCH] cisco: enic: Fic an error handling path in 'vnic_dev_init_devcmd2()'

From: Christophe JAILLET Date: Sat, 8 Jul 2017 06:51:35 +0200 > if 'ioread32()' returns 0xFFF, we have to go through the error > handling path as done everywhere else in this function. > > Move the 'err_free_wq' label to better match its name and its location > and add a new label

Re: [PATCH] [media] solo6x10: make const array saa7128_regs_ntsc static

On Mon, Jul 10, 2017 at 07:51:03PM +0100, Colin King wrote: > From: Colin Ian King > > Don't populate const array saa7128_regs_ntsc on the stack but insteaed make > it static. Makes the object code smaller and saves nearly 840 bytes > > Before: >text data

Re: [PATCH] [media] solo6x10: make const array saa7128_regs_ntsc static

On Mon, Jul 10, 2017 at 07:51:03PM +0100, Colin King wrote: > From: Colin Ian King > > Don't populate const array saa7128_regs_ntsc on the stack but insteaed make > it static. Makes the object code smaller and saves nearly 840 bytes > > Before: >text data bss dec hex

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Linus Torvalds wrote: > On Tue, Jul 11, 2017 at 9:19 AM, Thomas Gleixner wrote: > > > > What I do not understand here is that we have already power management > > around all of that. > > > >irq_chip_pm_get(>irq_data); > >... > >

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Linus Torvalds wrote: > On Tue, Jul 11, 2017 at 9:19 AM, Thomas Gleixner wrote: > > > > What I do not understand here is that we have already power management > > around all of that. > > > >irq_chip_pm_get(>irq_data); > >... > >chip_bus_lock(desc); > >

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Some details that may be useful in analysis of the bug: 1. lspci -nn -d 10de: 2. What displays, if any, you have plugged into the NVIDIA board when this happens? 3. Any boot parameters, esp relating to ACPI, PM, or related? Cheers, -ilia On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Some details that may be useful in analysis of the bug: 1. lspci -nn -d 10de: 2. What displays, if any, you have plugged into the NVIDIA board when this happens? 3. Any boot parameters, esp relating to ACPI, PM, or related? Cheers, -ilia On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith

Re: [PATCH v8 4/6] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v4

On Tue, Jul 11, 2017 at 3:07 PM, kbuild test robot wrote: > make ARCH=i386 Yeah, either this code shouldn't have been built on 32-bit arch at all, or be portable. >arch/x86/pci/fixup.c: In function 'pci_amd_enable_64bit_bar': >>> arch/x86/pci/fixup.c:674:15:

Re: [PATCH v8 4/6] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v4

On Tue, Jul 11, 2017 at 3:07 PM, kbuild test robot wrote: > make ARCH=i386 Yeah, either this code shouldn't have been built on 32-bit arch at all, or be portable. >arch/x86/pci/fixup.c: In function 'pci_amd_enable_64bit_bar': >>> arch/x86/pci/fixup.c:674:15: warning: large integer

[PATCH][V2] staging: fbtft: make const array gamma_par_mask static

From: Colin Ian King Don't populate array gamma_par_mask on the stack but instead make it static. Makes the object code smaller by 148 bytes: Before: textdata bss dec hex filename 29931104 040971001

[PATCH][V2] staging: fbtft: make const array gamma_par_mask static

From: Colin Ian King Don't populate array gamma_par_mask on the stack but instead make it static. Makes the object code smaller by 148 bytes: Before: textdata bss dec hex filename 29931104 040971001 drivers/staging/fbtft/fb_st7789v.o After: text

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

On 7/11/17 12:58 PM, Salvatore Mesoraca wrote: > 2017-07-11 1:40 GMT+02:00 Mickaël Salaün : >> >> On 10/07/2017 09:59, Salvatore Mesoraca wrote: >>> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün : Hi, I think it make sense to merge the W^X features

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

On 7/11/17 12:58 PM, Salvatore Mesoraca wrote: > 2017-07-11 1:40 GMT+02:00 Mickaël Salaün : >> >> On 10/07/2017 09:59, Salvatore Mesoraca wrote: >>> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün : Hi, I think it make sense to merge the W^X features with the TPE/shebang LSM [1].

Re: [PATCH] vfio: Remove unnecessary uses of vfio_container.group_lock

Sounds reasonable to me. Thanks, Kirti On 7/8/2017 3:45 AM, Alex Williamson wrote: > The original intent of vfio_container.group_lock is to protect > vfio_container.group_list, however over time it's become a crutch to > prevent changes in container composition any time we call into the > iommu

Re: [PATCH] vfio: Remove unnecessary uses of vfio_container.group_lock

Sounds reasonable to me. Thanks, Kirti On 7/8/2017 3:45 AM, Alex Williamson wrote: > The original intent of vfio_container.group_lock is to protect > vfio_container.group_list, however over time it's become a crutch to > prevent changes in container composition any time we call into the > iommu

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

On Tue, Jul 11, 2017 at 06:39:59PM +0100, Colin Ian King wrote: > On 11/07/17 18:30, Greg Kroah-Hartman wrote: > > On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote: > >> From: Colin Ian King > >> > >> Don't populate array gamma_par_mask on the stack but instead

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

On Tue, Jul 11, 2017 at 06:39:59PM +0100, Colin Ian King wrote: > On 11/07/17 18:30, Greg Kroah-Hartman wrote: > > On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote: > >> From: Colin Ian King > >> > >> Don't populate array gamma_par_mask on the stack but instead make it > >> static.

Re: [PATCH] acpi: Fix proper return code for function acpi_gsi_to_irq

On Tue, Jul 11, 2017 at 12:45:43PM -0400, Mark Salter wrote: > The function acpi_gsi_to_irq must return 0 on success as the caller > ghes_probe expects an 0 for success. This change also matches x86 > implementation. > > This patch was submitted around 4.5 timeframe but wasn't pushed because > it

Re: [PATCH] acpi: Fix proper return code for function acpi_gsi_to_irq

On Tue, Jul 11, 2017 at 12:45:43PM -0400, Mark Salter wrote: > The function acpi_gsi_to_irq must return 0 on success as the caller > ghes_probe expects an 0 for success. This change also matches x86 > implementation. > > This patch was submitted around 4.5 timeframe but wasn't pushed because > it

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

On 11/07/17 18:30, Greg Kroah-Hartman wrote: > On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote: >> From: Colin Ian King >> >> Don't populate array gamma_par_mask on the stack but instead make it >> static. Makes the object code smaller by 148 bytes: >> >>

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

On 11/07/17 18:30, Greg Kroah-Hartman wrote: > On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote: >> From: Colin Ian King >> >> Don't populate array gamma_par_mask on the stack but instead make it >> static. Makes the object code smaller by 148 bytes: >> >> Before: >>text

Re: [GIT pull] irq updates for 4.13

* Thomas Gleixner [170711 10:17]: > On Tue, 11 Jul 2017, Tony Lindgren wrote: > > * Linus Torvalds [170711 08:40]: > > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner > > > wrote: > > > > > > > > Ah. Now that makes

Re: [GIT pull] irq updates for 4.13

* Thomas Gleixner [170711 10:17]: > On Tue, 11 Jul 2017, Tony Lindgren wrote: > > * Linus Torvalds [170711 08:40]: > > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner > > > wrote: > > > > > > > > Ah. Now that makes sense. > > > > > > > > Unpatched the ordering is: > > > > > > > >

[PATCH V8 2/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 V8 2/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 V8 1/2] powerpc/hotplug: Ensure enough nodes avail for operations

powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized at boot. In order to

[PATCH V8 1/2] powerpc/hotplug: Ensure enough nodes avail for operations

powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized at boot. In order to

[PATCH V8 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/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory

[PATCH V8 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/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory

Re: [PATCH v2 00/10] Constify attribute_group structures

From: Arvind Yadav Date: Tue, 11 Jul 2017 12:52:41 +0530 > attribute_groups are not supposed to change at runtime. So mark the > non-const structs as const. Please resubmit this when net-next is open again: http://vger.kernel.org/~davem/net-next.html Thank

Re: [PATCH v2 00/10] Constify attribute_group structures

From: Arvind Yadav Date: Tue, 11 Jul 2017 12:52:41 +0530 > attribute_groups are not supposed to change at runtime. So mark the > non-const structs as const. Please resubmit this when net-next is open again: http://vger.kernel.org/~davem/net-next.html Thank you.

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