linux-next: Tree for Sep 6

Hi all, Please do not add any v4.15 related material to your linux-next included branches until after v4.14-rc1 has been released. Changes since 20170905: The devicetree tree gained conflicts against Linus' and the sound trees. The akpm-current tree lost its build failure. Non-merge commits

linux-next: Tree for Sep 6

Hi all, Please do not add any v4.15 related material to your linux-next included branches until after v4.14-rc1 has been released. Changes since 20170905: The devicetree tree gained conflicts against Linus' and the sound trees. The akpm-current tree lost its build failure. Non-merge commits

[PATCH] drivers/iommu/tegra: Optimize mutex_unlock function call

Code can be optimized more by making single exit point of function and calling mutex_unlock at the end Signed-off-by: Pushkar Jambhlekar --- drivers/iommu/tegra-smmu.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/tegra-smmu.c

[PATCH] drivers/iommu/tegra: Optimize mutex_unlock function call

Code can be optimized more by making single exit point of function and calling mutex_unlock at the end Signed-off-by: Pushkar Jambhlekar --- drivers/iommu/tegra-smmu.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/tegra-smmu.c

Re: [PATCH v2] md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list

On Wed, Sep 06, 2017 at 11:02:35AM +0800, Dennis Yang wrote: > In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST > set, it indicates that this stripe_head is already in the raid5_plug_cb > list and release_stripe() would be called instead to drop a reference > count.

Re: [PATCH v2] md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list

On Wed, Sep 06, 2017 at 11:02:35AM +0800, Dennis Yang wrote: > In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST > set, it indicates that this stripe_head is already in the raid5_plug_cb > list and release_stripe() would be called instead to drop a reference > count.

[PATCH 1/2] dt-bindings: watchdog: Add Spreadtrum watchdog documentation

This patch adds the documentation for Spreadtrum watchdog driver. Signed-off-by: Eric Long --- .../devicetree/bindings/watchdog/sprd-wdt.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644

[PATCH 2/2] watchdog: Add Spreadtrum watchdog driver

This patch adds the watchdog driver for Spreadtrum SC9860 platform. Signed-off-by: Eric Long --- drivers/watchdog/Kconfig| 8 + drivers/watchdog/Makefile | 1 + drivers/watchdog/sprd_wdt.c | 366 3 files changed,

[PATCH 1/2] dt-bindings: watchdog: Add Spreadtrum watchdog documentation

This patch adds the documentation for Spreadtrum watchdog driver. Signed-off-by: Eric Long --- .../devicetree/bindings/watchdog/sprd-wdt.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/sprd-wdt.txt diff --git

[PATCH 2/2] watchdog: Add Spreadtrum watchdog driver

This patch adds the watchdog driver for Spreadtrum SC9860 platform. Signed-off-by: Eric Long --- drivers/watchdog/Kconfig| 8 + drivers/watchdog/Makefile | 1 + drivers/watchdog/sprd_wdt.c | 366 3 files changed, 375 insertions(+) create

[PATCH] drivers/staging/pi433: Fixing coding guidelines

Fix brace style of if-else case Signed-off-by: Pushkar Jambhlekar --- drivers/staging/pi433/pi433_if.c | 162 +-- 1 file changed, 54 insertions(+), 108 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c

[PATCH] drivers/staging/pi433: Fixing coding guidelines

Fix brace style of if-else case Signed-off-by: Pushkar Jambhlekar --- drivers/staging/pi433/pi433_if.c | 162 +-- 1 file changed, 54 insertions(+), 108 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

Hi Baoquan, At 09/06/2017 01:26 PM, Baoquan He wrote: [...] static void __init smp_cpu_index_default(void) @@ -1335,19 +1295,20 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) Please also cleanup the passed in max_cpus since it's not used here any more. And up to the caller:

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

Hi Baoquan, At 09/06/2017 01:26 PM, Baoquan He wrote: [...] static void __init smp_cpu_index_default(void) @@ -1335,19 +1295,20 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) Please also cleanup the passed in max_cpus since it's not used here any more. And up to the caller:

Re: [PATCH v2 0/8] MT2712 IOMMU SUPPORT

On Tue, 2017-08-22 at 22:38 +0800, Joerg Roedel wrote: > On Mon, Aug 21, 2017 at 07:00:13PM +0800, Yong Wu wrote: > > Yong Wu (8): > > dt-bindings: mediatek: Add binding for mt2712 IOMMU and SMI > > iommu/mediatek: Move MTK_M4U_TO_LARB/PORT into mtk_iommu.c > > iommu/mediatek: Add mt2712

Re: [PATCH v2 0/8] MT2712 IOMMU SUPPORT

On Tue, 2017-08-22 at 22:38 +0800, Joerg Roedel wrote: > On Mon, Aug 21, 2017 at 07:00:13PM +0800, Yong Wu wrote: > > Yong Wu (8): > > dt-bindings: mediatek: Add binding for mt2712 IOMMU and SMI > > iommu/mediatek: Move MTK_M4U_TO_LARB/PORT into mtk_iommu.c > > iommu/mediatek: Add mt2712

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

CC Catalin On 2017/9/6 2:58, gengdongjiu wrote: > when exit from guest, some host PSTATE bits may be lost, such as > PSTATE.PAN or PSTATE.UAO. It is because host and hypervisor all run > in the EL2, host PSTATE value cannot be saved and restored via > SPSR_EL2. So if guest has changed the

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

CC Catalin On 2017/9/6 2:58, gengdongjiu wrote: > when exit from guest, some host PSTATE bits may be lost, such as > PSTATE.PAN or PSTATE.UAO. It is because host and hypervisor all run > in the EL2, host PSTATE value cannot be saved and restored via > SPSR_EL2. So if guest has changed the

Re: [RFC v2 6/6] platform/x86: intel_pmc_ipc: Use generic Intel IPC device calls

Hi Lee, On 9/5/2017 12:38 AM, Lee Jones wrote: On Sat, 02 Sep 2017, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Removed redundant IPC helper functions and refactored the driver to use generic IPC device

Re: [RFC v2 6/6] platform/x86: intel_pmc_ipc: Use generic Intel IPC device calls

Hi Lee, On 9/5/2017 12:38 AM, Lee Jones wrote: On Sat, 02 Sep 2017, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Removed redundant IPC helper functions and refactored the driver to use generic IPC device driver APIs. This patch also cleans-up PMC IPC

[PATCH 3/3] locking/rwsem/x86: Add stack frame dependency for __downgrade_write()

kernel/locking/rwsem.o: warning: objtool: downgrade_write()+0x22: call without frame pointer save/setup The warning means gcc 7.2.0 placed the __downgrade_write() inline asm (and its call instruction) before the frame pointer setup in downgrade_write(), which breaks frame pointer convention and

[PATCH 0/3] locking/rwsem/x86: Add stack frame dependency for some inline asm

Some warning were showed by objtool using gcc 7.2.0 kernel/locking/rwsem.o: warning: objtool: up_read()+0x11: call without frame pointer save/setup kernel/locking/rwsem.o: warning: objtool: up_write()+0x17: call without frame pointer save/setup kernel/locking/rwsem.o: warning: objtool:

[PATCH 3/3] locking/rwsem/x86: Add stack frame dependency for __downgrade_write()

kernel/locking/rwsem.o: warning: objtool: downgrade_write()+0x22: call without frame pointer save/setup The warning means gcc 7.2.0 placed the __downgrade_write() inline asm (and its call instruction) before the frame pointer setup in downgrade_write(), which breaks frame pointer convention and

[PATCH 0/3] locking/rwsem/x86: Add stack frame dependency for some inline asm

Some warning were showed by objtool using gcc 7.2.0 kernel/locking/rwsem.o: warning: objtool: up_read()+0x11: call without frame pointer save/setup kernel/locking/rwsem.o: warning: objtool: up_write()+0x17: call without frame pointer save/setup kernel/locking/rwsem.o: warning: objtool:

[PATCH 2/3] locking/rwsem/x86: Add stack frame dependency for __up_write()

kernel/locking/rwsem.o: warning: objtool: up_write()+0x17: call without frame pointer save/setup The warning means gcc 7.2.0 placed the __up_write() inline asm (and its call instruction) before the frame pointer setup in up_write(), which breaks frame pointer convention and can result in

[PATCH 1/3] locking/rwsem/x86: Add stack frame dependency for __up_read()

kernel/locking/rwsem.o: warning: objtool: up_read()+0x11: call without frame pointer save/setup The warning means gcc 7.2.0 placed the __up_read() inline asm (and its call instruction) before the frame pointer setup in up_read(), which breaks frame pointer convention and can result in incorrect

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/06/17 at 12:25pm, Baoquan He wrote: > On 08/28/17 at 11:20am, Dou Liyang wrote: > > - /* > > * Should not be necessary because the MP table should list the boot > > * CPU too, but we do it for the sake of robustness anyway. > > */ > > @@ -1254,29 +1237,6 @@ static int __init

[PATCH 2/3] locking/rwsem/x86: Add stack frame dependency for __up_write()

kernel/locking/rwsem.o: warning: objtool: up_write()+0x17: call without frame pointer save/setup The warning means gcc 7.2.0 placed the __up_write() inline asm (and its call instruction) before the frame pointer setup in up_write(), which breaks frame pointer convention and can result in

[PATCH 1/3] locking/rwsem/x86: Add stack frame dependency for __up_read()

kernel/locking/rwsem.o: warning: objtool: up_read()+0x11: call without frame pointer save/setup The warning means gcc 7.2.0 placed the __up_read() inline asm (and its call instruction) before the frame pointer setup in up_read(), which breaks frame pointer convention and can result in incorrect

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/06/17 at 12:25pm, Baoquan He wrote: > On 08/28/17 at 11:20am, Dou Liyang wrote: > > - /* > > * Should not be necessary because the MP table should list the boot > > * CPU too, but we do it for the sake of robustness anyway. > > */ > > @@ -1254,29 +1237,6 @@ static int __init

Re: [PATCH v3 2/3] arm: dts: add Nuvoton NPCM750 device tree

On Wed, Sep 6, 2017 at 10:00 AM, Brendan Higgins wrote: > +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.txt > @@ -0,0 +1,6 @@ > +NPCM Platforms Device Tree Bindings > +--- > +NPCM750 SoC > +Required root node properties: > +

Re: [PATCH v3 2/3] arm: dts: add Nuvoton NPCM750 device tree

On Wed, Sep 6, 2017 at 10:00 AM, Brendan Higgins wrote: > +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.txt > @@ -0,0 +1,6 @@ > +NPCM Platforms Device Tree Bindings > +--- > +NPCM750 SoC > +Required root node properties: > + - compatible =

Abysmal scheduler performance in Linus' tree?

I'm running e7d0c41ecc2e372a81741a30894f556afec24315 from Linus' tree today, and I'm seeing abysmal scheduler performance. Running make -j4 ends up with all the tasks on CPU 3 most of the time (on my 4-logical-thread laptop). taskset -c 0 whatever puts whatever on CPU 0, but plain while true; do

Abysmal scheduler performance in Linus' tree?

I'm running e7d0c41ecc2e372a81741a30894f556afec24315 from Linus' tree today, and I'm seeing abysmal scheduler performance. Running make -j4 ends up with all the tasks on CPU 3 most of the time (on my 4-logical-thread laptop). taskset -c 0 whatever puts whatever on CPU 0, but plain while true; do

[PATCH v2] arm: dts: artpec6: Remove unnecessary interrupt-parent property from sub-nodes

net. Signed-off-by: Surender Polsani <surend...@techveda.org> Acked-by: Niklas Cassel <niklas.cas...@axis.com> --- Changes for v2: - Done few changes as suggested by Niklas Cassel. - Patch is rebased and built(ARCH=arm) on latest next-20170905. --- arch/arm/boot/dts/artpec6.dtsi | 3 ---

[PATCH v2] arm: dts: artpec6: Remove unnecessary interrupt-parent property from sub-nodes

ani Acked-by: Niklas Cassel --- Changes for v2: - Done few changes as suggested by Niklas Cassel. - Patch is rebased and built(ARCH=arm) on latest next-20170905. --- arch/arm/boot/dts/artpec6.dtsi | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/ar

UBSAN: Undefined error in log2.h

Hi, I am hitting this bug when running the syzkaller fuzzer on kernel 4.13-rc7 Syzkaller hit 'UBSAN: Undefined behaviour in ./include/linux/log2.h:LINE' bug. Guilty file: fs/pipe.c Maintainers: [] UBSAN: Undefined behaviour in ./include/linux/log2.h:57:13 shift exponent 64 is too large for

UBSAN: Undefined error in log2.h

Hi, I am hitting this bug when running the syzkaller fuzzer on kernel 4.13-rc7 Syzkaller hit 'UBSAN: Undefined behaviour in ./include/linux/log2.h:LINE' bug. Guilty file: fs/pipe.c Maintainers: [] UBSAN: Undefined behaviour in ./include/linux/log2.h:57:13 shift exponent 64 is too large for

Re: UBSAN: Undefined error in time.h signed integer overflow

On Tue, Sep 5, 2017 at 9:30 PM, Shankara Pailoor wrote: > Hi, > > I encountered this bug while fuzzing linux kernel 4.13-rc7 with syzkaller. > > > UBSAN: Undefined behaviour in

Re: UBSAN: Undefined error in time.h signed integer overflow

On Tue, Sep 5, 2017 at 9:30 PM, Shankara Pailoor wrote: > Hi, > > I encountered this bug while fuzzing linux kernel 4.13-rc7 with syzkaller. > > > UBSAN: Undefined behaviour in ./include/linux/time.h:233:27 > signed

[PATCH 1/2] mm/slub: wake up kswapd for initial high order allocation

From: Joonsoo Kim slub uses higher order allocation than it actually needs. In this case, we don't want to do direct reclaim to make such a high order page since it causes a big latency to the user. Instead, we would like to fallback lower order allocation that it

[PATCH 2/2] mm/slub: don't use reserved memory for optimistic try

From: Joonsoo Kim High-order atomic allocation is difficult to succeed since we cannot reclaim anything in this context. So, we reserves the pageblock for this kind of request. In slub, we try to allocate higher-order page more than it actually needs in order to get the

[PATCH 1/2] mm/slub: wake up kswapd for initial high order allocation

From: Joonsoo Kim slub uses higher order allocation than it actually needs. In this case, we don't want to do direct reclaim to make such a high order page since it causes a big latency to the user. Instead, we would like to fallback lower order allocation that it actually needs. However, we

[PATCH 2/2] mm/slub: don't use reserved memory for optimistic try

From: Joonsoo Kim High-order atomic allocation is difficult to succeed since we cannot reclaim anything in this context. So, we reserves the pageblock for this kind of request. In slub, we try to allocate higher-order page more than it actually needs in order to get the best performance. If

[PATCH] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

From: Joonsoo Kim Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that important to reserve. When ZONE_MOVABLE is used, this problem would theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE allocation request which is mainly used

[PATCH] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request

From: Joonsoo Kim Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that important to reserve. When ZONE_MOVABLE is used, this problem would theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE allocation request which is mainly used for page cache and anon

UBSAN: Undefined error in time.h signed integer overflow

Hi, I encountered this bug while fuzzing linux kernel 4.13-rc7 with syzkaller. UBSAN: Undefined behaviour in ./include/linux/time.h:233:27 signed integer overflow: 8391720337152500783 * 10 cannot be

UBSAN: Undefined error in time.h signed integer overflow

Hi, I encountered this bug while fuzzing linux kernel 4.13-rc7 with syzkaller. UBSAN: Undefined behaviour in ./include/linux/time.h:233:27 signed integer overflow: 8391720337152500783 * 10 cannot be

Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU

On Wed, Sep 06, 2017 at 12:57:41AM +0200, Thomas Gleixner wrote: > On Sun, 3 Sep 2017, Thomas Gleixner wrote: > > > On Fri, 1 Sep 2017, Chen Yu wrote: > > > > > This is the major logic to spread the vectors on different CPUs. > > > The main idea is to choose the 'idlest' CPU which has assigned >

Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU

On Wed, Sep 06, 2017 at 12:57:41AM +0200, Thomas Gleixner wrote: > On Sun, 3 Sep 2017, Thomas Gleixner wrote: > > > On Fri, 1 Sep 2017, Chen Yu wrote: > > > > > This is the major logic to spread the vectors on different CPUs. > > > The main idea is to choose the 'idlest' CPU which has assigned >

Re: [PATCH 23/25 v3] ALSA/dummy: Replace tasklet with softirq hrtimer

On Sep 6 2017 01:18, Sebastian Andrzej Siewior wrote: From: Thomas Gleixner The tasklet is used to defer the execution of snd_pcm_period_elapsed() to the softirq context. Using the CLOCK_MONOTONIC_SOFT base invokes the timer callback in softirq context as well which renders

Re: [PATCH 23/25 v3] ALSA/dummy: Replace tasklet with softirq hrtimer

On Sep 6 2017 01:18, Sebastian Andrzej Siewior wrote: From: Thomas Gleixner The tasklet is used to defer the execution of snd_pcm_period_elapsed() to the softirq context. Using the CLOCK_MONOTONIC_SOFT base invokes the timer callback in softirq context as well which renders the tasklet

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 08/28/17 at 11:20am, Dou Liyang wrote: > Calling native_smp_prepare_cpus() to prepare for SMP bootup, does > some sanity checking, enables APIC mode and disables SMP feature. > > Now, APIC mode setup has been unified to apic_intr_mode_init(), > some sanity checks are redundant and need to be

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 08/28/17 at 11:20am, Dou Liyang wrote: > Calling native_smp_prepare_cpus() to prepare for SMP bootup, does > some sanity checking, enables APIC mode and disables SMP feature. > > Now, APIC mode setup has been unified to apic_intr_mode_init(), > some sanity checks are redundant and need to be

Re: [PATCH] gpio: thunderx: select IRQ_DOMAIN_HIERARCHY instead of depends on

Hi David, 2017-09-06 11:09 GMT+09:00 David Daney : > On 09/05/2017 06:40 PM, Masahiro Yamada wrote: >> >> IRQ_DOMAIN_HIERARCHY is not user-configurable, but supposed to be >> selected by drivers that need IRQ domain hierarchy support. >> >> GPIO_THUNDERX is the only

Re: [PATCH] gpio: thunderx: select IRQ_DOMAIN_HIERARCHY instead of depends on

Hi David, 2017-09-06 11:09 GMT+09:00 David Daney : > On 09/05/2017 06:40 PM, Masahiro Yamada wrote: >> >> IRQ_DOMAIN_HIERARCHY is not user-configurable, but supposed to be >> selected by drivers that need IRQ domain hierarchy support. >> >> GPIO_THUNDERX is the only user of "depends on

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi Baoquan, Thanks for your reply! My answer is in below. At 09/06/2017 08:55 AM, Baoquan He wrote: Hi Liyang, On 08/28/17 at 11:20am, Dou Liyang wrote: Now, there are many switches in kernel which are used to determine the final interrupt delivery mode, as shown below: 1) kconfig:

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi Baoquan, Thanks for your reply! My answer is in below. At 09/06/2017 08:55 AM, Baoquan He wrote: Hi Liyang, On 08/28/17 at 11:20am, Dou Liyang wrote: Now, there are many switches in kernel which are used to determine the final interrupt delivery mode, as shown below: 1) kconfig:

Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU

Thanks for looking at this, (please bear my slow response as I need to check related code before replying.) On Sun, Sep 03, 2017 at 08:17:04PM +0200, Thomas Gleixner wrote: > On Fri, 1 Sep 2017, Chen Yu wrote: > > > This is the major logic to spread the vectors on different CPUs. > > The main

Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU

Thanks for looking at this, (please bear my slow response as I need to check related code before replying.) On Sun, Sep 03, 2017 at 08:17:04PM +0200, Thomas Gleixner wrote: > On Fri, 1 Sep 2017, Chen Yu wrote: > > > This is the major logic to spread the vectors on different CPUs. > > The main

[PATCH 1/1] workqueue: use type int instead of bool to index array

From: zijun_hu type bool is used to index three arrays in alloc_and_link_pwqs() it doesn't look like conventional. it is fixed by using type int to index the relevant arrays. Signed-off-by: zijun_hu --- kernel/workqueue.c | 9 + 1 file changed, 5

[PATCH 1/1] workqueue: use type int instead of bool to index array

From: zijun_hu type bool is used to index three arrays in alloc_and_link_pwqs() it doesn't look like conventional. it is fixed by using type int to index the relevant arrays. Signed-off-by: zijun_hu --- kernel/workqueue.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff

Re: [PATCH 3/3] f2fs: support flexible inline xattr size

Hi Jaegeuk, Do we have time to test and stabilize this new feature before merge window? Thanks, On 2017/9/4 18:58, Chao Yu wrote: > Now, in product, more and more features based on file encryption were > introduced, their demand of xattr space is increasing, however, inline > xattr has

SME/32-bit regression

It appears there is a regression for 32-bit kernels due to SME changes. I bisected my particular problem (Xen PV guest) to 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() errors on baremetal. This seems to be caused by sme_me_mask being an unsigned long as opposed to

Re: [PATCH 3/3] f2fs: support flexible inline xattr size

Hi Jaegeuk, Do we have time to test and stabilize this new feature before merge window? Thanks, On 2017/9/4 18:58, Chao Yu wrote: > Now, in product, more and more features based on file encryption were > introduced, their demand of xattr space is increasing, however, inline > xattr has

SME/32-bit regression

It appears there is a regression for 32-bit kernels due to SME changes. I bisected my particular problem (Xen PV guest) to 21729f81ce8ae76a6995681d40e16f7ce8075db4 but I also saw pmd_clear_bad() errors on baremetal. This seems to be caused by sme_me_mask being an unsigned long as opposed to

[PATCH 3/3] KVM: SVM: Add irqchip_split() checks before enabling AVIC

SVM AVIC hardware accelerates guest write to APIC_EOI register (for edge-trigger interrupt), which means it does not trap to KVM. So, only enable SVM AVIC only in split irqchip mode. (e.g. launching qemu w/ option '-machine kernel_irqchip=split'). Suggested-by: Paolo Bonzini

[PATCH 3/3] KVM: SVM: Add irqchip_split() checks before enabling AVIC

SVM AVIC hardware accelerates guest write to APIC_EOI register (for edge-trigger interrupt), which means it does not trap to KVM. So, only enable SVM AVIC only in split irqchip mode. (e.g. launching qemu w/ option '-machine kernel_irqchip=split'). Suggested-by: Paolo Bonzini Signed-off-by:

kvm: use-after-free in irq_bypass_register_consumer

Got the following report while fuzzing 4.9.47. It seems that this bug has been reported by Dmitry Vyukov [https://lkml.org/lkml/2017/1/27/828] But I still can reproduce the bug on latest Ubuntu1604 (4.4.0-94-generic) PoC:

kvm: use-after-free in irq_bypass_register_consumer

Got the following report while fuzzing 4.9.47. It seems that this bug has been reported by Dmitry Vyukov [https://lkml.org/lkml/2017/1/27/828] But I still can reproduce the bug on latest Ubuntu1604 (4.4.0-94-generic) PoC:

[PATCH 2/3] KVM: Add struct kvm_vcpu pointer parameter to get_enable_apicv()

Modify struct kvm_x86_ops.arch.apicv_active() to take struct kvm_vcpu pointer as parameter in preparation to subsequent changes. Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/svm.c | 2 +-

[PATCH 2/3] KVM: Add struct kvm_vcpu pointer parameter to get_enable_apicv()

Modify struct kvm_x86_ops.arch.apicv_active() to take struct kvm_vcpu pointer as parameter in preparation to subsequent changes. Signed-off-by: Suravee Suthikulpanit --- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/svm.c | 2 +- arch/x86/kvm/vmx.c | 2 +-

[PATCH 1/3] KVM: SVM: Refactor AVIC vcpu initialization into avic_init_vcpu()

Preparing the base code for subsequent changes. This does not change existing logic. Signed-off-by: Suravee Suthikulpanit --- arch/x86/kvm/svm.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/svm.c

[PATCH 1/3] KVM: SVM: Refactor AVIC vcpu initialization into avic_init_vcpu()

Preparing the base code for subsequent changes. This does not change existing logic. Signed-off-by: Suravee Suthikulpanit --- arch/x86/kvm/svm.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index

[PATCH 0/3] KVM: SVM: Fix guest not booting w/ AVIC enabled

Certain QEMU options fails to boot VM guest w/ SVM AVIC enabled (e.g. modprobe kvm_amd avic=1). Investigation shows that this mainly due to AVIC hardware does not trap into hypervisor when guest OS writes to APIC_EOI register. The boot hang is caused by missing timer interrupt when using

[PATCH 0/3] KVM: SVM: Fix guest not booting w/ AVIC enabled

Certain QEMU options fails to boot VM guest w/ SVM AVIC enabled (e.g. modprobe kvm_amd avic=1). Investigation shows that this mainly due to AVIC hardware does not trap into hypervisor when guest OS writes to APIC_EOI register. The boot hang is caused by missing timer interrupt when using

Re: [PATCH RFC v3 0/4] Add cross-compilation support to eBPF samples

Hi Alexei, On Tue, Sep 5, 2017 at 8:24 PM, Alexei Starovoitov wrote: > On Sun, Sep 03, 2017 at 11:23:21AM -0700, Joel Fernandes wrote: >> These patches fix issues seen when cross-compiling eBPF samples on arm64. >> Compared to [1], I dropped the controversial

Re: [PATCH RFC v3 0/4] Add cross-compilation support to eBPF samples

Hi Alexei, On Tue, Sep 5, 2017 at 8:24 PM, Alexei Starovoitov wrote: > On Sun, Sep 03, 2017 at 11:23:21AM -0700, Joel Fernandes wrote: >> These patches fix issues seen when cross-compiling eBPF samples on arm64. >> Compared to [1], I dropped the controversial inline-asm patch pending further >>

Re: [PATCH RFC v3 0/4] Add cross-compilation support to eBPF samples

On Sun, Sep 03, 2017 at 11:23:21AM -0700, Joel Fernandes wrote: > These patches fix issues seen when cross-compiling eBPF samples on arm64. > Compared to [1], I dropped the controversial inline-asm patch pending further > discussion on the right way to do it. However these patches are still a step

Re: [PATCH RFC v3 0/4] Add cross-compilation support to eBPF samples

On Sun, Sep 03, 2017 at 11:23:21AM -0700, Joel Fernandes wrote: > These patches fix issues seen when cross-compiling eBPF samples on arm64. > Compared to [1], I dropped the controversial inline-asm patch pending further > discussion on the right way to do it. However these patches are still a step

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 2017/9/6 11:10, Jaegeuk Kim wrote: > On 09/06, Chao Yu wrote: >> On 2017/9/6 5:06, Jaegeuk Kim wrote: >>> This patch fixes bavail and bfree finally. >>> >>> longf_bfree;/* free blocks in fs */ >>> longf_bavail; /* free blocks avail to non-superuser */ >>> >>> So, bfree represents

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 2017/9/6 11:10, Jaegeuk Kim wrote: > On 09/06, Chao Yu wrote: >> On 2017/9/6 5:06, Jaegeuk Kim wrote: >>> This patch fixes bavail and bfree finally. >>> >>> longf_bfree;/* free blocks in fs */ >>> longf_bavail; /* free blocks avail to non-superuser */ >>> >>> So, bfree represents

Re: [f2fs-dev] [PATCH 2/2] f2fs: use generic terms used for encrypted block management

On 2017/9/6 8:15, Jaegeuk Kim wrote: > This patch renames functions regarding to buffer management via META_MAPPING > used for encrypted blocks especially. We can actually use them in generic way. Meta inode cache is more like bd_inode cache now. ;) Reviewed-by: Chao Yu

Re: [PATCH] md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list

> On Fri, Sep 01, 2017 at 05:26:48PM +0800, Dennis Yang wrote: > > >On Mon, Aug 28, 2017 at 08:01:59PM +0800, Dennis Yang wrote: > > >> break_stripe_batch_list() did not preserve STRIPE_ON_UNPLUG_LIST which is > > >> set when a stripe_head gets queued to the stripe_head list maintained by > > >>

Re: [f2fs-dev] [PATCH 2/2] f2fs: use generic terms used for encrypted block management

On 2017/9/6 8:15, Jaegeuk Kim wrote: > This patch renames functions regarding to buffer management via META_MAPPING > used for encrypted blocks especially. We can actually use them in generic way. Meta inode cache is more like bd_inode cache now. ;) Reviewed-by: Chao Yu Thanks, > >

Re: [PATCH] md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list

> On Fri, Sep 01, 2017 at 05:26:48PM +0800, Dennis Yang wrote: > > >On Mon, Aug 28, 2017 at 08:01:59PM +0800, Dennis Yang wrote: > > >> break_stripe_batch_list() did not preserve STRIPE_ON_UNPLUG_LIST which is > > >> set when a stripe_head gets queued to the stripe_head list maintained by > > >>

Re: [PATCH v3 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode

On 9/4/17 1:36 AM, Haishuang Yan wrote: In collect_md mode, if the tun dev is down, it still can call __ip6_tnl_rcv to receive on packets, and the rx statistics increase improperly. Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels") Cc: Alexei Starovoitov

Re: [PATCH v3 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode

On 9/4/17 1:36 AM, Haishuang Yan wrote: In collect_md mode, if the tun dev is down, it still can call __ip6_tnl_rcv to receive on packets, and the rx statistics increase improperly. Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels") Cc: Alexei Starovoitov Signed-off-by:

Re: [f2fs-dev] [PATCH 1/2] f2fs: introduce f2fs_encrypted_file for clean-up

On 2017/9/6 8:15, Jaegeuk Kim wrote: > This patch replaces (f2fs_encrypted_inode() && S_ISREG()) with > f2fs_encrypted_file(), which gives no functional change. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks, > --- > fs/f2fs/data.c | 10

Re: [f2fs-dev] [PATCH 1/2] f2fs: introduce f2fs_encrypted_file for clean-up

On 2017/9/6 8:15, Jaegeuk Kim wrote: > This patch replaces (f2fs_encrypted_inode() && S_ISREG()) with > f2fs_encrypted_file(), which gives no functional change. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks, > --- > fs/f2fs/data.c | 10 +- > fs/f2fs/f2fs.h | 5

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 09/06, Chao Yu wrote: > On 2017/9/6 5:06, Jaegeuk Kim wrote: > > This patch fixes bavail and bfree finally. > > > > longf_bfree;/* free blocks in fs */ > > longf_bavail; /* free blocks avail to non-superuser */ > > > > So, bfree represents all the reserved blocks, while bavail

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 09/06, Chao Yu wrote: > On 2017/9/6 5:06, Jaegeuk Kim wrote: > > This patch fixes bavail and bfree finally. > > > > longf_bfree;/* free blocks in fs */ > > longf_bavail; /* free blocks avail to non-superuser */ > > > > So, bfree represents all the reserved blocks, while bavail

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 2017/9/6 5:06, Jaegeuk Kim wrote: > This patch fixes bavail and bfree finally. > > longf_bfree;/* free blocks in fs */ > longf_bavail; /* free blocks avail to non-superuser */ > > So, bfree represents all the reserved blocks, while bavail does the space only > visible to normal

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 2017/9/6 5:06, Jaegeuk Kim wrote: > This patch fixes bavail and bfree finally. > > longf_bfree;/* free blocks in fs */ > longf_bavail; /* free blocks avail to non-superuser */ > > So, bfree represents all the reserved blocks, while bavail does the space only > visible to normal

[PATCH v2] md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list

In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST set, it indicates that this stripe_head is already in the raid5_plug_cb list and release_stripe() would be called instead to drop a reference count. Otherwise, the STRIPE_ON_UNPLUG_LIST bit would be set for this stripe_head

[PATCH v2] md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list

In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST set, it indicates that this stripe_head is already in the raid5_plug_cb list and release_stripe() would be called instead to drop a reference count. Otherwise, the STRIPE_ON_UNPLUG_LIST bit would be set for this stripe_head

linux-next: manual merge of the devicetree tree with Linus' tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: Documentation/devicetree/bindings/net/brcm,bgmac-nsp.txt between commit: ea6c3077678f ("dt-bindings: net: Remove duplicate NSP Ethernet MAC binding document") from Linus' tree and commit: 4da722ca19f3

linux-next: manual merge of the devicetree tree with Linus' tree

Hi Rob, Today's linux-next merge of the devicetree tree got a conflict in: Documentation/devicetree/bindings/net/brcm,bgmac-nsp.txt between commit: ea6c3077678f ("dt-bindings: net: Remove duplicate NSP Ethernet MAC binding document") from Linus' tree and commit: 4da722ca19f3

linux-next: manual merge of the devicetree tree with the sound tree

Hi all, Today's linux-next merge of the devicetree tree got a conflict in: Documentation/devicetree/bindings/sound/rockchip,pdm.txt between commit: fce7358b54c6 ("ASoC: rockchip: separate pinctrl pins from each other") from the sound tree and commit: 4da722ca19f3 ("dt-bindings: Remove

linux-next: manual merge of the devicetree tree with the sound tree

Hi all, Today's linux-next merge of the devicetree tree got a conflict in: Documentation/devicetree/bindings/sound/rockchip,pdm.txt between commit: fce7358b54c6 ("ASoC: rockchip: separate pinctrl pins from each other") from the sound tree and commit: 4da722ca19f3 ("dt-bindings: Remove

  1   2   3   4   5   6   7   8   9   10   >