commit 605b0487f0bc1ae9963bf52ece0f5c8055186f81 upstream.
Mark Syms has reported seeing tasks that are stuck waiting in
find_insert_glock. It turns out that struct lm_lockname contains four padding
bytes on 64-bit architectures that function glock_waitqueue doesn't skip when
hashing the glock name. As a result, we can end up waking up the wrong
waitqueue, and the waiting tasks may be stuck forever.
Fix that by using ht_parms.key_len instead of sizeof(struct lm_lockname) for
the key length.
Reported-by: Mark Syms <mark.syms(a)citrix.com>
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
Signed-off-by: Bob Peterson <rpeterso(a)redhat.com>
Cc: stable(a)vger.kernel.org # v4.14+
---
fs/gfs2/glock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index f66773c71bcde..d32964cd11176 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -107,7 +107,7 @@ static int glock_wake_function(wait_queue_entry_t *wait, unsigned int mode,
static wait_queue_head_t *glock_waitqueue(struct lm_lockname *name)
{
- u32 hash = jhash2((u32 *)name, sizeof(*name) / 4, 0);
+ u32 hash = jhash2((u32 *)name, ht_parms.key_len / 4, 0);
return glock_wait_table + hash_32(hash, GLOCK_WAIT_TABLE_BITS);
}
--
2.20.1
commit 28928a3ce142b2e4e5a7a0f067cefb41a3d2c3f9 upstream.
In Odroid XU3 Lite board, the temperature levels reported for thermal
zone 0 were weird. In warm room:
/sys/class/thermal/thermal_zone0/temp:32000
/sys/class/thermal/thermal_zone1/temp:51000
/sys/class/thermal/thermal_zone2/temp:55000
/sys/class/thermal/thermal_zone3/temp:54000
/sys/class/thermal/thermal_zone4/temp:51000
Sometimes after booting the value was even equal to ambient temperature
which is highly unlikely to be a real temperature of sensor in SoC.
The thermal sensor's calibration (trimming) is based on fused values.
In case of the board above, the fused values are: 35, 52, 43, 58 and 43
(corresponding to each TMU device). However driver defined a minimum value
for fused data as 40 and for smaller values it was using a hard-coded 55
instead. This lead to mapping data from sensor to wrong temperatures
for thermal zone 0.
Various vendor 3.10 trees (Hardkernel's based on Samsung LSI, Artik 10)
do not impose any limits on fused values. Since we do not have any
knowledge about these limits, use 0 as a minimum accepted fused value.
This should essentially allow accepting any reasonable fused value thus
behaving like vendor driver.
The exynos5420-tmu-sensor-conf.dtsi is copied directly from existing
exynos4412 with one change - the samsung,tmu_min_efuse_value.
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Acked-by: Eduardo Valentin <edubezval(a)gmail.com>
Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Reviewed-by: Anand Moon <linux.amoon(a)gmail.com>
Tested-by: Anand Moon <linux.amoon(a)gmail.com>
---
arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi | 25 +++++++++++++++++++++++
arch/arm/boot/dts/exynos5420.dtsi | 10 ++++-----
2 files changed, 30 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
diff --git a/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
new file mode 100644
index 000000000000..c8771c660550
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for Exynos5420 TMU sensor configuration
+ *
+ * Copyright (c) 2014 Lukasz Majewski <l.majewski(a)samsung.com>
+ * Copyright (c) 2017 Krzysztof Kozlowski <krzk(a)kernel.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <dt-bindings/thermal/thermal_exynos.h>
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <8>;
+samsung,tmu_reference_voltage = <16>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <55>;
+samsung,tmu_min_efuse_value = <0>;
+samsung,tmu_max_efuse_value = <100>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <85>;
+samsung,tmu_default_temp_offset = <50>;
+samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 00c4cfa54839..52f3d911f67f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -694,7 +694,7 @@
interrupts = <0 65 0>;
clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_cpu1: tmu@10064000 {
@@ -703,7 +703,7 @@
interrupts = <0 183 0>;
clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_cpu2: tmu@10068000 {
@@ -712,7 +712,7 @@
interrupts = <0 184 0>;
clocks = <&clock CLK_TMU>, <&clock CLK_TMU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_cpu3: tmu@1006c000 {
@@ -721,7 +721,7 @@
interrupts = <0 185 0>;
clocks = <&clock CLK_TMU>, <&clock CLK_TMU_GPU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_gpu: tmu@100a0000 {
@@ -730,7 +730,7 @@
interrupts = <0 215 0>;
clocks = <&clock CLK_TMU_GPU>, <&clock CLK_TMU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
sysmmu_g2dr: sysmmu@0x10A60000 {
--
2.7.4
commit 28928a3ce142b2e4e5a7a0f067cefb41a3d2c3f9 upstream.
In Odroid XU3 Lite board, the temperature levels reported for thermal
zone 0 were weird. In warm room:
/sys/class/thermal/thermal_zone0/temp:32000
/sys/class/thermal/thermal_zone1/temp:51000
/sys/class/thermal/thermal_zone2/temp:55000
/sys/class/thermal/thermal_zone3/temp:54000
/sys/class/thermal/thermal_zone4/temp:51000
Sometimes after booting the value was even equal to ambient temperature
which is highly unlikely to be a real temperature of sensor in SoC.
The thermal sensor's calibration (trimming) is based on fused values.
In case of the board above, the fused values are: 35, 52, 43, 58 and 43
(corresponding to each TMU device). However driver defined a minimum value
for fused data as 40 and for smaller values it was using a hard-coded 55
instead. This lead to mapping data from sensor to wrong temperatures
for thermal zone 0.
Various vendor 3.10 trees (Hardkernel's based on Samsung LSI, Artik 10)
do not impose any limits on fused values. Since we do not have any
knowledge about these limits, use 0 as a minimum accepted fused value.
This should essentially allow accepting any reasonable fused value thus
behaving like vendor driver.
The exynos5420-tmu-sensor-conf.dtsi is copied directly from existing
exynos4412 with one change - the samsung,tmu_min_efuse_value.
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Acked-by: Eduardo Valentin <edubezval(a)gmail.com>
Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Reviewed-by: Anand Moon <linux.amoon(a)gmail.com>
Tested-by: Anand Moon <linux.amoon(a)gmail.com>
---
arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi | 25 +++++++++++++++++++++++
arch/arm/boot/dts/exynos5420.dtsi | 10 ++++-----
2 files changed, 30 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
diff --git a/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
new file mode 100644
index 000000000000..c8771c660550
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for Exynos5420 TMU sensor configuration
+ *
+ * Copyright (c) 2014 Lukasz Majewski <l.majewski(a)samsung.com>
+ * Copyright (c) 2017 Krzysztof Kozlowski <krzk(a)kernel.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <dt-bindings/thermal/thermal_exynos.h>
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <8>;
+samsung,tmu_reference_voltage = <16>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <55>;
+samsung,tmu_min_efuse_value = <0>;
+samsung,tmu_max_efuse_value = <100>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <85>;
+samsung,tmu_default_temp_offset = <50>;
+samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 1b3d6c769a3c..d5edb7766942 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -777,7 +777,7 @@
interrupts = <0 65 0>;
clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_cpu1: tmu@10064000 {
@@ -786,7 +786,7 @@
interrupts = <0 183 0>;
clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_cpu2: tmu@10068000 {
@@ -795,7 +795,7 @@
interrupts = <0 184 0>;
clocks = <&clock CLK_TMU>, <&clock CLK_TMU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_cpu3: tmu@1006c000 {
@@ -804,7 +804,7 @@
interrupts = <0 185 0>;
clocks = <&clock CLK_TMU>, <&clock CLK_TMU_GPU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
tmu_gpu: tmu@100a0000 {
@@ -813,7 +813,7 @@
interrupts = <0 215 0>;
clocks = <&clock CLK_TMU_GPU>, <&clock CLK_TMU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
- #include "exynos4412-tmu-sensor-conf.dtsi"
+ #include "exynos5420-tmu-sensor-conf.dtsi"
};
thermal-zones {
--
2.7.4
Hi,
On Mon, Mar 11, 2019 at 08:17 PM CET, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> sk_msg: Always cancel strp work before freeing the psock
>
> to the 4.20-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:
> sk_msg-always-cancel-strp-work-before-freeing-the-ps.patch
> and it can be found in the queue-4.20 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.
There is a follow-up fix for this change - e8e3437762ad ("bpf: Stop the
psock parser before canceling its work") in bpf tree:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=e8e3…
I think this patch should not go to into stable without the follow-up
fix. Otherwise kselftests for bpf will be noisy due to kernel warnings.
Thanks,
Jakub
>
>
>
> commit d3747ebdfd2fd5e12d8d04ad3f6261503ce52913
> Author: Jakub Sitnicki <jakub(a)cloudflare.com>
> Date: Mon Jan 28 10:13:35 2019 +0100
>
> sk_msg: Always cancel strp work before freeing the psock
>
> [ Upstream commit 1d79895aef18fa05789995d86d523c9b2ee58a02 ]
>
> Despite having stopped the parser, we still need to deinitialize it
> by calling strp_done so that it cancels its work. Otherwise the worker
> thread can run after we have freed the parser, and attempt to access
> its workqueue resulting in a use-after-free:
>
> ==================================================================
> BUG: KASAN: use-after-free in pwq_activate_delayed_work+0x1b/0x1d0
> Read of size 8 at addr ffff888069975240 by task kworker/u2:2/93
>
> CPU: 0 PID: 93 Comm: kworker/u2:2 Not tainted 5.0.0-rc2-00335-g28f9d1a3d4fe-dirty #14
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
> Workqueue: (null) (kstrp)
> Call Trace:
> print_address_description+0x6e/0x2b0
> ? pwq_activate_delayed_work+0x1b/0x1d0
> kasan_report+0xfd/0x177
> ? pwq_activate_delayed_work+0x1b/0x1d0
> ? pwq_activate_delayed_work+0x1b/0x1d0
> pwq_activate_delayed_work+0x1b/0x1d0
> ? process_one_work+0x4aa/0x660
> pwq_dec_nr_in_flight+0x9b/0x100
> worker_thread+0x82/0x680
> ? process_one_work+0x660/0x660
> kthread+0x1b9/0x1e0
> ? __kthread_create_on_node+0x250/0x250
> ret_from_fork+0x1f/0x30
>
> Allocated by task 111:
> sk_psock_init+0x3c/0x1b0
> sock_map_link.isra.2+0x103/0x4b0
> sock_map_update_common+0x94/0x270
> sock_map_update_elem+0x145/0x160
> __se_sys_bpf+0x152e/0x1e10
> do_syscall_64+0xb2/0x3e0
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Freed by task 112:
> kfree+0x7f/0x140
> process_one_work+0x40b/0x660
> worker_thread+0x82/0x680
> kthread+0x1b9/0x1e0
> ret_from_fork+0x1f/0x30
>
> The buggy address belongs to the object at ffff888069975180
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 192 bytes inside of
> 512-byte region [ffff888069975180, ffff888069975380)
> The buggy address belongs to the page:
> page:ffffea0001a65d00 count:1 mapcount:0 mapping:ffff88806d401280 index:0x0 compound_mapcount: 0
> flags: 0x4000000000010200(slab|head)
> raw: 4000000000010200 dead000000000100 dead000000000200 ffff88806d401280
> raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff888069975100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff888069975180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff888069975200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff888069975280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888069975300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
> Reported-by: Marek Majkowski <marek(a)cloudflare.com>
> Signed-off-by: Jakub Sitnicki <jakub(a)cloudflare.com>
> Link: https://lore.kernel.org/netdev/CAJPywTLwgXNEZ2dZVoa=udiZmtrWJ0q5SuBW64aYs0Y…
> Acked-by: Song Liu <songliubraving(a)fb.com>
> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/net/core/skmsg.c b/net/core/skmsg.c
> index 54d854807630..4932861d7b88 100644
> --- a/net/core/skmsg.c
> +++ b/net/core/skmsg.c
> @@ -545,8 +545,7 @@ static void sk_psock_destroy_deferred(struct work_struct *gc)
> struct sk_psock *psock = container_of(gc, struct sk_psock, gc);
>
> /* No sk_callback_lock since already detached. */
> - if (psock->parser.enabled)
> - strp_done(&psock->parser.strp);
> + strp_done(&psock->parser.strp);
>
> cancel_work_sync(&psock->work);
>
From: Zev Weiss <zev(a)bewilderbeest.net>
Subject: kernel/sysctl.c: add missing range check in do_proc_dointvec_minmax_conv
This bug has apparently existed since the introduction of this function in
the pre-git era (4500e91754d3 in Thomas Gleixner's history.git, "[NET]:
Add proc_dointvec_userhz_jiffies, use it for proper handling of neighbour
sysctls."). As a minimal fix we can simply duplicate the corresponding
check in do_proc_dointvec_conv().
Link: http://lkml.kernel.org/r/20190207123426.9202-3-zev@bewilderbeest.net
Signed-off-by: Zev Weiss <zev(a)bewilderbeest.net>
Cc: Brendan Higgins <brendanhiggins(a)google.com>
Cc: Iurii Zaikin <yzaikin(a)google.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Luis Chamberlain <mcgrof(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [2.6.2+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/kernel/sysctl.c~kernel-sysctlc-add-missing-range-check-in-do_proc_dointvec_minmax_conv
+++ a/kernel/sysctl.c
@@ -2645,7 +2645,16 @@ static int do_proc_dointvec_minmax_conv(
{
struct do_proc_dointvec_minmax_conv_param *param = data;
if (write) {
- int val = *negp ? -*lvalp : *lvalp;
+ int val;
+ if (*negp) {
+ if (*lvalp > (unsigned long) INT_MAX + 1)
+ return -EINVAL;
+ val = -*lvalp;
+ } else {
+ if (*lvalp > (unsigned long) INT_MAX)
+ return -EINVAL;
+ val = *lvalp;
+ }
if ((param->min && *param->min > val) ||
(param->max && *param->max < val))
return -EINVAL;
_