- Linux-stable-mirror - lists.linaro.org

patch "usb: dwc2: host: use hrtimer for NAK retries" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc2: host: use hrtimer for NAK retries to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 6ed30a7d8ec29d3aba46e47aa8b4a44f077dda4e Mon Sep 17 00:00:00 2001 From: Terin Stock <terin(a)terinstock.com> Date: Sun, 9 Sep 2018 21:24:31 -0700 Subject: usb: dwc2: host: use hrtimer for NAK retries Modify the wait delay utilize the high resolution timer API to allow for more precisely scheduled callbacks. A previous commit added a 1ms retry delay after multiple consecutive NAKed transactions using jiffies. On systems with a low timer interrupt frequency, this delay may be significantly longer than specified, resulting in misbehavior with some USB devices. This scenario was reached on a Raspberry Pi 3B with a Macally FDD-USB floppy drive (identified as 0424:0fdc Standard Microsystems Corp. Floppy, based on the USB97CFDC USB FDC). With the relay delay, the drive would be unable to mount a disk, replying with NAKs until the device was reset. Using ktime, the delta between starting the timer (in dwc2_hcd_qh_add) and the callback function can be determined. With the original delay implementation, this value was consistently approximately 12ms. (output in us). <idle>-0 [000] ..s. 1600.559974: dwc2_wait_timer_fn: wait_timer delta: 11976 <idle>-0 [000] ..s. 1600.571974: dwc2_wait_timer_fn: wait_timer delta: 11977 <idle>-0 [000] ..s. 1600.583974: dwc2_wait_timer_fn: wait_timer delta: 11976 <idle>-0 [000] ..s. 1600.595974: dwc2_wait_timer_fn: wait_timer delta: 11977 After converting the relay delay to using a higher resolution timer, the delay was much closer to 1ms. <idle>-0 [000] d.h. 1956.553017: dwc2_wait_timer_fn: wait_timer delta: 1002 <idle>-0 [000] d.h. 1956.554114: dwc2_wait_timer_fn: wait_timer delta: 1002 <idle>-0 [000] d.h. 1957.542660: dwc2_wait_timer_fn: wait_timer delta: 1004 <idle>-0 [000] d.h. 1957.543701: dwc2_wait_timer_fn: wait_timer delta: 1002 The floppy drive operates properly with delays up to approximately 5ms, and sends NAKs for any delays that are longer. Fixes: 38d2b5fb75c1 ("usb: dwc2: host: Don't retry NAKed transactions right away") Cc: <stable(a)vger.kernel.org> Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Acked-by: Minas Harutyunyan <hminas(a)synopsys.com> Signed-off-by: Terin Stock <terin(a)terinstock.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- drivers/usb/dwc2/hcd.h | 2 +- drivers/usb/dwc2/hcd_queue.c | 19 ++++++++++++------- 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h index 3f9bccc95add..c089ffa1f0a8 100644 --- a/drivers/usb/dwc2/hcd.h +++ b/drivers/usb/dwc2/hcd.h @@ -366,7 +366,7 @@ struct dwc2_qh { u32 desc_list_sz; u32 *n_bytes; struct timer_list unreserve_timer; - struct timer_list wait_timer; + struct hrtimer wait_timer; struct dwc2_tt *dwc_tt; int ttport; unsigned tt_buffer_dirty:1; diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c index 40839591d2ec..ea3aa640c15c 100644 --- a/drivers/usb/dwc2/hcd_queue.c +++ b/drivers/usb/dwc2/hcd_queue.c @@ -59,7 +59,7 @@ #define DWC2_UNRESERVE_DELAY (msecs_to_jiffies(5)) /* If we get a NAK, wait this long before retrying */ -#define DWC2_RETRY_WAIT_DELAY (msecs_to_jiffies(1)) +#define DWC2_RETRY_WAIT_DELAY 1*1E6L /** * dwc2_periodic_channel_available() - Checks that a channel is available for a @@ -1464,10 +1464,12 @@ static void dwc2_deschedule_periodic(struct dwc2_hsotg *hsotg, * qh back to the "inactive" list, then queues transactions. * * @t: Pointer to wait_timer in a qh. + * + * Return: HRTIMER_NORESTART to not automatically restart this timer. */ -static void dwc2_wait_timer_fn(struct timer_list *t) +static enum hrtimer_restart dwc2_wait_timer_fn(struct hrtimer *t) { - struct dwc2_qh *qh = from_timer(qh, t, wait_timer); + struct dwc2_qh *qh = container_of(t, struct dwc2_qh, wait_timer); struct dwc2_hsotg *hsotg = qh->hsotg; unsigned long flags; @@ -1491,6 +1493,7 @@ static void dwc2_wait_timer_fn(struct timer_list *t) } spin_unlock_irqrestore(&hsotg->lock, flags); + return HRTIMER_NORESTART; } /** @@ -1521,7 +1524,8 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh, /* Initialize QH */ qh->hsotg = hsotg; timer_setup(&qh->unreserve_timer, dwc2_unreserve_timer_fn, 0); - timer_setup(&qh->wait_timer, dwc2_wait_timer_fn, 0); + hrtimer_init(&qh->wait_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); + qh->wait_timer.function = &dwc2_wait_timer_fn; qh->ep_type = ep_type; qh->ep_is_in = ep_is_in; @@ -1690,7 +1694,7 @@ void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh) * won't do anything anyway, but we want it to finish before we free * memory. */ - del_timer_sync(&qh->wait_timer); + hrtimer_cancel(&qh->wait_timer); dwc2_host_put_tt_info(hsotg, qh->dwc_tt); @@ -1716,6 +1720,7 @@ int dwc2_hcd_qh_add(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh) { int status; u32 intr_mask; + ktime_t delay; if (dbg_qh(qh)) dev_vdbg(hsotg->dev, "%s()\n", __func__); @@ -1734,8 +1739,8 @@ int dwc2_hcd_qh_add(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh) list_add_tail(&qh->qh_list_entry, &hsotg->non_periodic_sched_waiting); qh->wait_timer_cancel = false; - mod_timer(&qh->wait_timer, - jiffies + DWC2_RETRY_WAIT_DELAY + 1); + delay = ktime_set(0, DWC2_RETRY_WAIT_DELAY); + hrtimer_start(&qh->wait_timer, delay, HRTIMER_MODE_REL); } else { list_add_tail(&qh->qh_list_entry, &hsotg->non_periodic_sched_inactive); -- 2.20.0

6 years, 11 months

1
0
0 0

[RESEND PATCH v3] backlight: pwm_bl: Fix brightness levels for non-DT case.

by Enric Balletbo i Serra

Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to human eye")' allows the possibility to compute a default brightness table when there isn't the brightness-levels property in the DT. Unfortunately the changes made broke the pwm backlight for the non-DT boards. Usually, the non-DT boards don't pass the brightness levels via platform data, instead, it sets the max_brightness in their platform data and the driver calculates the level without a table. The offending patch assumed that when there is no brightness levels table we should create one, but this is clearly wrong for the non-DT case. After this patch the code handles the DT and the non-DT case taking in consideration also if max_brightness is set or not. Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to human eye") Cc: <stable(a)vger.kernel.org> Reported-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> Tested-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Acked-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Changes in v3: - Fixed some typos in commit message. - Removed ' in Fixes tag. Changes in v2: - Rebase on top of mainline - Add Tested-by and Acked-by tags. drivers/video/backlight/pwm_bl.c | 41 +++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index b7b5b31f3824..feb90764a811 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -568,7 +568,30 @@ static int pwm_backlight_probe(struct platform_device *pdev) goto err_alloc; } - if (!data->levels) { + if (data->levels) { + /* + * For the DT case, only when brightness levels is defined + * data->levels is filled. For the non-DT case, data->levels + * can come from platform data, however is not usual. + */ + for (i = 0; i <= data->max_brightness; i++) { + if (data->levels[i] > pb->scale) + pb->scale = data->levels[i]; + + pb->levels = data->levels; + } + } else if (!data->max_brightness) { + /* + * If no brightness levels are provided and max_brightness is + * not set, use the default brightness table. For the DT case, + * max_brightness is set to 0 when brightness levels is not + * specified. For the non-DT case, max_brightness is usually + * set to some value. + */ + + /* Get the PWM period (in nanoseconds) */ + pwm_get_state(pb->pwm, &state); + ret = pwm_backlight_brightness_default(&pdev->dev, data, state.period); if (ret < 0) { @@ -576,13 +599,19 @@ static int pwm_backlight_probe(struct platform_device *pdev) "failed to setup default brightness table\n"); goto err_alloc; } - } - for (i = 0; i <= data->max_brightness; i++) { - if (data->levels[i] > pb->scale) - pb->scale = data->levels[i]; + for (i = 0; i <= data->max_brightness; i++) { + if (data->levels[i] > pb->scale) + pb->scale = data->levels[i]; - pb->levels = data->levels; + pb->levels = data->levels; + } + } else { + /* + * That only happens for the non-DT case, where platform data + * sets the max_brightness value. + */ + pb->scale = data->max_brightness; } pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); -- 2.19.2

6 years, 11 months

2
1
0 0

[PATCH] x86/mm: Fix decoy address handling vs 32-bit builds

by Dan Williams

A decoy address is used by set_mce_nospec() to update the cache attributes for a page that may contain poison (multi-bit ECC error) while attempting to minimize the possibility of triggering a speculative access to that page. When reserve_memtype() is handling a decoy address it needs to convert it to its real physical alias. The conversion, AND'ing with __PHYSICAL_MASK, is broken for a 32-bit physical mask and reserve_memtype() is passed the last physical page. Gert reports triggering the: BUG_ON(start >= end); ...assertion when running a 32-bit non-PAE build on a platform that has a driver resource at the top of physical memory: BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved Given that the decoy address scheme is only targeted at 64-bit builds and assumes that the top of physical address space is free for use as a decoy address range, simply bypass address sanitization in the 32-bit case. Lastly, there was no need to crash the system when this failure occurred, and no need to crash future systems if the assumptions of decoy addresses are ever violated. Change the BUG_ON() to a WARN() with an error return. Reported-by: Gert Robben <t2(a)gert.gr> Tested-by: Gert Robben <t2(a)gert.gr> Cc: <stable(a)vger.kernel.org> Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Fixes: 510ee090abc3 ("x86/mm/pat: Prepare {reserve, free}_memtype() for...") Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- arch/x86/mm/pat.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index 08013524fba1..4fe956a63b25 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -519,8 +519,13 @@ static u64 sanitize_phys(u64 address) * for a "decoy" virtual address (bit 63 clear) passed to * set_memory_X(). __pa() on a "decoy" address results in a * physical address with bit 63 set. + * + * Decoy addresses are not present for 32-bit builds, see + * set_mce_nospec(). */ - return address & __PHYSICAL_MASK; + if (IS_ENABLED(CONFIG_X86_64)) + return address & __PHYSICAL_MASK; + return address; } /* @@ -546,7 +551,11 @@ int reserve_memtype(u64 start, u64 end, enum page_cache_mode req_type, start = sanitize_phys(start); end = sanitize_phys(end); - BUG_ON(start >= end); /* end is exclusive */ + if (start >= end) { + WARN(1, "%s failed: [mem %#010Lx-%#010Lx], req %s\n", __func__, + start, end - 1, cattr_name(req_type)); + return -EINVAL; + } if (!pat_enabled()) { /* This is identical to page table setting without PAT */

6 years, 11 months

2
1
0 0

Re: [PATCH 1/1] sched/headers: fix thread_info.<first> is overwritten by STACK_END_MAGIC

by Wang, Dongsheng

Hello Kees, On 2018/11/28 6:38, Kees Cook wrote: > On Thu, Nov 22, 2018 at 11:54 PM, Wang Dongsheng > <dongsheng.wang(a)hxt-semitech.com> wrote: >> When select ARCH_TASK_STRUCT_ON_STACK the first of thread_info variable >> is overwritten by STACK_END_MAGIC. In fact, the ARCH_TASK_STRUCT_ON_STACK >> is not a real task on stack, it's only init_task on init_stack. >> >> Commit 0500871f21b2 ("Construct init thread stack in the linker script >> rather than by union") added this macro and put task_strcut into >> thread_union. This brings us the following possibilities: >> TASK_ON_STACK THREAD_INFO_IN_TASK STACK >> ----- <-- thread_info & stack >> N N | | --- <-- task >> | | | | >> ----- --- >> >> ----- <-- stack >> N Y | | --- <-- task(Including thread_info) >> | | | | >> ----- --- >> >> ----- <-- stack & task & thread_info >> Y N | | >> | | >> ----- >> >> ----- <-- stack & task(Including thread_info) >> Y Y | | >> | | >> ----- >> The kernel has handled the first two cases correctly. >> >> For the third case: >> TASK_ON_STACK: Y. THREAD_INFO_IN_TASK: N. this case >> should never happen, because the task and thread_info will overlap. So >> when TASK_ON_STACK is selected, THREAD_INFO_IN_TASK must be selected too. >> >> For the fourth case: >> When task on stack, the end of stack should add a sizeof(task_struct) offset. >> >> This patch handled with the third and fourth case. >> >> Fixes: 0500871f21b2 ("Construct init thread stack in the linker ...") >> >> Signed-off-by: Wang Dongsheng <dongsheng.wang(a)hxt-semitech.com> >> Signed-off-by: Shunyong Yang <shunyong.yang(a)hxt-semitech.com> >> --- >> arch/Kconfig | 1 + >> include/linux/sched/task_stack.h | 5 ++++- >> 2 files changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/arch/Kconfig b/arch/Kconfig >> index e1e540ffa979..0a2c73e73195 100644 >> --- a/arch/Kconfig >> +++ b/arch/Kconfig >> @@ -251,6 +251,7 @@ config ARCH_HAS_SET_MEMORY >> # Select if arch init_task must go in the __init_task_data section >> config ARCH_TASK_STRUCT_ON_STACK >> bool >> + depends on THREAD_INFO_IN_TASK || IA64 > The "IA64" part shouldn't be needed since IA64 already selects it. > > Since it's selected, it also can't have a depends, IIUC. Since the IA64 thread_info including task_struct, it doesn't need to select THREAD_INFO_IN_TASK. So we need to allow IA64 select ARCH_TASK_STRUCT_ON_STACK without THREAD_INFO. >> # Select if arch has its private alloc_task_struct() function >> config ARCH_TASK_STRUCT_ALLOCATOR >> diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h >> index 6a841929073f..624c48defb9e 100644 >> --- a/include/linux/sched/task_stack.h >> +++ b/include/linux/sched/task_stack.h >> @@ -7,6 +7,7 @@ >> */ >> >> #include <linux/sched.h> >> +#include <linux/sched/task.h> >> #include <linux/magic.h> >> >> #ifdef CONFIG_THREAD_INFO_IN_TASK >> @@ -25,7 +26,9 @@ static inline void *task_stack_page(const struct task_struct *task) >> >> static inline unsigned long *end_of_stack(const struct task_struct *task) >> { >> - return task->stack; >> + if (!IS_ENABLED(CONFIG_ARCH_TASK_STRUCT_ON_STACK) || task != &init_task) >> + return task->stack; >> + return (unsigned long *)(task + 1); >> } > This seems like a strange place for the change. It feels more like > init_task has been defined incorrectly. The init_task will put into init_stack when ARCH_TASK_STRUCT_ON_STACK is selected. include/asm-generic/vmlinux.lds.h: #define INIT_TASK_DATA(align) \ . = ALIGN(align); \ __start_init_task = .; \ init_thread_union = .; \ init_stack = .; \ KEEP(*(.data..init_task)) \ KEEP(*(.data..init_thread_info)) \ . = __start_init_task + THREAD_SIZE; \ __end_init_task = .; So we need end_of_stack to offset sizeof(task_struct). Cheers, Dongsheng

6 years, 11 months

2
4
0 0

[PATCH] drm/nouveau: Fix memory leak in nv50_mstm_del()

by Lyude Paul

Noticed this while working on redoing the reference counting scheme in the DP MST helpers. Nouveau doesn't attempt to call drm_dp_mst_topology_mgr_destroy() at all, which leaves it leaking all of the resources for drm_dp_mst_topology_mgr and it's children mstbs+ports. Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: <stable(a)vger.kernel.org> # v4.10+ --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index d153ea2a08ac..a634b3d0b6a1 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -1254,6 +1254,7 @@ nv50_mstm_del(struct nv50_mstm **pmstm) { struct nv50_mstm *mstm = *pmstm; if (mstm) { + drm_dp_mst_topology_mgr_destroy(&mstm->mgr); kfree(*pmstm); *pmstm = NULL; } -- 2.19.2

6 years, 11 months

1
0
0 0

[PATCH] drm/dp_mst: Fix memory leak in drm_dp_mst_topology_mgr_destroy()

by Lyude Paul

We need to call drm_dp_mst_topology_mgr_set_mst(mgr, false) when destroying the topology manager in order to ensure that the root mstb and all of it's descendents are actually destroyed, and additionally to try to make sure that we leave the hub in a clean state. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: <stable(a)vger.kernel.org> # v3.17+ --- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 5a73a0b1c9cd..ad0fb6d003be 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -3235,6 +3235,7 @@ EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init); */ void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr) { + drm_dp_mst_topology_mgr_set_mst(mgr, false); flush_work(&mgr->work); flush_work(&mgr->destroy_connector_work); mutex_lock(&mgr->payload_lock); -- 2.19.2

6 years, 11 months

1
0
0 0

stable-rc/linux-4.4.y boot: 85 boots: 1 failed, 83 passed with 1 offline (v4.4.166-92-g216a0be637b7)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 85 boots: 1 failed, 83 passed with 1 offline (v4.4.166-92-g216a0be637b7) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.166-92-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.166-92-g216a0be637b7 Git Commit: 216a0be637b7dbf8db4aaad9810aba4ab15bb09c Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 42 unique boards, 20 SoC families, 11 builds out of 187 Boot Failure Detected: arm64: defconfig qcom-qdf2400: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

stable-rc/linux-4.14.y boot: 115 boots: 1 failed, 108 passed with 6 offline (v4.14.87-68-g9557e80a8f28)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 115 boots: 1 failed, 108 passed with 6 offline (v4.14.87-68-g9557e80a8f28) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.87-68… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.87-68-g9557e80a8f28 Git Commit: 9557e80a8f28e6bae4083dcc7dc6c2d1cb38d758 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 60 unique boards, 23 SoC families, 12 builds out of 197 Boot Regressions Detected: arm64: defconfig: rk3399-firefly: lab-baylibre-seattle: failing since 3 days (last pass: v4.14.86-56-g555f40d53cca - first fail: v4.14.87) Boot Failure Detected: arm64: defconfig rk3399-firefly: 1 failed lab Offline Platforms: arm: mvebu_v7_defconfig: armada-xp-openblocks-ax3-4: 1 offline lab multi_v7_defconfig: armada-xp-openblocks-ax3-4: 1 offline lab stih410-b2120: 1 offline lab tegra30-beaver: 1 offline lab zynq-zc702: 1 offline lab tegra_defconfig: tegra30-beaver: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

stable-rc/linux-4.19.y boot: 116 boots: 0 failed, 115 passed with 1 offline (v4.19.8-119-g6a09e212b52e)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 116 boots: 0 failed, 115 passed with 1 offline (v4.19.8-119-g6a09e212b52e) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.8-119… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.8-119-g6a09e212b52e Git Commit: 6a09e212b52e5edf398ca6296a183187d7343863 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 62 unique boards, 23 SoC families, 12 builds out of 202 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

[PATCH V2] x86/intel_rdt: Ensure usage of CPUs are locked while needed

by Reinette Chatre

The user triggers the creation of a pseudo-locked region when writing the requested schemata to the schemata resctrl file. The pseudo-locking of a region is required to be done on a CPU that is associated with the cache on which the pseudo-locked region will reside. In order to run the locking code on a specific CPU the needed CPU has to be selected and ensured to remain online during the entire locking sequence. At this time the cpu_hotplug_lock is not taken during the pseudo-lock region creation and it is thus possible for a CPU to be selected to run the pseudo-locking code and then that CPU to go offline before the thread is able to run on it. Fix this by ensuring that the cpu_hotplug_lock is taken while the CPU on which code has to run needs to be controlled. Since the cpu_hotplug_lock is always taken before rdtgroup_mutex the lock order is maintained. Fixes: e0bdfe8e36f3 ("x86/intel_rdt: Support creation/removal of pseudo-locked region") Signed-off-by: Reinette Chatre <reinette.chatre(a)intel.com> Cc: stable(a)vger.kernel.org --- V2: - Rebase against tip/x86/urgent - Modify subject from x86/resctrl to x86/intel_rdt to match subject used before the code reorganization. arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c index 27937458c231..efa4a519f5e5 100644 --- a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c +++ b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c @@ -23,6 +23,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <linux/cpu.h> #include <linux/kernfs.h> #include <linux/seq_file.h> #include <linux/slab.h> @@ -310,9 +311,11 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of, return -EINVAL; buf[nbytes - 1] = '\0'; + cpus_read_lock(); rdtgrp = rdtgroup_kn_lock_live(of->kn); if (!rdtgrp) { rdtgroup_kn_unlock(of->kn); + cpus_read_unlock(); return -ENOENT; } rdt_last_cmd_clear(); @@ -367,6 +370,7 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of, out: rdtgroup_kn_unlock(of->kn); + cpus_read_unlock(); return ret ?: nbytes; } -- 2.17.0

6 years, 11 months

3
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror