February 2020 - Linux-stable-mirror

FAILED: patch "[PATCH] pinctrl: qcom: Don't lock around irq_set_irq_wake()" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1d44616e7549d0154c1224a3eee3c407029294dc Mon Sep 17 00:00:00 2001 From: Stephen Boyd <swboyd(a)chromium.org> Date: Tue, 21 Jan 2020 10:09:50 -0800 Subject: [PATCH] pinctrl: qcom: Don't lock around irq_set_irq_wake() We don't need to hold the local pinctrl lock here to set irq wake on the summary irq line. Doing so only leads to lockdep warnings instead of protecting us from anything. Remove the locking. WARNING: possible circular locking dependency detected 5.4.11 #2 Tainted: G W ------------------------------------------------------ cat/3083 is trying to acquire lock: ffffff81f4fa58c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 but task is already holding lock: ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&pctrl->lock){-.-.}: _raw_spin_lock_irqsave+0x64/0x80 msm_gpio_irq_ack+0x68/0xf4 __irq_do_set_handler+0xe0/0x180 __irq_set_handler+0x60/0x9c irq_domain_set_info+0x90/0xb4 gpiochip_hierarchy_irq_domain_alloc+0x110/0x200 __irq_domain_alloc_irqs+0x130/0x29c irq_create_fwspec_mapping+0x1f0/0x300 irq_create_of_mapping+0x70/0x98 of_irq_get+0xa4/0xd4 spi_drv_probe+0x4c/0xb0 really_probe+0x138/0x3f0 driver_probe_device+0x70/0x140 __device_attach_driver+0x9c/0x110 bus_for_each_drv+0x88/0xd0 __device_attach+0xb0/0x160 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x35c/0x3f0 spi_add_device+0xbc/0x194 of_register_spi_devices+0x2c8/0x408 spi_register_controller+0x57c/0x6fc spi_geni_probe+0x260/0x328 platform_drv_probe+0x90/0xb0 really_probe+0x138/0x3f0 driver_probe_device+0x70/0x140 device_driver_attach+0x4c/0x6c __driver_attach+0xcc/0x154 bus_for_each_dev+0x84/0xcc driver_attach+0x2c/0x38 bus_add_driver+0x108/0x1fc driver_register+0x64/0xf8 __platform_driver_register+0x4c/0x58 spi_geni_driver_init+0x1c/0x24 do_one_initcall+0x1a4/0x3e8 do_initcall_level+0xb4/0xcc do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a8 kernel_init+0x14/0x100 ret_from_fork+0x10/0x18 -> #0 (&irq_desc_lock_class){-.-.}: __lock_acquire+0xeb4/0x2388 lock_acquire+0x1cc/0x210 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x310/0x41c dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x620 pm_suspend+0x210/0x348 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x15c/0x1fc __vfs_write+0x54/0x18c vfs_write+0xe4/0x1a4 ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_handler+0x7c/0x98 el0_svc+0x8/0xc other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pctrl->lock); lock(&irq_desc_lock_class); lock(&pctrl->lock); lock(&irq_desc_lock_class); *** DEADLOCK *** 7 locks held by cat/3083: #0: ffffff81f06d1420 (sb_writers#7){.+.+}, at: vfs_write+0xd0/0x1a4 #1: ffffff81c8935680 (&of->mutex){+.+.}, at: kernfs_fop_write+0x12c/0x1fc #2: ffffff81f4c322f0 (kn->count#337){.+.+}, at: kernfs_fop_write+0x134/0x1fc #3: ffffffe89a641d60 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x348 #4: ffffff81f190e970 (&dev->mutex){....}, at: __device_suspend+0x168/0x41c #5: ffffff81f183d8c0 (lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 #6: ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c stack backtrace: CPU: 4 PID: 3083 Comm: cat Tainted: G W 5.4.11 #2 Hardware name: Google Cheza (rev3+) (DT) Call trace: dump_backtrace+0x0/0x174 show_stack+0x20/0x2c dump_stack+0xc8/0x124 print_circular_bug+0x2ac/0x2c4 check_noncircular+0x1a0/0x1a8 __lock_acquire+0xeb4/0x2388 lock_acquire+0x1cc/0x210 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x310/0x41c dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x620 pm_suspend+0x210/0x348 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x15c/0x1fc __vfs_write+0x54/0x18c vfs_write+0xe4/0x1a4 ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_handler+0x7c/0x98 el0_svc+0x8/0xc Fixes: 6aced33f4974 ("pinctrl: msm: drop wake_irqs bitmap") Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Brian Masney <masneyb(a)onstation.org> Cc: Lina Iyer <ilina(a)codeaurora.org> Cc: Maulik Shah <mkshah(a)codeaurora.org> Signed-off-by: Stephen Boyd <swboyd(a)chromium.org> Link: https://lore.kernel.org/r/20200121180950.36959-1-swboyd@chromium.org Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index 5d6f9f61ce02..9a8daa256a32 100644 --- a/drivers/pinctrl/qcom/pinctrl-msm.c +++ b/drivers/pinctrl/qcom/pinctrl-msm.c @@ -960,7 +960,6 @@ static int msm_gpio_irq_set_wake(struct irq_data *d, unsigned int on) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct msm_pinctrl *pctrl = gpiochip_get_data(gc); - unsigned long flags; /* * While they may not wake up when the TLMM is powered off, @@ -971,12 +970,8 @@ static int msm_gpio_irq_set_wake(struct irq_data *d, unsigned int on) if (d->parent_data) irq_chip_set_wake_parent(d, on); - raw_spin_lock_irqsave(&pctrl->lock, flags); - irq_set_irq_wake(pctrl->irq, on); - raw_spin_unlock_irqrestore(&pctrl->lock, flags); - return 0; }

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] pinctrl: qcom: Don't lock around irq_set_irq_wake()" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1d44616e7549d0154c1224a3eee3c407029294dc Mon Sep 17 00:00:00 2001 From: Stephen Boyd <swboyd(a)chromium.org> Date: Tue, 21 Jan 2020 10:09:50 -0800 Subject: [PATCH] pinctrl: qcom: Don't lock around irq_set_irq_wake() We don't need to hold the local pinctrl lock here to set irq wake on the summary irq line. Doing so only leads to lockdep warnings instead of protecting us from anything. Remove the locking. WARNING: possible circular locking dependency detected 5.4.11 #2 Tainted: G W ------------------------------------------------------ cat/3083 is trying to acquire lock: ffffff81f4fa58c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 but task is already holding lock: ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&pctrl->lock){-.-.}: _raw_spin_lock_irqsave+0x64/0x80 msm_gpio_irq_ack+0x68/0xf4 __irq_do_set_handler+0xe0/0x180 __irq_set_handler+0x60/0x9c irq_domain_set_info+0x90/0xb4 gpiochip_hierarchy_irq_domain_alloc+0x110/0x200 __irq_domain_alloc_irqs+0x130/0x29c irq_create_fwspec_mapping+0x1f0/0x300 irq_create_of_mapping+0x70/0x98 of_irq_get+0xa4/0xd4 spi_drv_probe+0x4c/0xb0 really_probe+0x138/0x3f0 driver_probe_device+0x70/0x140 __device_attach_driver+0x9c/0x110 bus_for_each_drv+0x88/0xd0 __device_attach+0xb0/0x160 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x35c/0x3f0 spi_add_device+0xbc/0x194 of_register_spi_devices+0x2c8/0x408 spi_register_controller+0x57c/0x6fc spi_geni_probe+0x260/0x328 platform_drv_probe+0x90/0xb0 really_probe+0x138/0x3f0 driver_probe_device+0x70/0x140 device_driver_attach+0x4c/0x6c __driver_attach+0xcc/0x154 bus_for_each_dev+0x84/0xcc driver_attach+0x2c/0x38 bus_add_driver+0x108/0x1fc driver_register+0x64/0xf8 __platform_driver_register+0x4c/0x58 spi_geni_driver_init+0x1c/0x24 do_one_initcall+0x1a4/0x3e8 do_initcall_level+0xb4/0xcc do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a8 kernel_init+0x14/0x100 ret_from_fork+0x10/0x18 -> #0 (&irq_desc_lock_class){-.-.}: __lock_acquire+0xeb4/0x2388 lock_acquire+0x1cc/0x210 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x310/0x41c dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x620 pm_suspend+0x210/0x348 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x15c/0x1fc __vfs_write+0x54/0x18c vfs_write+0xe4/0x1a4 ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_handler+0x7c/0x98 el0_svc+0x8/0xc other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pctrl->lock); lock(&irq_desc_lock_class); lock(&pctrl->lock); lock(&irq_desc_lock_class); *** DEADLOCK *** 7 locks held by cat/3083: #0: ffffff81f06d1420 (sb_writers#7){.+.+}, at: vfs_write+0xd0/0x1a4 #1: ffffff81c8935680 (&of->mutex){+.+.}, at: kernfs_fop_write+0x12c/0x1fc #2: ffffff81f4c322f0 (kn->count#337){.+.+}, at: kernfs_fop_write+0x134/0x1fc #3: ffffffe89a641d60 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x348 #4: ffffff81f190e970 (&dev->mutex){....}, at: __device_suspend+0x168/0x41c #5: ffffff81f183d8c0 (lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 #6: ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c stack backtrace: CPU: 4 PID: 3083 Comm: cat Tainted: G W 5.4.11 #2 Hardware name: Google Cheza (rev3+) (DT) Call trace: dump_backtrace+0x0/0x174 show_stack+0x20/0x2c dump_stack+0xc8/0x124 print_circular_bug+0x2ac/0x2c4 check_noncircular+0x1a0/0x1a8 __lock_acquire+0xeb4/0x2388 lock_acquire+0x1cc/0x210 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x310/0x41c dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x620 pm_suspend+0x210/0x348 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x15c/0x1fc __vfs_write+0x54/0x18c vfs_write+0xe4/0x1a4 ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_handler+0x7c/0x98 el0_svc+0x8/0xc Fixes: 6aced33f4974 ("pinctrl: msm: drop wake_irqs bitmap") Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Brian Masney <masneyb(a)onstation.org> Cc: Lina Iyer <ilina(a)codeaurora.org> Cc: Maulik Shah <mkshah(a)codeaurora.org> Signed-off-by: Stephen Boyd <swboyd(a)chromium.org> Link: https://lore.kernel.org/r/20200121180950.36959-1-swboyd@chromium.org Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index 5d6f9f61ce02..9a8daa256a32 100644 --- a/drivers/pinctrl/qcom/pinctrl-msm.c +++ b/drivers/pinctrl/qcom/pinctrl-msm.c @@ -960,7 +960,6 @@ static int msm_gpio_irq_set_wake(struct irq_data *d, unsigned int on) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct msm_pinctrl *pctrl = gpiochip_get_data(gc); - unsigned long flags; /* * While they may not wake up when the TLMM is powered off, @@ -971,12 +970,8 @@ static int msm_gpio_irq_set_wake(struct irq_data *d, unsigned int on) if (d->parent_data) irq_chip_set_wake_parent(d, on); - raw_spin_lock_irqsave(&pctrl->lock, flags); - irq_set_irq_wake(pctrl->irq, on); - raw_spin_unlock_irqrestore(&pctrl->lock, flags); - return 0; }

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 539d8bde72c22d760013bf81436d6bb94eb67aed Mon Sep 17 00:00:00 2001 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 24 Oct 2019 17:33:42 +0300 Subject: [PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic Keeping the IRQ chip definition static shares it with multiple instances of the GPIO chip in the system. This is bad and now we get this warning from GPIO library: "detected irqchip that is shared with multiple gpiochips: please fix the driver." Hence, move the IRQ chip definition from being driver static into the struct intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance. Fixes: 9f573b98ca50 ("pinctrl: baytrail: Update irq chip operations") Depends-on: ca8a958e2acb ("pinctrl: baytrail: Pass irqchip when adding gpiochip") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c index 55141d5de29e..72ffd19448e5 100644 --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -107,6 +107,7 @@ struct byt_gpio_pin_context { struct byt_gpio { struct gpio_chip chip; + struct irq_chip irqchip; struct platform_device *pdev; struct pinctrl_dev *pctl_dev; struct pinctrl_desc pctl_desc; @@ -1395,15 +1396,6 @@ static int byt_irq_type(struct irq_data *d, unsigned int type) return 0; } -static struct irq_chip byt_irqchip = { - .name = "BYT-GPIO", - .irq_ack = byt_irq_ack, - .irq_mask = byt_irq_mask, - .irq_unmask = byt_irq_unmask, - .irq_set_type = byt_irq_type, - .flags = IRQCHIP_SKIP_SET_WAKE, -}; - static void byt_gpio_irq_handler(struct irq_desc *desc) { struct irq_data *data = irq_desc_get_irq_data(desc); @@ -1551,8 +1543,15 @@ static int byt_gpio_probe(struct byt_gpio *vg) if (irq_rc && irq_rc->start) { struct gpio_irq_chip *girq; + vg->irqchip.name = "BYT-GPIO", + vg->irqchip.irq_ack = byt_irq_ack, + vg->irqchip.irq_mask = byt_irq_mask, + vg->irqchip.irq_unmask = byt_irq_unmask, + vg->irqchip.irq_set_type = byt_irq_type, + vg->irqchip.flags = IRQCHIP_SKIP_SET_WAKE, + girq = &gc->irq; - girq->chip = &byt_irqchip; + girq->chip = &vg->irqchip; girq->init_hw = byt_gpio_irq_init_hw; girq->parent_handler = byt_gpio_irq_handler; girq->num_parents = 1;

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 539d8bde72c22d760013bf81436d6bb94eb67aed Mon Sep 17 00:00:00 2001 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 24 Oct 2019 17:33:42 +0300 Subject: [PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic Keeping the IRQ chip definition static shares it with multiple instances of the GPIO chip in the system. This is bad and now we get this warning from GPIO library: "detected irqchip that is shared with multiple gpiochips: please fix the driver." Hence, move the IRQ chip definition from being driver static into the struct intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance. Fixes: 9f573b98ca50 ("pinctrl: baytrail: Update irq chip operations") Depends-on: ca8a958e2acb ("pinctrl: baytrail: Pass irqchip when adding gpiochip") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c index 55141d5de29e..72ffd19448e5 100644 --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -107,6 +107,7 @@ struct byt_gpio_pin_context { struct byt_gpio { struct gpio_chip chip; + struct irq_chip irqchip; struct platform_device *pdev; struct pinctrl_dev *pctl_dev; struct pinctrl_desc pctl_desc; @@ -1395,15 +1396,6 @@ static int byt_irq_type(struct irq_data *d, unsigned int type) return 0; } -static struct irq_chip byt_irqchip = { - .name = "BYT-GPIO", - .irq_ack = byt_irq_ack, - .irq_mask = byt_irq_mask, - .irq_unmask = byt_irq_unmask, - .irq_set_type = byt_irq_type, - .flags = IRQCHIP_SKIP_SET_WAKE, -}; - static void byt_gpio_irq_handler(struct irq_desc *desc) { struct irq_data *data = irq_desc_get_irq_data(desc); @@ -1551,8 +1543,15 @@ static int byt_gpio_probe(struct byt_gpio *vg) if (irq_rc && irq_rc->start) { struct gpio_irq_chip *girq; + vg->irqchip.name = "BYT-GPIO", + vg->irqchip.irq_ack = byt_irq_ack, + vg->irqchip.irq_mask = byt_irq_mask, + vg->irqchip.irq_unmask = byt_irq_unmask, + vg->irqchip.irq_set_type = byt_irq_type, + vg->irqchip.flags = IRQCHIP_SKIP_SET_WAKE, + girq = &gc->irq; - girq->chip = &byt_irqchip; + girq->chip = &vg->irqchip; girq->init_hw = byt_gpio_irq_init_hw; girq->parent_handler = byt_gpio_irq_handler; girq->num_parents = 1;

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 539d8bde72c22d760013bf81436d6bb94eb67aed Mon Sep 17 00:00:00 2001 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 24 Oct 2019 17:33:42 +0300 Subject: [PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic Keeping the IRQ chip definition static shares it with multiple instances of the GPIO chip in the system. This is bad and now we get this warning from GPIO library: "detected irqchip that is shared with multiple gpiochips: please fix the driver." Hence, move the IRQ chip definition from being driver static into the struct intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance. Fixes: 9f573b98ca50 ("pinctrl: baytrail: Update irq chip operations") Depends-on: ca8a958e2acb ("pinctrl: baytrail: Pass irqchip when adding gpiochip") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c index 55141d5de29e..72ffd19448e5 100644 --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -107,6 +107,7 @@ struct byt_gpio_pin_context { struct byt_gpio { struct gpio_chip chip; + struct irq_chip irqchip; struct platform_device *pdev; struct pinctrl_dev *pctl_dev; struct pinctrl_desc pctl_desc; @@ -1395,15 +1396,6 @@ static int byt_irq_type(struct irq_data *d, unsigned int type) return 0; } -static struct irq_chip byt_irqchip = { - .name = "BYT-GPIO", - .irq_ack = byt_irq_ack, - .irq_mask = byt_irq_mask, - .irq_unmask = byt_irq_unmask, - .irq_set_type = byt_irq_type, - .flags = IRQCHIP_SKIP_SET_WAKE, -}; - static void byt_gpio_irq_handler(struct irq_desc *desc) { struct irq_data *data = irq_desc_get_irq_data(desc); @@ -1551,8 +1543,15 @@ static int byt_gpio_probe(struct byt_gpio *vg) if (irq_rc && irq_rc->start) { struct gpio_irq_chip *girq; + vg->irqchip.name = "BYT-GPIO", + vg->irqchip.irq_ack = byt_irq_ack, + vg->irqchip.irq_mask = byt_irq_mask, + vg->irqchip.irq_unmask = byt_irq_unmask, + vg->irqchip.irq_set_type = byt_irq_type, + vg->irqchip.flags = IRQCHIP_SKIP_SET_WAKE, + girq = &gc->irq; - girq->chip = &byt_irqchip; + girq->chip = &vg->irqchip; girq->init_hw = byt_gpio_irq_init_hw; girq->parent_handler = byt_gpio_irq_handler; girq->num_parents = 1;

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 539d8bde72c22d760013bf81436d6bb94eb67aed Mon Sep 17 00:00:00 2001 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 24 Oct 2019 17:33:42 +0300 Subject: [PATCH] pinctrl: baytrail: Allocate IRQ chip dynamic Keeping the IRQ chip definition static shares it with multiple instances of the GPIO chip in the system. This is bad and now we get this warning from GPIO library: "detected irqchip that is shared with multiple gpiochips: please fix the driver." Hence, move the IRQ chip definition from being driver static into the struct intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance. Fixes: 9f573b98ca50 ("pinctrl: baytrail: Update irq chip operations") Depends-on: ca8a958e2acb ("pinctrl: baytrail: Pass irqchip when adding gpiochip") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c index 55141d5de29e..72ffd19448e5 100644 --- a/drivers/pinctrl/intel/pinctrl-baytrail.c +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c @@ -107,6 +107,7 @@ struct byt_gpio_pin_context { struct byt_gpio { struct gpio_chip chip; + struct irq_chip irqchip; struct platform_device *pdev; struct pinctrl_dev *pctl_dev; struct pinctrl_desc pctl_desc; @@ -1395,15 +1396,6 @@ static int byt_irq_type(struct irq_data *d, unsigned int type) return 0; } -static struct irq_chip byt_irqchip = { - .name = "BYT-GPIO", - .irq_ack = byt_irq_ack, - .irq_mask = byt_irq_mask, - .irq_unmask = byt_irq_unmask, - .irq_set_type = byt_irq_type, - .flags = IRQCHIP_SKIP_SET_WAKE, -}; - static void byt_gpio_irq_handler(struct irq_desc *desc) { struct irq_data *data = irq_desc_get_irq_data(desc); @@ -1551,8 +1543,15 @@ static int byt_gpio_probe(struct byt_gpio *vg) if (irq_rc && irq_rc->start) { struct gpio_irq_chip *girq; + vg->irqchip.name = "BYT-GPIO", + vg->irqchip.irq_ack = byt_irq_ack, + vg->irqchip.irq_mask = byt_irq_mask, + vg->irqchip.irq_unmask = byt_irq_unmask, + vg->irqchip.irq_set_type = byt_irq_type, + vg->irqchip.flags = IRQCHIP_SKIP_SET_WAKE, + girq = &gc->irq; - girq->chip = &byt_irqchip; + girq->chip = &vg->irqchip; girq->init_hw = byt_gpio_irq_init_hw; girq->parent_handler = byt_gpio_irq_handler; girq->num_parents = 1;

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 52f73c383b2418f2d31b798e765ae7d596c35021 Mon Sep 17 00:00:00 2001 From: Suzuki K Poulose <suzuki.poulose(a)arm.com> Date: Mon, 13 Jan 2020 23:30:23 +0000 Subject: [PATCH] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly We detect the absence of FP/SIMD after an incapable CPU is brought up, and by then we have kernel threads running already with TIF_FOREIGN_FPSTATE set which could be set for early userspace applications (e.g, modprobe triggered from initramfs) and init. This could cause the applications to loop forever in do_nofity_resume() as we never clear the TIF flag, once we now know that we don't support FP. Fix this by making sure that we clear the TIF_FOREIGN_FPSTATE flag for tasks which may have them set, as we would have done in the normal case, but avoiding touching the hardware state (since we don't support any). Also to make sure we handle the cases seemlessly we categorise the helper functions to two : 1) Helpers for common core code, which calls into take appropriate actions without knowing the current FPSIMD state of the CPU/task. e.g fpsimd_restore_current_state(), fpsimd_flush_task_state(), fpsimd_save_and_flush_cpu_state(). We bail out early for these functions, taking any appropriate actions (e.g, clearing the TIF flag) where necessary to hide the handling from core code. 2) Helpers used when the presence of FP/SIMD is apparent. i.e, save/restore the FP/SIMD register state, modify the CPU/task FP/SIMD state. e.g, fpsimd_save(), task_fpsimd_load() - save/restore task FP/SIMD registers fpsimd_bind_task_to_cpu() \ - Update the "state" metadata for CPU/task. fpsimd_bind_state_to_cpu() / fpsimd_update_current_state() - Update the fp/simd state for the current task from memory. These must not be called in the absence of FP/SIMD. Put in a WARNING to make sure they are not invoked in the absence of FP/SIMD. KVM also uses the TIF_FOREIGN_FPSTATE flag to manage the FP/SIMD state on the CPU. However, without FP/SIMD support we trap all accesses and inject undefined instruction. Thus we should never "load" guest state. Add a sanity check to make sure this is valid. Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Reviewed-by: Ard Biesheuvel <ardb(a)kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com> Acked-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Will Deacon <will(a)kernel.org> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 3eb338f14386..94289d126993 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -269,6 +269,7 @@ static void sve_free(struct task_struct *task) */ static void task_fpsimd_load(void) { + WARN_ON(!system_supports_fpsimd()); WARN_ON(!have_cpu_fpsimd_context()); if (system_supports_sve() && test_thread_flag(TIF_SVE)) @@ -289,6 +290,7 @@ static void fpsimd_save(void) this_cpu_ptr(&fpsimd_last_state); /* set by fpsimd_bind_task_to_cpu() or fpsimd_bind_state_to_cpu() */ + WARN_ON(!system_supports_fpsimd()); WARN_ON(!have_cpu_fpsimd_context()); if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { @@ -1092,6 +1094,7 @@ void fpsimd_bind_task_to_cpu(void) struct fpsimd_last_state_struct *last = this_cpu_ptr(&fpsimd_last_state); + WARN_ON(!system_supports_fpsimd()); last->st = &current->thread.uw.fpsimd_state; last->sve_state = current->thread.sve_state; last->sve_vl = current->thread.sve_vl; @@ -1114,6 +1117,7 @@ void fpsimd_bind_state_to_cpu(struct user_fpsimd_state *st, void *sve_state, struct fpsimd_last_state_struct *last = this_cpu_ptr(&fpsimd_last_state); + WARN_ON(!system_supports_fpsimd()); WARN_ON(!in_softirq() && !irqs_disabled()); last->st = st; @@ -1128,8 +1132,19 @@ void fpsimd_bind_state_to_cpu(struct user_fpsimd_state *st, void *sve_state, */ void fpsimd_restore_current_state(void) { - if (!system_supports_fpsimd()) + /* + * For the tasks that were created before we detected the absence of + * FP/SIMD, the TIF_FOREIGN_FPSTATE could be set via fpsimd_thread_switch(), + * e.g, init. This could be then inherited by the children processes. + * If we later detect that the system doesn't support FP/SIMD, + * we must clear the flag for all the tasks to indicate that the + * FPSTATE is clean (as we can't have one) to avoid looping for ever in + * do_notify_resume(). + */ + if (!system_supports_fpsimd()) { + clear_thread_flag(TIF_FOREIGN_FPSTATE); return; + } get_cpu_fpsimd_context(); @@ -1148,7 +1163,7 @@ void fpsimd_restore_current_state(void) */ void fpsimd_update_current_state(struct user_fpsimd_state const *state) { - if (!system_supports_fpsimd()) + if (WARN_ON(!system_supports_fpsimd())) return; get_cpu_fpsimd_context(); @@ -1179,7 +1194,13 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state) void fpsimd_flush_task_state(struct task_struct *t) { t->thread.fpsimd_cpu = NR_CPUS; - + /* + * If we don't support fpsimd, bail out after we have + * reset the fpsimd_cpu for this task and clear the + * FPSTATE. + */ + if (!system_supports_fpsimd()) + return; barrier(); set_tsk_thread_flag(t, TIF_FOREIGN_FPSTATE); @@ -1193,6 +1214,7 @@ void fpsimd_flush_task_state(struct task_struct *t) */ static void fpsimd_flush_cpu_state(void) { + WARN_ON(!system_supports_fpsimd()); __this_cpu_write(fpsimd_last_state.st, NULL); set_thread_flag(TIF_FOREIGN_FPSTATE); } @@ -1203,6 +1225,8 @@ static void fpsimd_flush_cpu_state(void) */ void fpsimd_save_and_flush_cpu_state(void) { + if (!system_supports_fpsimd()) + return; WARN_ON(preemptible()); __get_cpu_fpsimd_context(); fpsimd_save(); diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c index 72fbbd86eb5e..e5816d885761 100644 --- a/arch/arm64/kvm/hyp/switch.c +++ b/arch/arm64/kvm/hyp/switch.c @@ -28,7 +28,15 @@ /* Check whether the FP regs were dirtied while in the host-side run loop: */ static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu) { - if (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE) + /* + * When the system doesn't support FP/SIMD, we cannot rely on + * the _TIF_FOREIGN_FPSTATE flag. However, we always inject an + * abort on the very first access to FP and thus we should never + * see KVM_ARM64_FP_ENABLED. For added safety, make sure we always + * trap the accesses. + */ + if (!system_supports_fpsimd() || + vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE) vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_FP_HOST);

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 52f73c383b2418f2d31b798e765ae7d596c35021 Mon Sep 17 00:00:00 2001 From: Suzuki K Poulose <suzuki.poulose(a)arm.com> Date: Mon, 13 Jan 2020 23:30:23 +0000 Subject: [PATCH] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly We detect the absence of FP/SIMD after an incapable CPU is brought up, and by then we have kernel threads running already with TIF_FOREIGN_FPSTATE set which could be set for early userspace applications (e.g, modprobe triggered from initramfs) and init. This could cause the applications to loop forever in do_nofity_resume() as we never clear the TIF flag, once we now know that we don't support FP. Fix this by making sure that we clear the TIF_FOREIGN_FPSTATE flag for tasks which may have them set, as we would have done in the normal case, but avoiding touching the hardware state (since we don't support any). Also to make sure we handle the cases seemlessly we categorise the helper functions to two : 1) Helpers for common core code, which calls into take appropriate actions without knowing the current FPSIMD state of the CPU/task. e.g fpsimd_restore_current_state(), fpsimd_flush_task_state(), fpsimd_save_and_flush_cpu_state(). We bail out early for these functions, taking any appropriate actions (e.g, clearing the TIF flag) where necessary to hide the handling from core code. 2) Helpers used when the presence of FP/SIMD is apparent. i.e, save/restore the FP/SIMD register state, modify the CPU/task FP/SIMD state. e.g, fpsimd_save(), task_fpsimd_load() - save/restore task FP/SIMD registers fpsimd_bind_task_to_cpu() \ - Update the "state" metadata for CPU/task. fpsimd_bind_state_to_cpu() / fpsimd_update_current_state() - Update the fp/simd state for the current task from memory. These must not be called in the absence of FP/SIMD. Put in a WARNING to make sure they are not invoked in the absence of FP/SIMD. KVM also uses the TIF_FOREIGN_FPSTATE flag to manage the FP/SIMD state on the CPU. However, without FP/SIMD support we trap all accesses and inject undefined instruction. Thus we should never "load" guest state. Add a sanity check to make sure this is valid. Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Reviewed-by: Ard Biesheuvel <ardb(a)kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com> Acked-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Will Deacon <will(a)kernel.org> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 3eb338f14386..94289d126993 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -269,6 +269,7 @@ static void sve_free(struct task_struct *task) */ static void task_fpsimd_load(void) { + WARN_ON(!system_supports_fpsimd()); WARN_ON(!have_cpu_fpsimd_context()); if (system_supports_sve() && test_thread_flag(TIF_SVE)) @@ -289,6 +290,7 @@ static void fpsimd_save(void) this_cpu_ptr(&fpsimd_last_state); /* set by fpsimd_bind_task_to_cpu() or fpsimd_bind_state_to_cpu() */ + WARN_ON(!system_supports_fpsimd()); WARN_ON(!have_cpu_fpsimd_context()); if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { @@ -1092,6 +1094,7 @@ void fpsimd_bind_task_to_cpu(void) struct fpsimd_last_state_struct *last = this_cpu_ptr(&fpsimd_last_state); + WARN_ON(!system_supports_fpsimd()); last->st = &current->thread.uw.fpsimd_state; last->sve_state = current->thread.sve_state; last->sve_vl = current->thread.sve_vl; @@ -1114,6 +1117,7 @@ void fpsimd_bind_state_to_cpu(struct user_fpsimd_state *st, void *sve_state, struct fpsimd_last_state_struct *last = this_cpu_ptr(&fpsimd_last_state); + WARN_ON(!system_supports_fpsimd()); WARN_ON(!in_softirq() && !irqs_disabled()); last->st = st; @@ -1128,8 +1132,19 @@ void fpsimd_bind_state_to_cpu(struct user_fpsimd_state *st, void *sve_state, */ void fpsimd_restore_current_state(void) { - if (!system_supports_fpsimd()) + /* + * For the tasks that were created before we detected the absence of + * FP/SIMD, the TIF_FOREIGN_FPSTATE could be set via fpsimd_thread_switch(), + * e.g, init. This could be then inherited by the children processes. + * If we later detect that the system doesn't support FP/SIMD, + * we must clear the flag for all the tasks to indicate that the + * FPSTATE is clean (as we can't have one) to avoid looping for ever in + * do_notify_resume(). + */ + if (!system_supports_fpsimd()) { + clear_thread_flag(TIF_FOREIGN_FPSTATE); return; + } get_cpu_fpsimd_context(); @@ -1148,7 +1163,7 @@ void fpsimd_restore_current_state(void) */ void fpsimd_update_current_state(struct user_fpsimd_state const *state) { - if (!system_supports_fpsimd()) + if (WARN_ON(!system_supports_fpsimd())) return; get_cpu_fpsimd_context(); @@ -1179,7 +1194,13 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state) void fpsimd_flush_task_state(struct task_struct *t) { t->thread.fpsimd_cpu = NR_CPUS; - + /* + * If we don't support fpsimd, bail out after we have + * reset the fpsimd_cpu for this task and clear the + * FPSTATE. + */ + if (!system_supports_fpsimd()) + return; barrier(); set_tsk_thread_flag(t, TIF_FOREIGN_FPSTATE); @@ -1193,6 +1214,7 @@ void fpsimd_flush_task_state(struct task_struct *t) */ static void fpsimd_flush_cpu_state(void) { + WARN_ON(!system_supports_fpsimd()); __this_cpu_write(fpsimd_last_state.st, NULL); set_thread_flag(TIF_FOREIGN_FPSTATE); } @@ -1203,6 +1225,8 @@ static void fpsimd_flush_cpu_state(void) */ void fpsimd_save_and_flush_cpu_state(void) { + if (!system_supports_fpsimd()) + return; WARN_ON(preemptible()); __get_cpu_fpsimd_context(); fpsimd_save(); diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c index 72fbbd86eb5e..e5816d885761 100644 --- a/arch/arm64/kvm/hyp/switch.c +++ b/arch/arm64/kvm/hyp/switch.c @@ -28,7 +28,15 @@ /* Check whether the FP regs were dirtied while in the host-side run loop: */ static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu) { - if (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE) + /* + * When the system doesn't support FP/SIMD, we cannot rely on + * the _TIF_FOREIGN_FPSTATE flag. However, we always inject an + * abort on the very first access to FP and thus we should never + * see KVM_ARM64_FP_ENABLED. For added safety, make sure we always + * trap the accesses. + */ + if (!system_supports_fpsimd() || + vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE) vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_FP_HOST);

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] KVM: arm64: pmu: Don't increment SW_INCR if PMCR.E is unset" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 3837407c1aa1101ed5e214c7d6041e7a23335c6e Mon Sep 17 00:00:00 2001 From: Eric Auger <eric.auger(a)redhat.com> Date: Fri, 24 Jan 2020 15:25:32 +0100 Subject: [PATCH] KVM: arm64: pmu: Don't increment SW_INCR if PMCR.E is unset The specification says PMSWINC increments PMEVCNTR<n>_EL1 by 1 if PMEVCNTR<n>_EL0 is enabled and configured to count SW_INCR. For PMEVCNTR<n>_EL0 to be enabled, we need both PMCNTENSET to be set for the corresponding event counter but we also need the PMCR.E bit to be set. Fixes: 7a0adc7064b8 ("arm64: KVM: Add access handler for PMSWINC register") Signed-off-by: Eric Auger <eric.auger(a)redhat.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Andrew Murray <andrew.murray(a)arm.com> Acked-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20200124142535.29386-2-eric.auger@redhat.com diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c index 8731dfeced8b..c3f8b059881e 100644 --- a/virt/kvm/arm/pmu.c +++ b/virt/kvm/arm/pmu.c @@ -486,6 +486,9 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) if (val == 0) return; + if (!(__vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E)) + return; + enable = __vcpu_sys_reg(vcpu, PMCNTENSET_EL0); for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) { if (!(val & BIT(i)))

5 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] KVM: arm64: pmu: Don't increment SW_INCR if PMCR.E is unset" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 3837407c1aa1101ed5e214c7d6041e7a23335c6e Mon Sep 17 00:00:00 2001 From: Eric Auger <eric.auger(a)redhat.com> Date: Fri, 24 Jan 2020 15:25:32 +0100 Subject: [PATCH] KVM: arm64: pmu: Don't increment SW_INCR if PMCR.E is unset The specification says PMSWINC increments PMEVCNTR<n>_EL1 by 1 if PMEVCNTR<n>_EL0 is enabled and configured to count SW_INCR. For PMEVCNTR<n>_EL0 to be enabled, we need both PMCNTENSET to be set for the corresponding event counter but we also need the PMCR.E bit to be set. Fixes: 7a0adc7064b8 ("arm64: KVM: Add access handler for PMSWINC register") Signed-off-by: Eric Auger <eric.auger(a)redhat.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Andrew Murray <andrew.murray(a)arm.com> Acked-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20200124142535.29386-2-eric.auger@redhat.com diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c index 8731dfeced8b..c3f8b059881e 100644 --- a/virt/kvm/arm/pmu.c +++ b/virt/kvm/arm/pmu.c @@ -486,6 +486,9 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) if (val == 0) return; + if (!(__vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E)) + return; + enable = __vcpu_sys_reg(vcpu, PMCNTENSET_EL0); for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) { if (!(val & BIT(i)))

5 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2020