January 2018 - Linux-stable-mirror

[Linux-stable-mirror] Patch "rtc: m41t80: m41t80_sqw_set_rate should return 0 on success" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: m41t80: m41t80_sqw_set_rate should return 0 on success to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-m41t80-m41t80_sqw_set_rate-should-return-0-on-success.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From de6042d2fa8afe22b76e3c68fd6e9584c9415a3b Mon Sep 17 00:00:00 2001 From: Troy Kisky <troy.kisky(a)boundarydevices.com> Date: Thu, 2 Nov 2017 18:58:12 -0700 Subject: rtc: m41t80: m41t80_sqw_set_rate should return 0 on success From: Troy Kisky <troy.kisky(a)boundarydevices.com> commit de6042d2fa8afe22b76e3c68fd6e9584c9415a3b upstream. Previously it was returning -EINVAL upon success. Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Cc: Christoph Fritz <chf.fritz(a)googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-m41t80.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/rtc/rtc-m41t80.c +++ b/drivers/rtc/rtc-m41t80.c @@ -510,10 +510,7 @@ static int m41t80_sqw_set_rate(struct cl reg = (reg & 0x0f) | (val << 4); ret = i2c_smbus_write_byte_data(client, reg_sqw, reg); - if (ret < 0) - return ret; - - return -EINVAL; + return ret; } static int m41t80_sqw_control(struct clk_hw *hw, bool enable) Patches currently in stable-queue which might be from troy.kisky(a)boundarydevices.com are queue-4.14/rtc-m41t80-m41t80_sqw_set_rate-should-return-0-on-success.patch queue-4.14/rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_is_prepared.patch queue-4.14/rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_recalc_rate.patch queue-4.14/rtc-m41t80-remove-unneeded-checks-from-m41t80_sqw_set_rate.patch queue-4.14/rtc-m41t80-fix-m41t80_sqw_round_rate-return-value.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_recalc_rate.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2cb90ed3de1e279dbaf23df141f54eb9fb1861e6 Mon Sep 17 00:00:00 2001 From: Troy Kisky <troy.kisky(a)boundarydevices.com> Date: Thu, 2 Nov 2017 18:58:14 -0700 Subject: rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate From: Troy Kisky <troy.kisky(a)boundarydevices.com> commit 2cb90ed3de1e279dbaf23df141f54eb9fb1861e6 upstream. This is a little more efficient, and avoids the warning WARNING: possible circular locking dependency detected 4.14.0-rc7-00007 #14 Not tainted ------------------------------------------------------ alsactl/330 is trying to acquire lock: (prepare_lock){+.+.}, at: [<c049300c>] clk_prepare_lock+0x80/0xf4 but task is already holding lock: (i2c_register_adapter){+.+.}, at: [<c0690ae0>] i2c_adapter_lock_bus+0x14/0x18 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (i2c_register_adapter){+.+.}: rt_mutex_lock+0x44/0x5c i2c_adapter_lock_bus+0x14/0x18 i2c_transfer+0xa8/0xbc i2c_smbus_xfer+0x20c/0x5d8 i2c_smbus_read_byte_data+0x38/0x48 m41t80_sqw_recalc_rate+0x24/0x58 Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Cc: Christoph Fritz <chf.fritz(a)googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-m41t80.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) --- a/drivers/rtc/rtc-m41t80.c +++ b/drivers/rtc/rtc-m41t80.c @@ -154,6 +154,7 @@ struct m41t80_data { struct rtc_device *rtc; #ifdef CONFIG_COMMON_CLK struct clk_hw sqw; + unsigned long freq; #endif }; @@ -443,26 +444,28 @@ static SIMPLE_DEV_PM_OPS(m41t80_pm, m41t #ifdef CONFIG_COMMON_CLK #define sqw_to_m41t80_data(_hw) container_of(_hw, struct m41t80_data, sqw) -static unsigned long m41t80_sqw_recalc_rate(struct clk_hw *hw, - unsigned long parent_rate) +static unsigned long m41t80_decode_freq(int setting) +{ + return (setting == 0) ? 0 : (setting == 1) ? M41T80_SQW_MAX_FREQ : + M41T80_SQW_MAX_FREQ >> setting; +} + +static unsigned long m41t80_get_freq(struct m41t80_data *m41t80) { - struct m41t80_data *m41t80 = sqw_to_m41t80_data(hw); struct i2c_client *client = m41t80->client; int reg_sqw = (m41t80->features & M41T80_FEATURE_SQ_ALT) ? M41T80_REG_WDAY : M41T80_REG_SQW; int ret = i2c_smbus_read_byte_data(client, reg_sqw); - unsigned long val = M41T80_SQW_MAX_FREQ; if (ret < 0) return 0; + return m41t80_decode_freq(ret >> 4); +} - ret >>= 4; - if (ret == 0) - val = 0; - else if (ret > 1) - val = val / (1 << ret); - - return val; +static unsigned long m41t80_sqw_recalc_rate(struct clk_hw *hw, + unsigned long parent_rate) +{ + return sqw_to_m41t80_data(hw)->freq; } static long m41t80_sqw_round_rate(struct clk_hw *hw, unsigned long rate, @@ -505,6 +508,8 @@ static int m41t80_sqw_set_rate(struct cl reg = (reg & 0x0f) | (val << 4); ret = i2c_smbus_write_byte_data(client, reg_sqw, reg); + if (!ret) + m41t80->freq = m41t80_decode_freq(val); return ret; } @@ -579,6 +584,7 @@ static struct clk *m41t80_sqw_register_c init.parent_names = NULL; init.num_parents = 0; m41t80->sqw.init = &init; + m41t80->freq = m41t80_get_freq(m41t80); /* optional override of the clockname */ of_property_read_string(node, "clock-output-names", &init.name); Patches currently in stable-queue which might be from troy.kisky(a)boundarydevices.com are queue-4.14/rtc-m41t80-m41t80_sqw_set_rate-should-return-0-on-success.patch queue-4.14/rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_is_prepared.patch queue-4.14/rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_recalc_rate.patch queue-4.14/rtc-m41t80-remove-unneeded-checks-from-m41t80_sqw_set_rate.patch queue-4.14/rtc-m41t80-fix-m41t80_sqw_round_rate-return-value.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_is_prepared.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 13bb1d78f2e372ec0d9b30489ac63768240140fc Mon Sep 17 00:00:00 2001 From: Troy Kisky <troy.kisky(a)boundarydevices.com> Date: Thu, 2 Nov 2017 18:58:15 -0700 Subject: rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared From: Troy Kisky <troy.kisky(a)boundarydevices.com> commit 13bb1d78f2e372ec0d9b30489ac63768240140fc upstream. This is a little more efficient and avoids the warning WARNING: possible circular locking dependency detected 4.14.0-rc7-00010 #16 Not tainted ------------------------------------------------------ kworker/2:1/70 is trying to acquire lock: (prepare_lock){+.+.}, at: [<c049300c>] clk_prepare_lock+0x80/0xf4 but task is already holding lock: (i2c_register_adapter){+.+.}, at: [<c0690b04>] i2c_adapter_lock_bus+0x14/0x18 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (i2c_register_adapter){+.+.}: rt_mutex_lock+0x44/0x5c i2c_adapter_lock_bus+0x14/0x18 i2c_transfer+0xa8/0xbc i2c_smbus_xfer+0x20c/0x5d8 i2c_smbus_read_byte_data+0x38/0x48 m41t80_sqw_is_prepared+0x18/0x28 Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Cc: Christoph Fritz <chf.fritz(a)googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-m41t80.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) --- a/drivers/rtc/rtc-m41t80.c +++ b/drivers/rtc/rtc-m41t80.c @@ -155,6 +155,7 @@ struct m41t80_data { #ifdef CONFIG_COMMON_CLK struct clk_hw sqw; unsigned long freq; + unsigned int sqwe; #endif }; @@ -527,7 +528,10 @@ static int m41t80_sqw_control(struct clk else ret &= ~M41T80_ALMON_SQWE; - return i2c_smbus_write_byte_data(client, M41T80_REG_ALARM_MON, ret); + ret = i2c_smbus_write_byte_data(client, M41T80_REG_ALARM_MON, ret); + if (!ret) + m41t80->sqwe = enable; + return ret; } static int m41t80_sqw_prepare(struct clk_hw *hw) @@ -542,14 +546,7 @@ static void m41t80_sqw_unprepare(struct static int m41t80_sqw_is_prepared(struct clk_hw *hw) { - struct m41t80_data *m41t80 = sqw_to_m41t80_data(hw); - struct i2c_client *client = m41t80->client; - int ret = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON); - - if (ret < 0) - return ret; - - return !!(ret & M41T80_ALMON_SQWE); + return sqw_to_m41t80_data(hw)->sqwe; } static const struct clk_ops m41t80_sqw_ops = { Patches currently in stable-queue which might be from troy.kisky(a)boundarydevices.com are queue-4.14/rtc-m41t80-m41t80_sqw_set_rate-should-return-0-on-success.patch queue-4.14/rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_is_prepared.patch queue-4.14/rtc-m41t80-avoid-i2c-read-in-m41t80_sqw_recalc_rate.patch queue-4.14/rtc-m41t80-remove-unneeded-checks-from-m41t80_sqw_set_rate.patch queue-4.14/rtc-m41t80-fix-m41t80_sqw_round_rate-return-value.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find." to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: revert-xfrm-fix-stack-out-of-bounds-read-in-xfrm_state_find.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 94802151894d482e82c324edf2c658f8e6b96508 Mon Sep 17 00:00:00 2001 From: Steffen Klassert <steffen.klassert(a)secunet.com> Date: Wed, 15 Nov 2017 06:40:57 +0100 Subject: Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find." From: Steffen Klassert <steffen.klassert(a)secunet.com> commit 94802151894d482e82c324edf2c658f8e6b96508 upstream. This reverts commit c9f3f813d462c72dbe412cee6a5cbacf13c4ad5e. This commit breaks transport mode when the policy template has widlcard addresses configured, so revert it. Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Cc: From: Derek Robson <robsonde(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/xfrm/xfrm_policy.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -1362,29 +1362,36 @@ xfrm_tmpl_resolve_one(struct xfrm_policy struct net *net = xp_net(policy); int nx; int i, error; + xfrm_address_t *daddr = xfrm_flowi_daddr(fl, family); + xfrm_address_t *saddr = xfrm_flowi_saddr(fl, family); xfrm_address_t tmp; for (nx = 0, i = 0; i < policy->xfrm_nr; i++) { struct xfrm_state *x; - xfrm_address_t *local; - xfrm_address_t *remote; + xfrm_address_t *remote = daddr; + xfrm_address_t *local = saddr; struct xfrm_tmpl *tmpl = &policy->xfrm_vec[i]; - remote = &tmpl->id.daddr; - local = &tmpl->saddr; - if (xfrm_addr_any(local, tmpl->encap_family)) { - error = xfrm_get_saddr(net, fl->flowi_oif, - &tmp, remote, - tmpl->encap_family, 0); - if (error) - goto fail; - local = &tmp; + if (tmpl->mode == XFRM_MODE_TUNNEL || + tmpl->mode == XFRM_MODE_BEET) { + remote = &tmpl->id.daddr; + local = &tmpl->saddr; + if (xfrm_addr_any(local, tmpl->encap_family)) { + error = xfrm_get_saddr(net, fl->flowi_oif, + &tmp, remote, + tmpl->encap_family, 0); + if (error) + goto fail; + local = &tmp; + } } x = xfrm_state_find(remote, local, fl, tmpl, policy, &error, family); if (x && x->km.state == XFRM_STATE_VALID) { xfrm[nx++] = x; + daddr = remote; + saddr = local; continue; } if (x) { Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are queue-4.14/revert-xfrm-fix-stack-out-of-bounds-read-in-xfrm_state_find.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14 ?

by Christoph Fritz

Hey Troy and Alexandre, any objections asking Greg to add following recent v4.15 changes into stable branch 4.14? 05a03bf rtc: m41t80: remove unneeded checks from m41t80_sqw_set_rate 13bb1d7 rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared 2cb90ed rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate c8384bb rtc: m41t80: fix m41t80_sqw_round_rate return value de6042d rtc: m41t80: m41t80_sqw_set_rate should return 0 on success Without these patches, deadlock warnings showing up in 4.14: ====================================================== WARNING: possible circular locking dependency detected 4.14.8-00011-gd203938 #11 Not tainted ------------------------------------------------------ kworker/1:2/133 is trying to acquire lock: (prepare_lock){+.+.}, at: [<c04951d0>] clk_prepare_lock+0x80/0xf4 but task is already holding lock: (i2c_register_adapter){+.+.}, at: [<c069305c>] i2c_adapter_lock_bus+0x14/0x18 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (i2c_register_adapter){+.+.}: rt_mutex_lock+0x44/0x5c i2c_adapter_lock_bus+0x14/0x18 i2c_transfer+0xa8/0xbc i2c_smbus_xfer+0x214/0x5cc i2c_smbus_read_byte_data+0x3c/0x4c m41t80_sqw_recalc_rate+0x24/0x58 clk_register+0x3c8/0x638 m41t80_probe+0x224/0x378 i2c_device_probe+0x1dc/0x26c driver_probe_device+0x278/0x300 __driver_attach+0xbc/0xc0 bus_for_each_dev+0x74/0xa8 driver_attach+0x20/0x28 bus_add_driver+0x188/0x210 driver_register+0x80/0x100 i2c_register_driver+0x40/0x8c m41t80_driver_init+0x18/0x20 do_one_initcall+0x44/0x17c kernel_init_freeable+0x11c/0x1dc kernel_init+0x10/0x11c ret_from_fork+0x14/0x20 -> #0 (prepare_lock){+.+.}: lock_acquire+0x78/0x98 __mutex_lock+0x54/0x988 mutex_lock_nested+0x24/0x2c clk_prepare_lock+0x80/0xf4 clk_core_get_rate+0x14/0x64 clk_get_rate+0x1c/0x20 i2c_imx_start+0x20/0x1cc i2c_imx_xfer+0x38/0xb84 __i2c_transfer+0x138/0x27c i2c_transfer+0x78/0xbc i2c_master_send+0x44/0x54 regmap_i2c_write+0x18/0x34 _regmap_raw_write+0x56c/0x668 _regmap_bus_raw_write+0x74/0x94 _regmap_write+0x60/0x9c _regmap_update_bits+0xc8/0xcc regmap_update_bits_base+0x58/0x7c regulator_set_voltage_sel_regmap+0x50/0xa0 _regulator_do_set_voltage+0x280/0x35c regulator_set_voltage_unlocked+0xec/0x254 regulator_set_voltage_unlocked+0x1e8/0x254 regulator_set_voltage+0x30/0x5c imx6q_set_target+0xb8/0x4e0 __cpufreq_driver_target+0x224/0x540 od_dbs_update+0xa0/0x168 dbs_work_handler+0x34/0x60 process_one_work+0x194/0x41c worker_thread+0x34/0x538 kthread+0x11c/0x158 ret_from_fork+0x14/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(i2c_register_adapter); lock(prepare_lock); lock(i2c_register_adapter); lock(prepare_lock); *** DEADLOCK *** 7 locks held by kworker/1:2/133: #0: ("events"){+.+.}, at: [<c014144c>] process_one_work+0x128/0x41c #1: ((&policy_dbs->work)){+.+.}, at: [<c014144c>] process_one_work+0x128/0x41c #2: (&policy_dbs->update_mutex){+.+.}, at: [<c06da1a0>] dbs_work_handler+0x28/0x60 #3: (&rdev->mutex){+.+.}, at: [<c04a8cac>] regulator_lock_supply+0x24/0x44 #4: (&rdev->mutex/1){+.+.}, at: [<c04a8cac>] regulator_lock_supply+0x24/0x44 #5: (da9062_core:870:(config)->lock){+.+.}, at: [<c055f2c8>] regmap_lock_mutex+0x14/0x18 #6: (i2c_register_adapter){+.+.}, at: [<c069305c>] i2c_adapter_lock_bus+0x14/0x18 Thanks -- Christoph

6 years, 11 months

3
3
0 0

[Linux-stable-mirror] Patch "x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-pti-switch-to-kernel-cr3-at-early-in-entry_syscall_compat.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d7732ba55c4b6a2da339bb12589c515830cfac2c Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Wed, 3 Jan 2018 19:52:04 +0100 Subject: x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat() From: Thomas Gleixner <tglx(a)linutronix.de> commit d7732ba55c4b6a2da339bb12589c515830cfac2c upstream. The preparation for PTI which added CR3 switching to the entry code misplaced the CR3 switch in entry_SYSCALL_compat(). With PTI enabled the entry code tries to access a per cpu variable after switching to kernel GS. This fails because that variable is not mapped to user space. This results in a double fault and in the worst case a kernel crash. Move the switch ahead of the access and clobber RSP which has been saved already. Fixes: 8a09317b895f ("x86/mm/pti: Prepare the x86/entry assembly code for entry/exit CR3 switching") Reported-by: Lars Wendler <wendler.lars(a)web.de> Reported-by: Laura Abbott <labbott(a)redhat.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Borislav Betkov <bp(a)alien8.de> Cc: Andy Lutomirski <luto(a)kernel.org>, Cc: Dave Hansen <dave.hansen(a)linux.intel.com>, Cc: Peter Zijlstra <peterz(a)infradead.org>, Cc: Greg KH <gregkh(a)linuxfoundation.org>, , Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>, Cc: Juergen Gross <jgross(a)suse.com> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801031949200.1957@nanos Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/entry/entry_64_compat.S | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -190,8 +190,13 @@ ENTRY(entry_SYSCALL_compat) /* Interrupts are off on entry. */ swapgs - /* Stash user ESP and switch to the kernel stack. */ + /* Stash user ESP */ movl %esp, %r8d + + /* Use %rsp as scratch reg. User ESP is stashed in r8 */ + SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp + + /* Switch to the kernel stack */ movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp /* Construct struct pt_regs on stack */ @@ -220,12 +225,6 @@ GLOBAL(entry_SYSCALL_compat_after_hwfram pushq $0 /* pt_regs->r15 = 0 */ /* - * We just saved %rdi so it is safe to clobber. It is not - * preserved during the C calls inside TRACE_IRQS_OFF anyway. - */ - SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi - - /* * User mode is traced as though IRQs are on, and SYSENTER * turned them off. */ Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.14/x86-pti-switch-to-kernel-cr3-at-early-in-entry_syscall_compat.patch queue-4.14/x86-dumpstack-print-registers-for-first-stack-frame.patch queue-4.14/x86-process-define-cpu_tss_rw-in-same-section-as-declaration.patch queue-4.14/x86-pti-make-sure-the-user-kernel-ptes-match.patch queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch queue-4.14/x86-dumpstack-fix-partial-register-dumps.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/process: Define cpu_tss_rw in same section as declaration" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/process: Define cpu_tss_rw in same section as declaration to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-process-define-cpu_tss_rw-in-same-section-as-declaration.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2fd9c41aea47f4ad071accf94b94f94f2c4d31eb Mon Sep 17 00:00:00 2001 From: Nick Desaulniers <ndesaulniers(a)google.com> Date: Wed, 3 Jan 2018 12:39:52 -0800 Subject: x86/process: Define cpu_tss_rw in same section as declaration From: Nick Desaulniers <ndesaulniers(a)google.com> commit 2fd9c41aea47f4ad071accf94b94f94f2c4d31eb upstream. cpu_tss_rw is declared with DECLARE_PER_CPU_PAGE_ALIGNED but then defined with DEFINE_PER_CPU_SHARED_ALIGNED leading to section mismatch warnings. Use DEFINE_PER_CPU_PAGE_ALIGNED consistently. This is necessary because it's mapped to the cpu entry area and must be page aligned. [ tglx: Massaged changelog a bit ] Fixes: 1a935bc3d4ea ("x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct") Suggested-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: thomas.lendacky(a)amd.com Cc: Borislav Petkov <bpetkov(a)suse.de> Cc: tklauser(a)distanz.ch Cc: minipli(a)googlemail.com Cc: me(a)kylehuey.com Cc: namit(a)vmware.com Cc: luto(a)kernel.org Cc: jpoimboe(a)redhat.com Cc: tj(a)kernel.org Cc: cl(a)linux.com Cc: bp(a)suse.de Cc: thgarnie(a)google.com Cc: kirill.shutemov(a)linux.intel.com Link: https://lkml.kernel.org/r/20180103203954.183360-1-ndesaulniers@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -47,7 +47,7 @@ * section. Since TSS's are completely CPU-local, we want them * on exact cacheline boundaries, to eliminate cacheline ping-pong. */ -__visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, cpu_tss_rw) = { +__visible DEFINE_PER_CPU_PAGE_ALIGNED(struct tss_struct, cpu_tss_rw) = { .x86_tss = { /* * .sp0 is only used when entering ring 0 from a lower Patches currently in stable-queue which might be from ndesaulniers(a)google.com are queue-4.14/x86-process-define-cpu_tss_rw-in-same-section-as-declaration.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/pti: Make sure the user/kernel PTEs match" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/pti: Make sure the user/kernel PTEs match to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-pti-make-sure-the-user-kernel-ptes-match.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 52994c256df36fda9a715697431cba9daecb6b11 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Wed, 3 Jan 2018 15:57:59 +0100 Subject: x86/pti: Make sure the user/kernel PTEs match From: Thomas Gleixner <tglx(a)linutronix.de> commit 52994c256df36fda9a715697431cba9daecb6b11 upstream. Meelis reported that his K8 Athlon64 emits MCE warnings when PTI is enabled: [Hardware Error]: Error Addr: 0x0000ffff81e000e0 [Hardware Error]: MC1 Error: L1 TLB multimatch. [Hardware Error]: cache level: L1, tx: INSN The address is in the entry area, which is mapped into kernel _AND_ user space. That's special because we switch CR3 while we are executing there. User mapping: 0xffffffff81e00000-0xffffffff82000000 2M ro PSE GLB x pmd Kernel mapping: 0xffffffff81000000-0xffffffff82000000 16M ro PSE x pmd So the K8 is complaining that the TLB entries differ. They differ in the GLB bit. Drop the GLB bit when installing the user shared mapping. Fixes: 6dc72c3cbca0 ("x86/mm/pti: Share entry text PMD") Reported-by: Meelis Roos <mroos(a)linux.ee> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Meelis Roos <mroos(a)linux.ee> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801031407180.1957@nanos Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/mm/pti.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/mm/pti.c +++ b/arch/x86/mm/pti.c @@ -367,7 +367,8 @@ static void __init pti_setup_espfix64(vo static void __init pti_clone_entry_text(void) { pti_clone_pmds((unsigned long) __entry_text_start, - (unsigned long) __irqentry_text_end, _PAGE_RW); + (unsigned long) __irqentry_text_end, + _PAGE_RW | _PAGE_GLOBAL); } /* Patches currently in stable-queue which might be from tglx(a)linutronix.de are queue-4.14/x86-pti-switch-to-kernel-cr3-at-early-in-entry_syscall_compat.patch queue-4.14/x86-dumpstack-print-registers-for-first-stack-frame.patch queue-4.14/x86-process-define-cpu_tss_rw-in-same-section-as-declaration.patch queue-4.14/x86-pti-make-sure-the-user-kernel-ptes-match.patch queue-4.14/x86-cpu-x86-pti-do-not-enable-pti-on-amd-processors.patch queue-4.14/x86-dumpstack-fix-partial-register-dumps.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/dumpstack: Fix partial register dumps" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/dumpstack: Fix partial register dumps to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-dumpstack-fix-partial-register-dumps.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a9cdbe72c4e8bf3b38781c317a79326e2e1a230d Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf <jpoimboe(a)redhat.com> Date: Sun, 31 Dec 2017 10:18:06 -0600 Subject: x86/dumpstack: Fix partial register dumps MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Josh Poimboeuf <jpoimboe(a)redhat.com> commit a9cdbe72c4e8bf3b38781c317a79326e2e1a230d upstream. The show_regs_safe() logic is wrong. When there's an iret stack frame, it prints the entire pt_regs -- most of which is random stack data -- instead of just the five registers at the end. show_regs_safe() is also poorly named: the on_stack() checks aren't for safety. Rename the function to show_regs_if_on_stack() and add a comment to explain why the checks are needed. These issues were introduced with the "partial register dump" feature of the following commit: b02fcf9ba121 ("x86/unwinder: Handle stack overflows more gracefully") That patch had gone through a few iterations of development, and the above issues were artifacts from a previous iteration of the patch where 'regs' pointed directly to the iret frame rather than to the (partially empty) pt_regs. Tested-by: Alexander Tsoy <alexander(a)tsoy.me> Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Toralf Förster <toralf.foerster(a)gmx.de> Fixes: b02fcf9ba121 ("x86/unwinder: Handle stack overflows more gracefully") Link: http://lkml.kernel.org/r/5b05b8b344f59db2d3d50dbdeba92d60f2304c54.151473674… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/unwind.h | 17 +++++++++++++---- arch/x86/kernel/dumpstack.c | 28 ++++++++++++++++++++-------- arch/x86/kernel/stacktrace.c | 2 +- 3 files changed, 34 insertions(+), 13 deletions(-) --- a/arch/x86/include/asm/unwind.h +++ b/arch/x86/include/asm/unwind.h @@ -56,18 +56,27 @@ void unwind_start(struct unwind_state *s #if defined(CONFIG_UNWINDER_ORC) || defined(CONFIG_UNWINDER_FRAME_POINTER) /* - * WARNING: The entire pt_regs may not be safe to dereference. In some cases, - * only the iret frame registers are accessible. Use with caution! + * If 'partial' returns true, only the iret frame registers are valid. */ -static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state) +static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state, + bool *partial) { if (unwind_done(state)) return NULL; + if (partial) { +#ifdef CONFIG_UNWINDER_ORC + *partial = !state->full_regs; +#else + *partial = false; +#endif + } + return state->regs; } #else -static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state) +static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state, + bool *partial) { return NULL; } --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -76,12 +76,23 @@ void show_iret_regs(struct pt_regs *regs regs->sp, regs->flags); } -static void show_regs_safe(struct stack_info *info, struct pt_regs *regs) +static void show_regs_if_on_stack(struct stack_info *info, struct pt_regs *regs, + bool partial) { - if (on_stack(info, regs, sizeof(*regs))) + /* + * These on_stack() checks aren't strictly necessary: the unwind code + * has already validated the 'regs' pointer. The checks are done for + * ordering reasons: if the registers are on the next stack, we don't + * want to print them out yet. Otherwise they'll be shown as part of + * the wrong stack. Later, when show_trace_log_lvl() switches to the + * next stack, this function will be called again with the same regs so + * they can be printed in the right context. + */ + if (!partial && on_stack(info, regs, sizeof(*regs))) { __show_regs(regs, 0); - else if (on_stack(info, (void *)regs + IRET_FRAME_OFFSET, - IRET_FRAME_SIZE)) { + + } else if (partial && on_stack(info, (void *)regs + IRET_FRAME_OFFSET, + IRET_FRAME_SIZE)) { /* * When an interrupt or exception occurs in entry code, the * full pt_regs might not have been saved yet. In that case @@ -98,6 +109,7 @@ void show_trace_log_lvl(struct task_stru struct stack_info stack_info = {0}; unsigned long visit_mask = 0; int graph_idx = 0; + bool partial; printk("%sCall Trace:\n", log_lvl); @@ -140,7 +152,7 @@ void show_trace_log_lvl(struct task_stru printk("%s <%s>\n", log_lvl, stack_name); if (regs) - show_regs_safe(&stack_info, regs); + show_regs_if_on_stack(&stack_info, regs, partial); /* * Scan the stack, printing any text addresses we find. At the @@ -164,7 +176,7 @@ void show_trace_log_lvl(struct task_stru /* * Don't print regs->ip again if it was already printed - * by show_regs_safe() below. + * by show_regs_if_on_stack(). */ if (regs && stack == &regs->ip) goto next; @@ -199,9 +211,9 @@ next: unwind_next_frame(&state); /* if the frame has entry regs, print them */ - regs = unwind_get_entry_regs(&state); + regs = unwind_get_entry_regs(&state, &partial); if (regs) - show_regs_safe(&stack_info, regs); + show_regs_if_on_stack(&stack_info, regs, partial); } if (stack_name) --- a/arch/x86/kernel/stacktrace.c +++ b/arch/x86/kernel/stacktrace.c @@ -98,7 +98,7 @@ static int __save_stack_trace_reliable(s for (unwind_start(&state, task, NULL, NULL); !unwind_done(&state); unwind_next_frame(&state)) { - regs = unwind_get_entry_regs(&state); + regs = unwind_get_entry_regs(&state, NULL); if (regs) { /* * Kernel mode registers on the stack indicate an Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are queue-4.14/x86-dumpstack-print-registers-for-first-stack-frame.patch queue-4.14/x86-process-define-cpu_tss_rw-in-same-section-as-declaration.patch queue-4.14/x86-dumpstack-fix-partial-register-dumps.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/dumpstack: Print registers for first stack frame" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/dumpstack: Print registers for first stack frame to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-dumpstack-print-registers-for-first-stack-frame.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3ffdeb1a02be3086f1411a15c5b9c481fa28e21f Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf <jpoimboe(a)redhat.com> Date: Sun, 31 Dec 2017 10:18:07 -0600 Subject: x86/dumpstack: Print registers for first stack frame MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Josh Poimboeuf <jpoimboe(a)redhat.com> commit 3ffdeb1a02be3086f1411a15c5b9c481fa28e21f upstream. In the stack dump code, if the frame after the starting pt_regs is also a regs frame, the registers don't get printed. Fix that. Reported-by: Andy Lutomirski <luto(a)amacapital.net> Tested-by: Alexander Tsoy <alexander(a)tsoy.me> Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Toralf Förster <toralf.foerster(a)gmx.de> Fixes: 3b3fa11bc700 ("x86/dumpstack: Print any pt_regs found on the stack") Link: http://lkml.kernel.org/r/396f84491d2f0ef64eda4217a2165f5712f6a115.151473674… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/dumpstack.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -115,6 +115,7 @@ void show_trace_log_lvl(struct task_stru unwind_start(&state, task, regs, stack); stack = stack ? : get_stack_pointer(task, regs); + regs = unwind_get_entry_regs(&state, &partial); /* * Iterate through the stacks, starting with the current stack pointer. @@ -132,7 +133,7 @@ void show_trace_log_lvl(struct task_stru * - hardirq stack * - entry stack */ - for (regs = NULL; stack; stack = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { + for ( ; stack; stack = PTR_ALIGN(stack_info.next_sp, sizeof(long))) { const char *stack_name; if (get_stack_info(stack, task, &stack_info, &visit_mask)) { Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are queue-4.14/x86-dumpstack-print-registers-for-first-stack-frame.patch queue-4.14/x86-process-define-cpu_tss_rw-in-same-section-as-declaration.patch queue-4.14/x86-dumpstack-fix-partial-register-dumps.patch

6 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2018