With Arnd's script [1] help, I found some bugfixes in Spreadtrum 4.14 product kernel, but missing in v4.14.146:
513e1073d52e locking/lockdep: Add debug_locks check in __lock_downgrade() 957063c92473 pinctrl: sprd: Use define directive for sprd_pinconf_params values 87a2b65fc855 power: supply: sysfs: ratelimit property read error message
[1] https://lore.kernel.org/lkml/20190322154425.3852517-19-arnd@arndb.de/T/
Changes from v2: - Drop 2 unnecessary patches (patch 1 and patch 6) from v2 patch set. - Backport these patches to 4.19.y.
Changes from v1: - Drop 2 unnecessary patches (patch 1 and patch 4) from v1 patch set. - Add upstream commit id in change log for each stable patch.
David Lechner (1): power: supply: sysfs: ratelimit property read error message
Nathan Chancellor (1): pinctrl: sprd: Use define directive for sprd_pinconf_params values
Waiman Long (1): locking/lockdep: Add debug_locks check in __lock_downgrade()
drivers/pinctrl/sprd/pinctrl-sprd.c | 6 ++---- drivers/power/supply/power_supply_sysfs.c | 3 ++- kernel/locking/lockdep.c | 3 +++ 3 files changed, 7 insertions(+), 5 deletions(-)
From: Waiman Long longman@redhat.com
[Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf]
Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning.
Fix that by add a check for debug_locks at the beginning of __lock_downgrade().
Reported-by: Tetsuo Handa penguin-kernel@i-love.sakura.ne.jp Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com Signed-off-by: Waiman Long longman@redhat.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Paul E. McKenney paulmck@linux.vnet.ibm.com Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will.deacon@arm.com Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.c... Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Baolin Wang baolin.wang@linaro.org --- kernel/locking/lockdep.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 565005a..5c370c6 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct *curr, unsigned int depth, unsigned int depth; int i;
+ if (unlikely(!debug_locks)) + return 0; + depth = curr->lockdep_depth; /* * This function is about (re)setting the class of a held lock,
On 9/25/19 6:01 AM, Baolin Wang wrote:
From: Waiman Long longman@redhat.com
[Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf]
Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning.
Fix that by add a check for debug_locks at the beginning of __lock_downgrade().
Reported-by: Tetsuo Handa penguin-kernel@i-love.sakura.ne.jp Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com Signed-off-by: Waiman Long longman@redhat.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Paul E. McKenney paulmck@linux.vnet.ibm.com Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will.deacon@arm.com Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.c... Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Baolin Wang baolin.wang@linaro.org
kernel/locking/lockdep.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 565005a..5c370c6 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct *curr, unsigned int depth, unsigned int depth; int i;
- if (unlikely(!debug_locks))
return 0;- depth = curr->lockdep_depth; /*
- This function is about (re)setting the class of a held lock,
Apparently, there are 2 such patches in the upstream kernel - commit 513e1073d52e55b8024b4f238a48de7587c64ccf and 71492580571467fb7177aade19c18ce7486267f5. These are probably caused by the fact that there are 2 places in the code that can match the hunks. Anyway, this looks like it is applying to the wrong function. It should be applied to __lock_downgrade. Though it shouldn't harm if it is applied to the wrong function.
Cheers, Longman
On Wed, 25 Sep 2019 at 22:05, Waiman Long longman@redhat.com wrote:
On 9/25/19 6:01 AM, Baolin Wang wrote:
From: Waiman Long longman@redhat.com
[Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf]
Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning.
Fix that by add a check for debug_locks at the beginning of __lock_downgrade().
Reported-by: Tetsuo Handa penguin-kernel@i-love.sakura.ne.jp Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com Signed-off-by: Waiman Long longman@redhat.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Paul E. McKenney paulmck@linux.vnet.ibm.com Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will.deacon@arm.com Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.c... Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Baolin Wang baolin.wang@linaro.org
kernel/locking/lockdep.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 565005a..5c370c6 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct *curr, unsigned int depth, unsigned int depth; int i;
if (unlikely(!debug_locks))return 0;depth = curr->lockdep_depth; /* * This function is about (re)setting the class of a held lock,Apparently, there are 2 such patches in the upstream kernel - commit 513e1073d52e55b8024b4f238a48de7587c64ccf and 71492580571467fb7177aade19c18ce7486267f5. These are probably caused by the fact that there are 2 places in the code that can match the hunks. Anyway, this looks like it is applying to the wrong function. It should be applied to __lock_downgrade. Though it shouldn't harm if it is applied to the wrong function.
Ah, I noticed there are 2 commits with the same commit message, though 513e1073d52e55b8024b4f238a48de7587c64ccf patch did not change the __lock_downgrade(), which is really confusing. This patch (513e1073d52e55b8024b4f238a48de7587c64ccf) did the right thing, and 71492580571467fb7177aade19c18ce7486267f5 patch should be applied to __lock_downgrade.
I'll backport commit 71492580571467fb7177aade19c18ce7486267f5 too in future. Thanks.
From: Nathan Chancellor natechancellor@gmail.com
[Upstream commit 957063c924736d4341e5d588757b9f31e8f6fa24]
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/sprd/pinctrl-sprd.c:845:19: warning: implicit conversion from enumeration type 'enum sprd_pinconf_params' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] {"sprd,control", SPRD_PIN_CONFIG_CONTROL, 0}, ~ ^~~~~~~~~~~~~~~~~~~~~~~ drivers/pinctrl/sprd/pinctrl-sprd.c:846:22: warning: implicit conversion from enumeration type 'enum sprd_pinconf_params' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] {"sprd,sleep-mode", SPRD_PIN_CONFIG_SLEEP_MODE, 0}, ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
It is expected that pinctrl drivers can extend pin_config_param because of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion isn't an issue. Most drivers that take advantage of this define the PIN_CONFIG variables as constants, rather than enumerated values. Do the same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/138 Signed-off-by: Nathan Chancellor natechancellor@gmail.com Reviewed-by: Baolin Wang baolin.wang@linaro.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Baolin Wang baolin.wang@linaro.org --- drivers/pinctrl/sprd/pinctrl-sprd.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c b/drivers/pinctrl/sprd/pinctrl-sprd.c index 6352991..83958bd 100644 --- a/drivers/pinctrl/sprd/pinctrl-sprd.c +++ b/drivers/pinctrl/sprd/pinctrl-sprd.c @@ -159,10 +159,8 @@ struct sprd_pinctrl { struct sprd_pinctrl_soc_info *info; };
-enum sprd_pinconf_params { - SPRD_PIN_CONFIG_CONTROL = PIN_CONFIG_END + 1, - SPRD_PIN_CONFIG_SLEEP_MODE = PIN_CONFIG_END + 2, -}; +#define SPRD_PIN_CONFIG_CONTROL (PIN_CONFIG_END + 1) +#define SPRD_PIN_CONFIG_SLEEP_MODE (PIN_CONFIG_END + 2)
static int sprd_pinctrl_get_id_by_name(struct sprd_pinctrl *sprd_pctl, const char *name)
From: David Lechner david@lechnology.com
[Upstream commit 87a2b65fc855e6be50f791c2ebbb492541896827]
This adds rate limiting to the message that is printed when reading a power supply property via sysfs returns an error. This will prevent userspace applications from unintentionally dDOSing the system by continuously reading a property that returns an error.
Signed-off-by: David Lechner david@lechnology.com Signed-off-by: Sebastian Reichel sebastian.reichel@collabora.com Signed-off-by: Baolin Wang baolin.wang@linaro.org --- drivers/power/supply/power_supply_sysfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c index eb5dc74..2ccaf4f 100644 --- a/drivers/power/supply/power_supply_sysfs.c +++ b/drivers/power/supply/power_supply_sysfs.c @@ -91,7 +91,8 @@ static ssize_t power_supply_show_property(struct device *dev, dev_dbg(dev, "driver has no data for `%s' property\n", attr->attr.name); else if (ret != -ENODEV && ret != -EAGAIN) - dev_err(dev, "driver failed to report `%s' property: %zd\n", + dev_err_ratelimited(dev, + "driver failed to report `%s' property: %zd\n", attr->attr.name, ret); return ret; }
linux-stable-mirror@lists.linaro.org
-
Baolin Wang -
Waiman Long