[PATCH v2] perf/core: Fix updating cgroup time with descendants

From: "leilei.lin" This fix updating cgroup time when event is being scheduled in by descendants Signed-off-by: leilei.lin Reviewed-and-tested-by: Jiri Olsa --- kernel/events/core.c | 2 +- 1 file changed, 1

[PATCH v2] perf/core: Fix updating cgroup time with descendants

From: "leilei.lin" This fix updating cgroup time when event is being scheduled in by descendants Signed-off-by: leilei.lin Reviewed-and-tested-by: Jiri Olsa --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c

Re: [Part1 PATCH v5 16/17] X86/KVM: Decrypt shared per-cpu variables when SEV is active

On Wed, Sep 27, 2017 at 10:13:28AM -0500, Brijesh Singh wrote: > When SEV is active, guest memory is encrypted with a guest-specific key, a > guest memory region shared with the hypervisor must be mapped as decrypted > before we can share it. > > Cc: Thomas Gleixner > Cc:

Re: [Part1 PATCH v5 16/17] X86/KVM: Decrypt shared per-cpu variables when SEV is active

On Wed, Sep 27, 2017 at 10:13:28AM -0500, Brijesh Singh wrote: > When SEV is active, guest memory is encrypted with a guest-specific key, a > guest memory region shared with the hypervisor must be mapped as decrypted > before we can share it. > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H.

linux-next: Tree for Sep 29

Hi all, News: I will not be doing linux-next releases from Setp 30 to Oct 30 (inclusive). Changes since 20170928: The net-next tree gained a build failure, due to in interaction with the net tree, for which I applied a merge fix patch. The drm tree still had its build failure for which I

linux-next: Tree for Sep 29

Hi all, News: I will not be doing linux-next releases from Setp 30 to Oct 30 (inclusive). Changes since 20170928: The net-next tree gained a build failure, due to in interaction with the net tree, for which I applied a merge fix patch. The drm tree still had its build failure for which I

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

On 28-09-2017 18:35, Raj, Ashok wrote: > Thanks for trying that Harsh. > > sp_off turns of super page support. Which this mode, do you still see offsets > greater than 4k? Yes, offset greater than 4k is still there. Refer below. [56732.774872] offset 4110 len 76 dma addr 3a531200e dma len 76

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

On 28-09-2017 18:35, Raj, Ashok wrote: > Thanks for trying that Harsh. > > sp_off turns of super page support. Which this mode, do you still see offsets > greater than 4k? Yes, offset greater than 4k is still there. Refer below. [56732.774872] offset 4110 len 76 dma addr 3a531200e dma len 76

[PATCH] nvme-pci: Use PCI bus address for data/queues in CMB

Currently, NVMe PCI host driver is programming CMB dma address as I/O SQs addresses. This results in failures on systems where 1:1 outbound mapping is not used (example Broadcom iProc SOCs) because CMB BAR will be progammed with PCI bus address but NVMe PCI EP will try to access CMB using dma

[PATCH] nvme-pci: Use PCI bus address for data/queues in CMB

Currently, NVMe PCI host driver is programming CMB dma address as I/O SQs addresses. This results in failures on systems where 1:1 outbound mapping is not used (example Broadcom iProc SOCs) because CMB BAR will be progammed with PCI bus address but NVMe PCI EP will try to access CMB using dma

Re: [PATCH 10/12] writeback: only allow one inflight and pending full flush

On Fri, Sep 29, 2017 at 3:17 AM, Jens Axboe wrote: > On 09/28/2017 11:44 PM, Linus Torvalds wrote: >> On Thu, Sep 28, 2017 at 2:41 PM, Andrew Morton >> wrote: >>> >>> test_and_set_bit()? >> >> If there aren't any atomicity concerns (either because of

Re: [PATCH 10/12] writeback: only allow one inflight and pending full flush

On Fri, Sep 29, 2017 at 3:17 AM, Jens Axboe wrote: > On 09/28/2017 11:44 PM, Linus Torvalds wrote: >> On Thu, Sep 28, 2017 at 2:41 PM, Andrew Morton >> wrote: >>> >>> test_and_set_bit()? >> >> If there aren't any atomicity concerns (either because of higher-level >> locking, or because racing

[PATCH] usb: dwc3: workaround: disable device-initiated U1/U2

Issue: When the USB controller is configured as a USB device mode, the device initiates low power when an ACK is pending for a data packet (DP). When operating in SuperSpeed mode and when the internal condition for low power (u1/u2) is satisfied, the device initiates u1/u2 even though it has just

[PATCH] usb: dwc3: workaround: disable device-initiated U1/U2

Issue: When the USB controller is configured as a USB device mode, the device initiates low power when an ACK is pending for a data packet (DP). When operating in SuperSpeed mode and when the internal condition for low power (u1/u2) is satisfied, the device initiates u1/u2 even though it has just

Re: [PATCH] ratelimit: use deferred printk() version

Hello, (Cc-ing Andrew lkml.kernel.org/r/20170928120405.18273-1-sergey.senozhat...@gmail.com ) On (09/28/17 21:13), Sergey Senozhatsky wrote: > (Cc-ing Sasha) > > On (09/28/17 21:04), Sergey Senozhatsky wrote: > [..] > > : process 9121 (trinity-c78) no longer affine to cpu8 > > : smpboot:

Re: [PATCH] extcon: Split out extcon header file for consumer and provider device

Hi, On 2017년 09월 29일 11:03, Yoshihiro Shimoda wrote: > Hi, > >> From: Chanwoo Choi >> Sent: Friday, September 29, 2017 9:02 AM >> > < snip > >> drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +- > < snip > >> drivers/usb/gadget/udc/renesas_usb3.c | 2 +- > > These two drivers

Re: [PATCH] ratelimit: use deferred printk() version

Hello, (Cc-ing Andrew lkml.kernel.org/r/20170928120405.18273-1-sergey.senozhat...@gmail.com ) On (09/28/17 21:13), Sergey Senozhatsky wrote: > (Cc-ing Sasha) > > On (09/28/17 21:04), Sergey Senozhatsky wrote: > [..] > > : process 9121 (trinity-c78) no longer affine to cpu8 > > : smpboot:

Re: [PATCH] extcon: Split out extcon header file for consumer and provider device

Hi, On 2017년 09월 29일 11:03, Yoshihiro Shimoda wrote: > Hi, > >> From: Chanwoo Choi >> Sent: Friday, September 29, 2017 9:02 AM >> > < snip > >> drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +- > < snip > >> drivers/usb/gadget/udc/renesas_usb3.c | 2 +- > > These two drivers

[PATCH] zsmalloc: calling zs_map_object() from irq is a bug

Use BUG_ON(in_interrupt()) in zs_map_object(). This is not a new BUG_ON(), it's always been there, but was recently changed to VM_BUG_ON(). There are several problems there. First, we use use per-CPU mappings both in zsmalloc and in zram, and interrupt may easily corrupt those buffers. Second, and

[PATCH] zsmalloc: calling zs_map_object() from irq is a bug

Use BUG_ON(in_interrupt()) in zs_map_object(). This is not a new BUG_ON(), it's always been there, but was recently changed to VM_BUG_ON(). There are several problems there. First, we use use per-CPU mappings both in zsmalloc and in zram, and interrupt may easily corrupt those buffers. Second, and

[PATCH] USB: serial: qcserial: add Dell DW5818, DW5819

Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74 series which will by default boot with vid 0x413c and pid's 0x81cf, 0x81d0, 0x81d1,0x81d2. Signed-off-by: Shrirang Bagul --- drivers/usb/serial/qcserial.c | 4 1 file changed, 4 insertions(+)

[PATCH] USB: serial: qcserial: add Dell DW5818, DW5819

Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74 series which will by default boot with vid 0x413c and pid's 0x81cf, 0x81d0, 0x81d1,0x81d2. Signed-off-by: Shrirang Bagul --- drivers/usb/serial/qcserial.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v2] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

Replace instances of drm_framebuffer_reference/unreference() with *_get/put() suffixes and drm_dev_unref with *_put() suffix because get/put is shorter and consistent with the kernel use of *_get/put suffixes. Done with following coccinelle semantic patch @@ expression ex; @@ (

[PATCH v2] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

Replace instances of drm_framebuffer_reference/unreference() with *_get/put() suffixes and drm_dev_unref with *_put() suffix because get/put is shorter and consistent with the kernel use of *_get/put suffixes. Done with following coccinelle semantic patch @@ expression ex; @@ (

Re: [virtio-dev] Re: [PATCH v15 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

On Fri, Sep 08, 2017 at 07:09:24PM +0800, Wei Wang wrote: > On 09/08/2017 11:36 AM, Michael S. Tsirkin wrote: > > On Tue, Aug 29, 2017 at 11:09:18AM +0800, Wei Wang wrote: > > > On 08/29/2017 02:03 AM, Michael S. Tsirkin wrote: > > > > On Mon, Aug 28, 2017 at 06:08:31PM +0800, Wei Wang wrote: > >

Re: [virtio-dev] Re: [PATCH v15 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

On Fri, Sep 08, 2017 at 07:09:24PM +0800, Wei Wang wrote: > On 09/08/2017 11:36 AM, Michael S. Tsirkin wrote: > > On Tue, Aug 29, 2017 at 11:09:18AM +0800, Wei Wang wrote: > > > On 08/29/2017 02:03 AM, Michael S. Tsirkin wrote: > > > > On Mon, Aug 28, 2017 at 06:08:31PM +0800, Wei Wang wrote: > >

Re: Kernel panic - not syncing: Fatal exception in interrupt (file_free_rcu+0x14)

On Thu, Sep 28, 2017 at 8:32 PM, Kyle Sanderson wrote: > Not sure if the stack is crap or not, but this looks like an RCU crash? > > https://i.imgur.com/sBnNe1p.jpg Hmm. Not the clearest picture, and the "Code:" line in particular is missing the interesting part, but at a

Re: Kernel panic - not syncing: Fatal exception in interrupt (file_free_rcu+0x14)

On Thu, Sep 28, 2017 at 8:32 PM, Kyle Sanderson wrote: > Not sure if the stack is crap or not, but this looks like an RCU crash? > > https://i.imgur.com/sBnNe1p.jpg Hmm. Not the clearest picture, and the "Code:" line in particular is missing the interesting part, but at a guess it's taking a

[PATCH] ASoC: rockchip: Fix wrong allocation size of dapm routes

The allocation size of dapm routes is wrong, correct it. Fixes: d9f9c167edae ("ASoC: rockchip: Init dapm routes dynamically") Signed-off-by: Jeffy Chen --- sound/soc/rockchip/rk3399_gru_sound.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH] ASoC: rockchip: Fix wrong allocation size of dapm routes

The allocation size of dapm routes is wrong, correct it. Fixes: d9f9c167edae ("ASoC: rockchip: Init dapm routes dynamically") Signed-off-by: Jeffy Chen --- sound/soc/rockchip/rk3399_gru_sound.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

Kernel panic - not syncing: Fatal exception in interrupt (file_free_rcu+0x14)

Not sure if the stack is crap or not, but this looks like an RCU crash? https://i.imgur.com/sBnNe1p.jpg Kyle. FileServer ~ # uname -a Linux FileServer.OpenWRT.local 4.12.5-gentoo #1 SMP PREEMPT Fri Aug 18 17:23:00 PDT 2017 x86_64 Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux

Kernel panic - not syncing: Fatal exception in interrupt (file_free_rcu+0x14)

Not sure if the stack is crap or not, but this looks like an RCU crash? https://i.imgur.com/sBnNe1p.jpg Kyle. FileServer ~ # uname -a Linux FileServer.OpenWRT.local 4.12.5-gentoo #1 SMP PREEMPT Fri Aug 18 17:23:00 PDT 2017 x86_64 Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux

[PATCH 1/7] regulator: axp20x: Fix poly-phase bit offset for AXP803 DCDC5/6

The bit offset used to check if DCDC5 and DCDC6 are tied together in poly-phase output is wrong. It was checking against a reserved bit, which is always false. In reality, neither the reference design layout nor actually produced boards tie these two buck regulators together. But we should still

[PATCH 1/7] regulator: axp20x: Fix poly-phase bit offset for AXP803 DCDC5/6

The bit offset used to check if DCDC5 and DCDC6 are tied together in poly-phase output is wrong. It was checking against a reserved bit, which is always false. In reality, neither the reference design layout nor actually produced boards tie these two buck regulators together. But we should still

[PATCH 4/7] ARM: dts: sunxi: Add dtsi for AXP81x PMIC

The AXP81x family of PMIC is used with the Allwinner A83T and H8 SoCs. This includes the AXP813 and AXP818. There is no discernible difference except the labeling. The AXP813 is paired with the A83T, while the AXP818 is paired with the H8. This patch adds a dtsi file for all the common bindings

[PATCH 4/7] ARM: dts: sunxi: Add dtsi for AXP81x PMIC

The AXP81x family of PMIC is used with the Allwinner A83T and H8 SoCs. This includes the AXP813 and AXP818. There is no discernible difference except the labeling. The AXP813 is paired with the A83T, while the AXP818 is paired with the H8. This patch adds a dtsi file for all the common bindings

[PATCH 2/7] regulator: axp20x: Add support for AXP813 regulators

The AXP813 PMIC has 7 DC-DC buck regulators, 16 LDOs (including the fixed RTC LDO and 2 GPIO LDOs), and 1 switchable. The drive-vbus feature is also supported. All the hardware details are very similar to the AXP803, with the following exceptions: - Extra DCDC7 buck regulator, with the same

Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively

On Thu, Sep 28, 2017 at 6:53 PM, Mimi Zohar wrote: > > The locking issue isn't with validating the file hash, but with the > setxattr, chmod, chown syscalls. Each of these syscalls takes the > i_rwsem exclusively before IMA (or EVM) is called. Read my email again. >

[PATCH 2/7] regulator: axp20x: Add support for AXP813 regulators

The AXP813 PMIC has 7 DC-DC buck regulators, 16 LDOs (including the fixed RTC LDO and 2 GPIO LDOs), and 1 switchable. The drive-vbus feature is also supported. All the hardware details are very similar to the AXP803, with the following exceptions: - Extra DCDC7 buck regulator, with the same

Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively

On Thu, Sep 28, 2017 at 6:53 PM, Mimi Zohar wrote: > > The locking issue isn't with validating the file hash, but with the > setxattr, chmod, chown syscalls. Each of these syscalls takes the > i_rwsem exclusively before IMA (or EVM) is called. Read my email again. > In setxattr, chmod, chown

[PATCH 3/7] mfd: axp20x: Add axp20x-regulator cell for AXP813

Now that axp20x-regulator supports AXP813, we can add a cell for it to enable it. Signed-off-by: Chen-Yu Tsai Tested-by: Maxime Ripard --- drivers/mfd/axp20x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mfd/axp20x.c

[PATCH 3/7] mfd: axp20x: Add axp20x-regulator cell for AXP813

Now that axp20x-regulator supports AXP813, we can add a cell for it to enable it. Signed-off-by: Chen-Yu Tsai Tested-by: Maxime Ripard --- drivers/mfd/axp20x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index 336de66ca408..2468b431bb22

[PATCH 0/7] regulator: axp20x: Add support for AXP813/818 regulators

Hi everyone, This series adds support for the X-Powers AXP813/818 [1] PMICs' regulators. The series is quite straightforward. There are no compile time dependencies between the driver patches, so each can go through their respective (mfd and regulator) trees. Patch 1 fixes a wrong bit offset for

[PATCH 7/7] ARM: dts: sun8i: a83t: allwinner-h8homlet-v2: Add AXP818 regulator nodes

This patch adds device nodes for all the regulators of the AXP818 PMIC. References to the 3V dummy regulator are replaced, and it is disabled. The 3.3V and 5V are also disabled. Signed-off-by: Chen-Yu Tsai --- .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 126

[PATCH 6/7] ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes

This patch adds device nodes for all the regulators of the AXP813 PMIC. References to the 3.3V dummy regulator are replaced, and it is disabled. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 134 ++- 1 file changed, 132

[PATCH 5/7] ARM: dts: sun8i: a83t: cubietruck-plus: Add AXP818 regulator nodes

This patch adds device nodes for all the regulators of the AXP818 PMIC. References to the 3.3V dummy regulator are replaced, and it is disabled. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 150 ++- 1 file changed, 148

[PATCH 0/7] regulator: axp20x: Add support for AXP813/818 regulators

Hi everyone, This series adds support for the X-Powers AXP813/818 [1] PMICs' regulators. The series is quite straightforward. There are no compile time dependencies between the driver patches, so each can go through their respective (mfd and regulator) trees. Patch 1 fixes a wrong bit offset for

[PATCH 7/7] ARM: dts: sun8i: a83t: allwinner-h8homlet-v2: Add AXP818 regulator nodes

This patch adds device nodes for all the regulators of the AXP818 PMIC. References to the 3V dummy regulator are replaced, and it is disabled. The 3.3V and 5V are also disabled. Signed-off-by: Chen-Yu Tsai --- .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 126 - 1

[PATCH 6/7] ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes

This patch adds device nodes for all the regulators of the AXP813 PMIC. References to the 3.3V dummy regulator are replaced, and it is disabled. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 134 ++- 1 file changed, 132 insertions(+), 2

[PATCH 5/7] ARM: dts: sun8i: a83t: cubietruck-plus: Add AXP818 regulator nodes

This patch adds device nodes for all the regulators of the AXP818 PMIC. References to the 3.3V dummy regulator are replaced, and it is disabled. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 150 ++- 1 file changed, 148 insertions(+), 2

[RFC PATCH v6 0/3] ACPI / EC: Tune the timing of EC events arrival during S3-exit

If EC events occurred during BIOS S3-exit and early OS S3-exit steps can be detected by OS earlier, then there can be less driver order issues between acpi_ec_resume() and some other drivers' .resume() hook (e.x. acpi_button_resume()). However there are known facts that EC FW does drop EC events

[RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by moving EC event handling earlier

This patch tries to detect EC events earlier after resume, so that if an event occurred before invoking acpi_ec_unblock_transactions(), it could be detected by acpi_ec_unblock_transactions() which is the earliest EC driver call after resume. However after the noirq stage, if an event ocurred

[RFC PATCH v6 2/3] ACPI / EC: Add event detection support for noirq stages

This patch adds a timer to poll EC events: 1. between acpi_ec_suspend() and acpi_ec_block_transactions(), 2. between acpi_ec_unblock_transactions() and acpi_ec_resume(). During these periods, if an EC event occurred, we have not mean to detect it. Thus the events occurred in late S3-entry could be

[RFC PATCH v6 3/3] ACPI / EC: Enable noirq stage event detection

This patch enables noirq stage event detection for the EC driver. EC is a very special driver, required to detecting events throughout the entire suspend/resume process. Thus this patch enables event detection for EC during noirq stages to meet this requirement. This is done by making sure that

[RFC PATCH v6 0/3] ACPI / EC: Tune the timing of EC events arrival during S3-exit

If EC events occurred during BIOS S3-exit and early OS S3-exit steps can be detected by OS earlier, then there can be less driver order issues between acpi_ec_resume() and some other drivers' .resume() hook (e.x. acpi_button_resume()). However there are known facts that EC FW does drop EC events

[RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by moving EC event handling earlier

This patch tries to detect EC events earlier after resume, so that if an event occurred before invoking acpi_ec_unblock_transactions(), it could be detected by acpi_ec_unblock_transactions() which is the earliest EC driver call after resume. However after the noirq stage, if an event ocurred

[RFC PATCH v6 2/3] ACPI / EC: Add event detection support for noirq stages

This patch adds a timer to poll EC events: 1. between acpi_ec_suspend() and acpi_ec_block_transactions(), 2. between acpi_ec_unblock_transactions() and acpi_ec_resume(). During these periods, if an EC event occurred, we have not mean to detect it. Thus the events occurred in late S3-entry could be

[RFC PATCH v6 3/3] ACPI / EC: Enable noirq stage event detection

This patch enables noirq stage event detection for the EC driver. EC is a very special driver, required to detecting events throughout the entire suspend/resume process. Thus this patch enables event detection for EC during noirq stages to meet this requirement. This is done by making sure that

Re: [kbuild-all] [0-Day CI notification] 0-Day kernel test service will be shut down from Sep 30 3PM to Oct 5

CC LKML. Sorry it's a site level power down during the 10.1 holidays. :( On Fri, Sep 29, 2017 at 10:12:20AM +0800, Philip Li wrote: Hi all, this is Philip who maintains the 0-Day kernel test service. Thanks for subscribing to 0-Day kernel testing. We will have lab power down from Oct 1 to Oct

Re: [kbuild-all] [0-Day CI notification] 0-Day kernel test service will be shut down from Sep 30 3PM to Oct 5

CC LKML. Sorry it's a site level power down during the 10.1 holidays. :( On Fri, Sep 29, 2017 at 10:12:20AM +0800, Philip Li wrote: Hi all, this is Philip who maintains the 0-Day kernel test service. Thanks for subscribing to 0-Day kernel testing. We will have lab power down from Oct 1 to Oct

Re: [lkp-robot] [mac80211] 31e9170bde: hwsim.sta_dynamic_down_up.fail

Thanks, I will look into it. Xiang Gao 2017-09-28 4:06 GMT-04:00 kernel test robot : > > FYI, we noticed the following commit: > > commit: 31e9170bdeb6ebe66426337b4e2b9924683a412b ("mac80211: aead api to > reduce redundancy") > url: >

Re: [lkp-robot] [mac80211] 31e9170bde: hwsim.sta_dynamic_down_up.fail

Thanks, I will look into it. Xiang Gao 2017-09-28 4:06 GMT-04:00 kernel test robot : > > FYI, we noticed the following commit: > > commit: 31e9170bdeb6ebe66426337b4e2b9924683a412b ("mac80211: aead api to > reduce redundancy") > url: >

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

Hi Steven, Peter, I'm planning to make the following changes for the next rev, could you let me know if you're Ok with it? 1. Drop the stop_critical_timings changes - previous patch was generating the preempt_enable/disable events but they aren't "real" events. Instead since we already have

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

Hi Steven, Peter, I'm planning to make the following changes for the next rev, could you let me know if you're Ok with it? 1. Drop the stop_critical_timings changes - previous patch was generating the preempt_enable/disable events but they aren't "real" events. Instead since we already have

[0-Day CI notification] 0-Day kernel test service will be shut down from Sep 30 3PM to Oct 5

Hi all, this is Philip who maintains the 0-Day kernel test service. Thanks for subscribing to 0-Day kernel testing. We will have lab power down from Oct 1 to Oct 5, so that the service will be shut down from Asia Pacific Time Sep 30 3PM and will recover from Oct 6 as soon as we can. Sorry for any

[0-Day CI notification] 0-Day kernel test service will be shut down from Sep 30 3PM to Oct 5

Hi all, this is Philip who maintains the 0-Day kernel test service. Thanks for subscribing to 0-Day kernel testing. We will have lab power down from Oct 1 to Oct 5, so that the service will be shut down from Asia Pacific Time Sep 30 3PM and will recover from Oct 6 as soon as we can. Sorry for any

Re: linux-next: build failure after merge of the net-next tree

Le 09/28/17 à 18:36, Stephen Rothwell a écrit : > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > net/dsa/slave.c: In function 'dsa_slave_create': > net/dsa/slave.c:1191:18: error: 'struct dsa_slave_priv' has no member named

Re: linux-next: build failure after merge of the net-next tree

Le 09/28/17 à 18:36, Stephen Rothwell a écrit : > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > net/dsa/slave.c: In function 'dsa_slave_create': > net/dsa/slave.c:1191:18: error: 'struct dsa_slave_priv' has no member named

Re: [PATCH for-next 2/9] RDMA/hns: Factor out the code for checking sdb status into a new function

On 2017/9/28 21:50, Leon Romanovsky wrote: On Thu, Sep 28, 2017 at 12:57:27PM +0800, Wei Hu (Xavier) wrote: From: Lijun Ou It mainly places the lines for checking send doorbell status into a special functions. As a result, we can directly call it in

Re: [PATCH for-next 2/9] RDMA/hns: Factor out the code for checking sdb status into a new function

On 2017/9/28 21:50, Leon Romanovsky wrote: On Thu, Sep 28, 2017 at 12:57:27PM +0800, Wei Hu (Xavier) wrote: From: Lijun Ou It mainly places the lines for checking send doorbell status into a special functions. As a result, we can directly call it in check_qp_db_process_status function and

Re: [PATCH v3 0/4] Update TMDSEVM3530 support for omap3-evm

On Tue, Sep 12, 2017 at 06:48:20PM -0500, Derald D. Woods wrote: > This patch set allows TMDSEVM3530(omap3-evm.dts) to boot using common > processor module data that is shared with 'omap3-evm-37xx.dts'. A new > common file for processor module data is introduced to help facilitate > the updated

Re: [PATCH v3 0/4] Update TMDSEVM3530 support for omap3-evm

On Tue, Sep 12, 2017 at 06:48:20PM -0500, Derald D. Woods wrote: > This patch set allows TMDSEVM3530(omap3-evm.dts) to boot using common > processor module data that is shared with 'omap3-evm-37xx.dts'. A new > common file for processor module data is introduced to help facilitate > the updated

RE: [PATCH] extcon: Split out extcon header file for consumer and provider device

Hi, > From: Chanwoo Choi > Sent: Friday, September 29, 2017 9:02 AM > < snip > > drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +- < snip > > drivers/usb/gadget/udc/renesas_usb3.c | 2 +- These two drivers need the modification. But... < snip > > diff --git

RE: [PATCH] extcon: Split out extcon header file for consumer and provider device

Hi, > From: Chanwoo Choi > Sent: Friday, September 29, 2017 9:02 AM > < snip > > drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +- < snip > > drivers/usb/gadget/udc/renesas_usb3.c | 2 +- These two drivers need the modification. But... < snip > > diff --git

Re: [PATCH 01/12] mmc: dt-bindings: update Mediatek MMC bindings

On Wed, 2017-09-27 at 09:18 +0800, Chaotian Jing wrote: > On Wed, 2017-09-27 at 00:33 +0200, Ulf Hansson wrote: > > On 14 September 2017 at 04:10, Chaotian Jing > > wrote: > > > On Wed, 2017-09-13 at 09:10 -0500, Rob Herring wrote: > > >> On Tue, Sep 12, 2017 at

Re: [PATCH 01/12] mmc: dt-bindings: update Mediatek MMC bindings

On Wed, 2017-09-27 at 09:18 +0800, Chaotian Jing wrote: > On Wed, 2017-09-27 at 00:33 +0200, Ulf Hansson wrote: > > On 14 September 2017 at 04:10, Chaotian Jing > > wrote: > > > On Wed, 2017-09-13 at 09:10 -0500, Rob Herring wrote: > > >> On Tue, Sep 12, 2017 at 05:07:41PM +0800, Chaotian Jing

Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively

On Thu, 2017-09-28 at 17:33 -0700, Linus Torvalds wrote: > On Thu, Sep 28, 2017 at 5:12 PM, Mimi Zohar wrote: > > > > Originally IMA did define it's own lock, prior to IMA-appraisal. IMA- > > appraisal introduced writing the file hash as an xattr, which required > >

Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively

On Thu, 2017-09-28 at 17:33 -0700, Linus Torvalds wrote: > On Thu, Sep 28, 2017 at 5:12 PM, Mimi Zohar wrote: > > > > Originally IMA did define it's own lock, prior to IMA-appraisal. IMA- > > appraisal introduced writing the file hash as an xattr, which required > > taking the i_mutex.

Re: [PATCH v3] mm, sysctl: make NUMA stats configurable

On 2017年09月29日 05:29, Andrew Morton wrote: > On Thu, 28 Sep 2017 14:11:41 +0800 Kemi Wang wrote: > >> This is the second step which introduces a tunable interface that allow >> numa stats configurable for optimizing zone_statistics(), as suggested by >> Dave Hansen and

Re: [PATCH v3] mm, sysctl: make NUMA stats configurable

On 2017年09月29日 05:29, Andrew Morton wrote: > On Thu, 28 Sep 2017 14:11:41 +0800 Kemi Wang wrote: > >> This is the second step which introduces a tunable interface that allow >> numa stats configurable for optimizing zone_statistics(), as suggested by >> Dave Hansen and Ying Huang. > > Looks

Re: [PATCH] x86/asm: Fix inline asm call constraints for GCC 4.4

On Thu, Sep 28, 2017 at 04:53:09PM -0700, Linus Torvalds wrote: > On Thu, Sep 28, 2017 at 2:58 PM, Josh Poimboeuf wrote: > > > > Reported-by: kernel test robot > > Fixes: f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang") > >

Re: [PATCH] x86/asm: Fix inline asm call constraints for GCC 4.4

On Thu, Sep 28, 2017 at 04:53:09PM -0700, Linus Torvalds wrote: > On Thu, Sep 28, 2017 at 2:58 PM, Josh Poimboeuf wrote: > > > > Reported-by: kernel test robot > > Fixes: f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang") > > Signed-off-by: Josh Poimboeuf > > Side note: it's

linux-next: build failure after merge of the net-next tree

Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/dsa/slave.c: In function 'dsa_slave_create': net/dsa/slave.c:1191:18: error: 'struct dsa_slave_priv' has no member named 'phy' phy_disconnect(p->phy); ^ Caused

linux-next: build failure after merge of the net-next tree

Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) failed like this: net/dsa/slave.c: In function 'dsa_slave_create': net/dsa/slave.c:1191:18: error: 'struct dsa_slave_priv' has no member named 'phy' phy_disconnect(p->phy); ^ Caused

[PATCH RESEND] KVM: nVMX: Fix nested #PF intends to break L1's vmlauch/vmresume

From: Wanpeng Li [ cut here ] WARNING: CPU: 4 PID: 5280 at /home/kernel/linux/arch/x86/kvm//vmx.c:11394 nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel] CPU: 4 PID: 5280 Comm: qemu-system-x86 Tainted: GW OE 4.13.0+ #17 RIP:

[PATCH RESEND] KVM: nVMX: Fix nested #PF intends to break L1's vmlauch/vmresume

From: Wanpeng Li [ cut here ] WARNING: CPU: 4 PID: 5280 at /home/kernel/linux/arch/x86/kvm//vmx.c:11394 nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel] CPU: 4 PID: 5280 Comm: qemu-system-x86 Tainted: GW OE 4.13.0+ #17 RIP: 0010:nested_vmx_vmexit+0xc2b/0xd70

Re: [PATCH 2/3] srcu: queue work without holding the lock

On Thu, Sep 28, 2017 at 06:03:57PM +0200, Sebastian Andrzej Siewior wrote: > On 2017-09-22 11:46:10 [-0700], Paul E. McKenney wrote: > > On Fri, Sep 22, 2017 at 05:28:05PM +0200, Sebastian Andrzej Siewior wrote: > > > On RT we can't invoke queue_delayed_work() within an atomic section > > > (which

Re: [PATCH 2/3] srcu: queue work without holding the lock

On Thu, Sep 28, 2017 at 06:03:57PM +0200, Sebastian Andrzej Siewior wrote: > On 2017-09-22 11:46:10 [-0700], Paul E. McKenney wrote: > > On Fri, Sep 22, 2017 at 05:28:05PM +0200, Sebastian Andrzej Siewior wrote: > > > On RT we can't invoke queue_delayed_work() within an atomic section > > > (which

Re: [PATCH 1/3] srcu: use cpu_online() instead custom check

On Thu, Sep 28, 2017 at 06:02:08PM +0200, Sebastian Andrzej Siewior wrote: > On 2017-09-22 11:43:14 [-0700], Paul E. McKenney wrote: > > On Fri, Sep 22, 2017 at 05:28:04PM +0200, Sebastian Andrzej Siewior wrote: > > > The current check via srcu_online is slightly racy because after looking > > >

Re: [PATCH 1/3] srcu: use cpu_online() instead custom check

On Thu, Sep 28, 2017 at 06:02:08PM +0200, Sebastian Andrzej Siewior wrote: > On 2017-09-22 11:43:14 [-0700], Paul E. McKenney wrote: > > On Fri, Sep 22, 2017 at 05:28:04PM +0200, Sebastian Andrzej Siewior wrote: > > > The current check via srcu_online is slightly racy because after looking > > >

[PATCH v2] KVM: VMX: Don't expose PLE enable if there is no hardware support

From: Wanpeng Li PLE_Window: Software can configure this field as an upper bound on the amount of time a guest is allowed to execute in a PAUSE LOOP. KVM doesn't expose the PLE capability to the L1 hypervisor, however, ple_window still shows the default value on L1

[PATCH v2] KVM: VMX: Don't expose PLE enable if there is no hardware support

From: Wanpeng Li PLE_Window: Software can configure this field as an upper bound on the amount of time a guest is allowed to execute in a PAUSE LOOP. KVM doesn't expose the PLE capability to the L1 hypervisor, however, ple_window still shows the default value on L1 hypervisor. This patch

[PATCH v2 2/4] KVM: LAPIC: Keep timer running when switching between one-shot and periodic mode

From: Wanpeng Li If we take TSC-deadline mode timer out of the picture, the Intel SDM does not say that the timer is disable when the timer mode is change, either from one-shot to periodic or vice versa. After this patch, the timer is no longer disarmed on change of

[PATCH v2 2/4] KVM: LAPIC: Keep timer running when switching between one-shot and periodic mode

From: Wanpeng Li If we take TSC-deadline mode timer out of the picture, the Intel SDM does not say that the timer is disable when the timer mode is change, either from one-shot to periodic or vice versa. After this patch, the timer is no longer disarmed on change of mode, so the counter (TMCCT)

[PATCH v2 4/4] KVM: LAPIC: Don't silently accept bad vectors

From: Wanpeng Li Vectors 0-15 are reserved, and a physical LAPIC - upon sending or receiving one - would generate an APIC error instead of doing the requested action. Make our emulation behave similarly. Cc: Paolo Bonzini Cc: Radim Krčmář

[PATCH v2 3/4] KVM: LAPIC: Apply change to TDCR right away to the timer

From: Wanpeng Li The description in the Intel SDM of how the divide configuration register is used: "The APIC timer frequency will be the processor's bus clock or core crystal clock frequency divided by the value specified in the divide configuration register."

[PATCH v2 4/4] KVM: LAPIC: Don't silently accept bad vectors

From: Wanpeng Li Vectors 0-15 are reserved, and a physical LAPIC - upon sending or receiving one - would generate an APIC error instead of doing the requested action. Make our emulation behave similarly. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/lapic.c |

[PATCH v2 3/4] KVM: LAPIC: Apply change to TDCR right away to the timer

From: Wanpeng Li The description in the Intel SDM of how the divide configuration register is used: "The APIC timer frequency will be the processor's bus clock or core crystal clock frequency divided by the value specified in the divide configuration register." Observation of baremetal shown

[PATCH v2 1/4] KVM: LAPIC: Fix lapic timer mode transition

From: Wanpeng Li SDM 10.5.4.1 TSC-Deadline Mode mentioned that "Transitioning between TSC-Deadline mode and other timer modes also disarms the timer". So the APIC Timer Initial Count Register for one-shot/periodic mode should be reset. This patch do it. Cc: Paolo

[PATCH v2 0/4] KVM: LAPIC: Rework lapic timer to behave more like real-hardware

The issue is reported in xen community. Anthony PERARD pointed out: https://www.mail-archive.com/xen-devel@lists.xen.org/msg117283.html# | When developing PVH for OVMF, I've used the lapic timer. It turns out that the | way it is used by OVMF did not work with Xen [1]. I tried to find out

  1   2   3   4   5   6   7   8   9   10   >