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

[PATCH v4 3/8] drm/fb_helper: Introduce suspend/resume_hotplug()

by Lyude Paul

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their output_poll_changed handler, this can happen in every single context that can fire off a hotplug event. An example: [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 [ 246.677580] Workqueue: events output_poll_execute [drm_kms_helper] [ 246.678704] Call Trace: [ 246.679753] __schedule+0x322/0xaf0 [ 246.680916] schedule+0x33/0x90 [ 246.681924] schedule_preempt_disabled+0x15/0x20 [ 246.683023] __mutex_lock+0x569/0x9a0 [ 246.684035] ? kobject_uevent_env+0x117/0x7b0 [ 246.685132] ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.686179] mutex_lock_nested+0x1b/0x20 [ 246.687278] ? mutex_lock_nested+0x1b/0x20 [ 246.688307] drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.689420] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.690462] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.691570] output_poll_execute+0x198/0x1c0 [drm_kms_helper] [ 246.692611] process_one_work+0x231/0x620 [ 246.693725] worker_thread+0x214/0x3a0 [ 246.694756] kthread+0x12b/0x150 [ 246.695856] ? wq_pool_ids_show+0x140/0x140 [ 246.696888] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.697998] ret_from_fork+0x3a/0x50 [ 246.699034] INFO: task kworker/0:1:60 blocked for more than 120 seconds. [ 246.700153] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.701182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.702278] kworker/0:1 D 0 60 2 0x80000000 [ 246.703293] Workqueue: pm pm_runtime_work [ 246.704393] Call Trace: [ 246.705403] __schedule+0x322/0xaf0 [ 246.706439] ? wait_for_completion+0x104/0x190 [ 246.707393] schedule+0x33/0x90 [ 246.708375] schedule_timeout+0x3a5/0x590 [ 246.709289] ? mark_held_locks+0x58/0x80 [ 246.710208] ? _raw_spin_unlock_irq+0x2c/0x40 [ 246.711222] ? wait_for_completion+0x104/0x190 [ 246.712134] ? trace_hardirqs_on_caller+0xf4/0x190 [ 246.713094] ? wait_for_completion+0x104/0x190 [ 246.713964] wait_for_completion+0x12c/0x190 [ 246.714895] ? wake_up_q+0x80/0x80 [ 246.715727] ? get_work_pool+0x90/0x90 [ 246.716649] flush_work+0x1c9/0x280 [ 246.717483] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0 [ 246.718442] __cancel_work_timer+0x146/0x1d0 [ 246.719247] cancel_delayed_work_sync+0x13/0x20 [ 246.720043] drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper] [ 246.721123] nouveau_pmops_runtime_suspend+0x3d/0xb0 [nouveau] [ 246.721897] pci_pm_runtime_suspend+0x6b/0x190 [ 246.722825] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.723737] __rpm_callback+0x7a/0x1d0 [ 246.724721] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.725607] rpm_callback+0x24/0x80 [ 246.726553] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.727376] rpm_suspend+0x142/0x6b0 [ 246.728185] pm_runtime_work+0x97/0xc0 [ 246.728938] process_one_work+0x231/0x620 [ 246.729796] worker_thread+0x44/0x3a0 [ 246.730614] kthread+0x12b/0x150 [ 246.731395] ? wq_pool_ids_show+0x140/0x140 [ 246.732202] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.732878] ret_from_fork+0x3a/0x50 [ 246.733768] INFO: task kworker/4:2:422 blocked for more than 120 seconds. [ 246.734587] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.735393] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.736113] kworker/4:2 D 0 422 2 0x80000080 [ 246.736789] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ 246.737665] Call Trace: [ 246.738490] __schedule+0x322/0xaf0 [ 246.739250] schedule+0x33/0x90 [ 246.739908] rpm_resume+0x19c/0x850 [ 246.740750] ? finish_wait+0x90/0x90 [ 246.741541] __pm_runtime_resume+0x4e/0x90 [ 246.742370] nv50_disp_atomic_commit+0x31/0x210 [nouveau] [ 246.743124] drm_atomic_commit+0x4a/0x50 [drm] [ 246.743775] restore_fbdev_mode_atomic+0x1c8/0x240 [drm_kms_helper] [ 246.744603] restore_fbdev_mode+0x31/0x140 [drm_kms_helper] [ 246.745373] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper] [ 246.746220] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [ 246.746884] drm_fb_helper_hotplug_event.part.28+0x96/0xb0 [drm_kms_helper] [ 246.747675] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.748544] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.749439] nv50_mstm_hotplug+0x15/0x20 [nouveau] [ 246.750111] drm_dp_send_link_address+0x177/0x1c0 [drm_kms_helper] [ 246.750764] drm_dp_check_and_send_link_address+0xa8/0xd0 [drm_kms_helper] [ 246.751602] drm_dp_mst_link_probe_work+0x51/0x90 [drm_kms_helper] [ 246.752314] process_one_work+0x231/0x620 [ 246.752979] worker_thread+0x44/0x3a0 [ 246.753838] kthread+0x12b/0x150 [ 246.754619] ? wq_pool_ids_show+0x140/0x140 [ 246.755386] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.756162] ret_from_fork+0x3a/0x50 [ 246.756847] Showing all locks held in the system: [ 246.758261] 3 locks held by kworker/4:0/37: [ 246.759016] #0: 00000000f8df4d2d ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.759856] #1: 00000000e6065461 ((work_completion)(&(&dev->mode_config.output_poll_work)->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.760670] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.761516] 2 locks held by kworker/0:1/60: [ 246.762274] #0: 00000000fff6be0f ((wq_completion)"pm"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.762982] #1: 000000005ab44fb4 ((work_completion)(&dev->power.work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.763890] 1 lock held by khungtaskd/64: [ 246.764664] #0: 000000008cb8b5c3 (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185 [ 246.765588] 5 locks held by kworker/4:2/422: [ 246.766440] #0: 00000000232f0959 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.767390] #1: 00000000bb59b134 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.768154] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0xb0 [drm_kms_helper] [ 246.768966] #3: 000000004c8f0b6b (crtc_ww_class_acquire){+.+.}, at: restore_fbdev_mode_atomic+0x4b/0x240 [drm_kms_helper] [ 246.769921] #4: 000000004c34a296 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8a/0x1b0 [drm] [ 246.770839] 1 lock held by dmesg/1038: [ 246.771739] 2 locks held by zsh/1172: [ 246.772650] #0: 00000000836d0438 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40 [ 246.773680] #1: 000000001f4f4d48 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0xc1/0x870 [ 246.775522] ============================================= Because of this, there's an unreasonable number of places that drm drivers would need to insert special handling to prevent trying to resume the device from all of these contexts that can deadlock. It's difficult even to try synchronizing with fb_helper in these contexts as well, since any of them could introduce a deadlock by waiting to acquire the top-level fb_helper mutex, while it's being held by another thread that might potentially call down to pm_runtime_get_sync(). Luckily-there's no actual reason we need to allow fb_helper to handle hotplugging at all when runtime suspending a device. If a hotplug happens during a runtime suspend operation, there's no reason the driver can't just re-enable fbcon's hotplug handling and bring it up to speed with hotplugging events it may have missed by calling drm_fb_helper_hotplug_event(). So, let's make this easy and just add helpers to handle disabling and enabling fb_helper connector probing() without having to potentially wait on fb_helper to finish it's work. This will let us fix the runtime suspend/resume deadlocks that we've been experiencing with nouveau, along with being able to fix some of the incorrect runtime PM core interaction that other DRM drivers currently perform to work around these issues. Changes since v3: - Actually check if fb_helper is NULL in both new helpers - Actually check drm_fbdev_emulation in both new helpers - Don't fire off a fb_helper hotplug unconditionally; only do it if the following conditions are true (as otherwise, calling this in the wrong spot will cause Bad Things to happen): - fb_helper hotplug handling was actually inhibited previously - fb_helper actually has a delayed hotplug pending - fb_helper is actually bound - fb_helper is actually initialized - Add __must_check to drm_fb_helper_suspend_hotplug(). There's no situation where a driver would actually want to use this without checking the return value, so enforce that - Rewrite and clarify the documentation for both helpers. - Make sure to return true in the drm_fb_helper_suspend_hotplug() stub that's provided in drm_fb_helper.h when CONFIG_DRM_FBDEV_EMULATION isn't enabled - Actually grab the toplevel fb_helper lock in drm_fb_helper_resume_hotplug(), since it's possible other activity (such as a hotplug) could be going on at the same time the driver calls drm_fb_helper_resume_hotplug(). We need this to check whether or not drm_fb_helper_hotplug_event() needs to be called anyway Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/drm_fb_helper.c | 123 +++++++++++++++++++++++++++++++- include/drm/drm_fb_helper.h | 22 ++++++ 2 files changed, 144 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 2ee1eaa66188..b5f1dee0c3a0 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -84,6 +84,11 @@ static DEFINE_MUTEX(kernel_fb_helper_lock); * For suspend/resume consider using drm_mode_config_helper_suspend() and * drm_mode_config_helper_resume() which takes care of fbdev as well. * + * For runtime suspend and runtime resume, drivers which need to disable + * normal hotplug handling should consider using + * drm_fb_helper_suspend_hotplug() and drm_fb_helper_resume_hotplug() to + * avoid deadlocking with fb_helper's hotplug handling. + * * All other functions exported by the fb helper library can be used to * implement the fbdev driver interface by the driver. * @@ -2733,6 +2738,118 @@ int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel) } EXPORT_SYMBOL(drm_fb_helper_initial_config); +/** + * drm_fb_helper_resume_hotplug - Uninhibit fb_helper hotplug handling + * @fb_helper: driver-allocated fbdev helper, can be NULL + * + * Uninhibit fb_helper's hotplug handling after it was previously inhibited by + * a call to drm_fb_helper_suspend_hotplug(). Unlike + * drm_fb_helper_suspend_hotplug(), this function will wait on + * fb_helper->lock. + * + * This helper will take care of handling any hotplug events that happened + * while fb_helper's hotplug handling was suspended. Since this possibly + * implies a call to drm_fb_helper_hotplug_event(), care must be taken when + * calling this function as it may initiate a modeset. + * + * Please note that this function is different from + * drm_fb_helper_set_suspend(). It does not resume fb_helper, it only allows + * fb_helper to probe connectors in response to changes to the device's + * connector configuration if this functionality was previously disabled by + * drm_fb_helper_suspend_hotplug(). Generally, a driver will only want to call + * this in it's runtime resume callbacks. + * + * Drivers calling drm_fb_helper_suspend_hotplug() must make sure to call this + * somewhere in their runtime resume callbacks. + * + * See also: drm_fb_helper_suspend_hotplug() + */ +void +drm_fb_helper_resume_hotplug(struct drm_fb_helper *fb_helper) +{ + bool changed; + + if (!drm_fbdev_emulation || !fb_helper) + return; + + mutex_lock(&fb_helper->lock); + + changed = !fb_helper->deferred_setup && + fb_helper->fb && + drm_fb_helper_is_bound(fb_helper) && + fb_helper->hotplug_suspended && + fb_helper->delayed_hotplug; + if (changed) + fb_helper->delayed_hotplug = false; + + fb_helper->hotplug_suspended = false; + + mutex_unlock(&fb_helper->lock); + + if (changed) + drm_fb_helper_hotplug_event(fb_helper); +} +EXPORT_SYMBOL(drm_fb_helper_resume_hotplug); + +/** + * drm_fb_helper_suspend_hotplug - Attempt to temporarily suspend fb_helper's + * hotplug handling + * @fb_helper: driver-allocated fbdev helper, can be NULL + * + * Temporarily inhibit fb_helper from responding to connector changes without + * blocking on fb_helper->lock, if possible. This can be called by a DRM + * driver early on in it's runtime suspend callback to both check whether or + * not fb_helper is still busy, and prevent hotplugs that might occur part-way + * through the runtime suspend process from being handled by fb_helper until + * drm_fb_helper_resume_hotplug() is called. This dramatically simplifies the + * runtime suspend process, as it eliminates the possibility that fb_helper + * might try to perform a modeset half way through the runtime suspend process + * in response to a connector hotplug, something which will almost certainly + * lead to deadlocking for drivers that need to disable normal hotplug + * handling in their runtime suspend handlers. + * + * Calls to this function should be put at the very start of a driver's + * runtime suspend operation if desired. The driver is then responsible for + * re-enabling fb_helper hotplug handling when normal hotplug detection + * becomes available on the device again by calling + * drm_fb_helper_resume_hotplug(). Usually, a driver will want to re-enable + * fb_helper hotplug handling once the hotplug detection capabilities of its + * devices have returned to normal (e.g. when the device is runtime resumed, + * or after the runtime suspend process was aborted for some reason). + * + * Please note that this function is different from + * drm_fb_helper_set_suspend(), in that it does not actually suspend + * fb_helper. It only prevents fb_helper from responding to connector hotplugs + * on it's own. Generally, a driver will only want to call this in its + * runtime suspend callback. + * + * See also: drm_fb_helper_resume_hotplug() + * + * RETURNS: + * True if hotplug handling was disabled successfully, or fb_helper wasn't + * actually initialized/enabled yet. False if grabbing &fb_helper->lock would + * have meant blocking on fb_helper. When this function returns false, this + * usually implies means that fb_helper is still busy doing something such as + * probing connectors or performing a modeset. Drivers should treat this the + * same way they would any other activity on the device, and abort the runtime + * suspend process as early as possible in response. + */ +bool __must_check +drm_fb_helper_suspend_hotplug(struct drm_fb_helper *fb_helper) +{ + if (!drm_fbdev_emulation || !fb_helper) + return true; + + if (!mutex_trylock(&fb_helper->lock)) + return false; + + fb_helper->hotplug_suspended = true; + mutex_unlock(&fb_helper->lock); + + return true; +} +EXPORT_SYMBOL(drm_fb_helper_suspend_hotplug); + /** * drm_fb_helper_hotplug_event - respond to a hotplug notification by * probing all the outputs attached to the fb @@ -2751,6 +2868,9 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config); * for a race-free fbcon setup and will make sure that the fbdev emulation will * not miss any hotplug events. * + * See also: drm_fb_helper_suspend_hotplug() + * See also: drm_fb_helper_resume_hotplug() + * * RETURNS: * 0 on success and a non-zero error code otherwise. */ @@ -2768,7 +2888,8 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper) return err; } - if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) { + if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper) || + fb_helper->hotplug_suspended) { fb_helper->delayed_hotplug = true; mutex_unlock(&fb_helper->lock); return err; diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index b069433e7fc1..9c6e4ceff3af 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -232,6 +232,14 @@ struct drm_fb_helper { * See also: @deferred_setup */ int preferred_bpp; + + /** + * @hotplug_suspended: + * + * Whether or not we can currently handle hotplug events, or if we + * need to wait for the DRM device to uninhibit us. + */ + bool hotplug_suspended; }; /** @@ -330,6 +338,11 @@ void drm_fb_helper_fbdev_teardown(struct drm_device *dev); void drm_fb_helper_lastclose(struct drm_device *dev); void drm_fb_helper_output_poll_changed(struct drm_device *dev); + +void drm_fb_helper_resume_hotplug(struct drm_fb_helper *fb_helper); +bool __must_check +drm_fb_helper_suspend_hotplug(struct drm_fb_helper *fb_helper); + #else static inline void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, @@ -564,6 +577,15 @@ static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev) { } +static inline void +drm_fb_helper_resume_hotplug(struct drm_fb_helper *fb_helper) +{ +} +static inline bool __must_check +drm_fb_helper_suspend_hotplug(struct drm_fb_helper *fb_helper) +{ + return true; +} #endif static inline int -- 2.17.1

7 years, 3 months

1
0
0 0

Re: [PATCH] pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()

by Uwe Kleine-König

Hello, On Mon, Jul 30, 2018 at 05:43:43PM +0200, Linus Walleij wrote: > On Fri, Jul 13, 2018 at 4:55 PM Dan Carpenter <dan.carpenter(a)oracle.com> wrote: > > > The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It > > has info->ngroups elements. Thus the > here should be >= to prevent > > reading one element beyond the end of the array. > > > > Fixes: 30612cd90005 ("pinctrl: imx1 core driver") > > Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> > > Patch applied. > > I am not tagging for stable as it is debug code and does not > affect end users. Not sure this is a valid reason. Distro kernels usually enable debugfs. I'd say an out-of-bounds access that can only be triggered by root should still be fixed. I won't argue but added stable to the addressees of this mail to at least raise awareness. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |

7 years, 3 months

2
1
0 0

[PATCH v2] drm/amd/display: Report non-DP display as disconnected without EDID

by Harry Wentland

[Why] Some boards seem to have a problem where HPD is high on HDMI even though no display is connected. We don't want to report these as connected. DP spec still requires us to report DP displays as connected when HPD is high but we can't read the EDID in order to go to fail-safe mode. [How] If connector_signal is not DP abort detection if we can't retrieve the EDID. Bugzilla: https://bugs.freedesktop.org/107390 Bugzilla: https://bugs.freedesktop.org/106846 Cc: stable(a)vger.kernel.org Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> v2: Add Bugzilla and stable --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index b180197a41e2..84f0fd15be4c 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -744,6 +744,17 @@ bool dc_link_detect(struct dc_link *link, enum dc_detect_reason reason) break; case EDID_NO_RESPONSE: DC_LOG_ERROR("No EDID read.\n"); + + /* + * Abort detection for non-DP connectors if we have + * no EDID + * + * DP needs to report as connected if HDP is high + * even if we have no EDID in order to go to + * fail-safe mode + */ + if (!dc_is_dp_signal(link->connector_signal)) + return false; default: break; } -- 2.17.1

7 years, 3 months

2
1
0 0

request to include on 4.14.y: a4c447533a18ee86e07232d6344ba12b1f9c5077

by Eduardo Valentin

Greg, This is a straight forward cherry-pick. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Thanks. -- All the best, Eduardo Valentin

7 years, 3 months

2
3
0 0

Re: [PATCH] HID: Bluetooth: hidp: buffer overflow in hidp_process_report

by Mark Salyzyn

On 08/01/2018 09:37 AM, Greg KH wrote: > On Tue, Jul 31, 2018 at 03:02:13PM -0700, Mark Salyzyn wrote: >> CVE-2018-9363 >> >> The buffer length is unsigned at all layers, but gets cast to int and >> checked in hidp_process_report and can lead to a buffer overflow. >> Switch len parameter to unsigned int to resolve issue. >> >> This affects 3.18 and newer kernels. >> >> Signed-off-by: Mark Salyzyn <salyzyn(a)android.com> >> Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough") >> Cc: Marcel Holtmann <marcel(a)holtmann.org> >> Cc: Johan Hedberg <johan.hedberg(a)gmail.com> >> Cc: "David S. Miller" <davem(a)davemloft.net> >> Cc: Kees Cook <keescook(a)chromium.org> >> Cc: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> >> Cc: linux-bluetooth(a)vger.kernel.org >> Cc: netdev(a)vger.kernel.org >> Cc: linux-kernel(a)vger.kernel.org >> Cc: security(a)kernel.org >> Cc: kernel-team(a)android.com > Nit, you only need to bother security@ if you do not have a fix and need > to figure out one. Thanks, I thought anything with a CVE was to go there according to netdev FAQ (dropped security from response list). > Also, you forgot to cc: stable(a)vger.kernel.org to be included in older > kernel releases :( netdev FAQ said to _not_ copy stable, I am so confused ;-{ (added stable to response list b/c patch is now taken into bluetooth-next) > thanks, > > greg k-h

7 years, 3 months

2
1
0 0

Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

by Oleksandr Natalenko

Hi. > I tested this on AMD Ryzen & Intel Broadwell system and dumped the > boot_cpu_data before and after a microcode update. On the Intel > system I also did a fatal MCE using mce-inject to confirm the output > from the mce handling code. > > P. > > ---8<--- > > On systems where a runtime microcode update has occurred the microcode > version output in a MCE log record is wrong because > boot_cpu_data.microcode is not updated during runtime. > > Update boot_cpu_data.microcode when the BSP's microcode is updated. > > Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check > records") > Suggested-by: Borislav Petkov <bp(a)alien8.com> > Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> > Cc: stable(a)vger.kernel.org > Cc: sironi(a)amazon.de > Cc: tony.luck(a)intel.com > --- > Changes in v2: Use mc_amd->hdr.patch_id on AMD > > arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ > arch/x86/kernel/cpu/microcode/intel.c | 4 ++++ > 2 files changed, 8 insertions(+) > > diff --git a/arch/x86/kernel/cpu/microcode/amd.c > b/arch/x86/kernel/cpu/microcode/amd.c > index 0624957aa068..63b072377ba4 100644 > --- a/arch/x86/kernel/cpu/microcode/amd.c > +++ b/arch/x86/kernel/cpu/microcode/amd.c > @@ -537,6 +537,10 @@ static enum ucode_state apply_microcode_amd(int > cpu) > uci->cpu_sig.rev = mc_amd->hdr.patch_id; > c->microcode = mc_amd->hdr.patch_id; > > + /* Update boot_cpu_data's revision too, if we're on the BSP: */ > + if (c->cpu_index == boot_cpu_data.cpu_index) > + boot_cpu_data.microcode = mc_amd->hdr.patch_id; > + > return UCODE_UPDATED; > } > > diff --git a/arch/x86/kernel/cpu/microcode/intel.c > b/arch/x86/kernel/cpu/microcode/intel.c > index 97ccf4c3b45b..256d336cbc04 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -851,6 +851,10 @@ static enum ucode_state apply_microcode_intel(int > cpu) > uci->cpu_sig.rev = rev; > c->microcode = rev; > > + /* Update boot_cpu_data's revision too, if we're on the BSP: */ > + if (c->cpu_index == boot_cpu_data.cpu_index) > + boot_cpu_data.microcode = rev; > + > return UCODE_UPDATED; > } > > -- > 2.17.0 After this patch, do we preserve an original microcode version somewhere? If no, why? Sometimes it is useful while debugging another crash because of faulty microcode. Thanks. -- Oleksandr Natalenko (post-factum)

7 years, 3 months

2
2
0 0

Re: [PATCH v3 02/14] ARM: dts: sunxi: h3/h5: Fix i2c2 register address

by Icenowy Zheng

在 2017-09-26二的 09:22 +0200，Corentin Labbe写道： > The unit address and register address does not match. > This patch fix the register address with the good one. > > Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> > Signed-off-by: Corentin Labbe <clabbe.montjoie(a)gmail.com> This patch should be backported. Older LTS also needs patches, but the patch needs to be refactored to suite the versions. Cc: stable(a)vger.kernel.org # 4.14 > --- > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi > index b37ed3461229..289f2cd06dfe 100644 > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi > @@ -632,7 +632,7 @@ > > i2c2: i2c@1c2b400 { > compatible = "allwinner,sun6i-a31-i2c"; > - reg = <0x01c2b000 0x400>; > + reg = <0x01c2b400 0x400>; > interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&ccu CLK_BUS_I2C2>; > resets = <&ccu RST_BUS_I2C2>;

7 years, 3 months

1
0
0 0

2018-7_租務精選

by Flourish_萊斯物業

7 years, 3 months

1
0
0 0

[PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for 4.14.x and 4.17.x -stable, respectively. Thanks!

7 years, 3 months

2
1
0 0

[PATCH v3 3/3] RDMA/mlx5: Fix shift overflow in mlx5_ib_create_wq

by Kees Cook

From: Leon Romanovsky <leonro(a)mellanox.com> [ 61.182439] UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/qp.c:5366:34 [ 61.183673] shift exponent 4294967288 is too large for 32-bit type 'unsigned int' [ 61.185530] CPU: 0 PID: 639 Comm: qp Not tainted 4.18.0-rc1-00037-g4aa1d69a9c60-dirty #96 [ 61.186981] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 61.188315] Call Trace: [ 61.188661] dump_stack+0xc7/0x13b [ 61.190427] ubsan_epilogue+0x9/0x49 [ 61.190899] __ubsan_handle_shift_out_of_bounds+0x1ea/0x22f [ 61.197040] mlx5_ib_create_wq+0x1c99/0x1d50 [ 61.206632] ib_uverbs_ex_create_wq+0x499/0x820 [ 61.213892] ib_uverbs_write+0x77e/0xae0 [ 61.248018] vfs_write+0x121/0x3b0 [ 61.249831] ksys_write+0xa1/0x120 [ 61.254024] do_syscall_64+0x7c/0x2a0 [ 61.256178] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 61.259211] RIP: 0033:0x7f54bab70e99 [ 61.262125] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 [ 61.268678] RSP: 002b:00007ffe1541c318 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 61.271076] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f54bab70e99 [ 61.273795] RDX: 0000000000000070 RSI: 0000000020000240 RDI: 0000000000000003 [ 61.276982] RBP: 00007ffe1541c330 R08: 00000000200078e0 R09: 0000000000000002 [ 61.280035] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004005c0 [ 61.283279] R13: 00007ffe1541c420 R14: 0000000000000000 R15: 0000000000000000 Cc: <stable(a)vger.kernel.org> # 4.7 Fixes: 79b20a6c3014 ("IB/mlx5: Add receive Work Queue verbs") Cc: syzkaller <syzkaller(a)googlegroups.com> Reported-by: Noa Osherovich <noaos(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/infiniband/hw/mlx5/qp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c index a4f1f638509f..7fc156db643d 100644 --- a/drivers/infiniband/hw/mlx5/qp.c +++ b/drivers/infiniband/hw/mlx5/qp.c @@ -5365,7 +5365,10 @@ static int set_user_rq_size(struct mlx5_ib_dev *dev, rwq->wqe_count = ucmd->rq_wqe_count; rwq->wqe_shift = ucmd->rq_wqe_shift; - rwq->buf_size = (rwq->wqe_count << rwq->wqe_shift); + if (check_shift_overflow(rwq->wqe_count, rwq->wqe_shift, + &rwq->buf_size)) + return -EINVAL; + rwq->log_rq_stride = rwq->wqe_shift; rwq->log_rq_size = ilog2(rwq->wqe_count); return 0; -- 2.17.1

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror