This is a note to let you know that I've just added the patch titled
clk: imx: imx7d: Fix parent clock for OCRAM_CLK
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:
clk-imx-imx7d-fix-parent-clock-for-ocram_clk.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Adriana Reus <adriana.reus(a)nxp.com>
Date: Mon, 2 Oct 2017 13:32:10 +0300
Subject: clk: imx: imx7d: Fix parent clock for OCRAM_CLK
From: Adriana Reus <adriana.reus(a)nxp.com>
[ Upstream commit edc5a8e754aba9c6eaeddd18cb1e72462f99b16c ]
The parent of OCRAM_CLK should be axi_main_root_clk
and not axi_post_div.
before:
axi_src 1 1 332307692 0 0
axi_cg 1 1 332307692 0 0
axi_pre_div 1 1 332307692 0 0
axi_post_div 1 1 332307692 0 0
ocram_clk 0 0 332307692 0 0
main_axi_root_clk 1 1 332307692 0 0
after:
axi_src 1 1 332307692 0 0
axi_cg 1 1 332307692 0 0
axi_pre_div 1 1 332307692 0 0
axi_post_div 1 1 332307692 0 0
main_axi_root_clk 1 1 332307692 0 0
ocram_clk 0 0 332307692 0 0
Reference Doc: i.MX 7D Reference Manual - Chap 5, p 516
(https://www.nxp.com/docs/en/reference-manual/IMX7DRM.pdf)
Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support")
Signed-off-by: Adriana Reus <adriana.reus(a)nxp.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/imx/clk-imx7d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -797,7 +797,7 @@ static void __init imx7d_clocks_init(str
clks[IMX7D_MAIN_AXI_ROOT_CLK] = imx_clk_gate4("main_axi_root_clk", "axi_post_div", base + 0x4040, 0);
clks[IMX7D_DISP_AXI_ROOT_CLK] = imx_clk_gate4("disp_axi_root_clk", "disp_axi_post_div", base + 0x4050, 0);
clks[IMX7D_ENET_AXI_ROOT_CLK] = imx_clk_gate4("enet_axi_root_clk", "enet_axi_post_div", base + 0x4060, 0);
- clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "axi_post_div", base + 0x4110, 0);
+ clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "main_axi_root_clk", base + 0x4110, 0);
clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk", "ahb_root_clk", base + 0x4120, 0);
clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk", "dram_post_div", base + 0x4130, 0);
clks[IMX7D_DRAM_PHYM_ROOT_CLK] = imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130, 0);
Patches currently in stable-queue which might be from adriana.reus(a)nxp.com are
queue-4.14/clk-imx-imx7d-fix-parent-clock-for-ocram_clk.patch
This is a note to let you know that I've just added the patch titled
clk: hi6220: mark clock cs_atb_syspll as critical
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:
clk-hi6220-mark-clock-cs_atb_syspll-as-critical.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Leo Yan <leo.yan(a)linaro.org>
Date: Fri, 1 Sep 2017 08:47:14 +0800
Subject: clk: hi6220: mark clock cs_atb_syspll as critical
From: Leo Yan <leo.yan(a)linaro.org>
[ Upstream commit d2a3671ebe6479483a12f94fcca63c058d95ad64 ]
Clock cs_atb_syspll is pll used for coresight trace bus; when clock
cs_atb_syspll is disabled and operates its child clock node cs_atb
results in system hang. So mark clock cs_atb_syspll as critical to
keep it enabled.
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Zhangfei Gao <zhangfei.gao(a)linaro.org>
Cc: Haojian Zhuang <haojian.zhuang(a)linaro.org>
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
Signed-off-by: Michael Turquette <mturquette(a)baylibre.com>
Link: lkml.kernel.org/r/1504226835-2115-2-git-send-email-leo.yan@linaro.org
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/hisilicon/clk-hi6220.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/hisilicon/clk-hi6220.c
+++ b/drivers/clk/hisilicon/clk-hi6220.c
@@ -145,7 +145,7 @@ static struct hisi_gate_clock hi6220_sep
{ HI6220_BBPPLL_SEL, "bbppll_sel", "pll0_bbp_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 9, 0, },
{ HI6220_MEDIA_PLL_SRC, "media_pll_src", "pll_media_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 10, 0, },
{ HI6220_MMC2_SEL, "mmc2_sel", "mmc2_mux1", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 11, 0, },
- { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 12, 0, },
+ { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IS_CRITICAL, 0x270, 12, 0, },
};
static struct hisi_mux_clock hi6220_mux_clks_sys[] __initdata = {
Patches currently in stable-queue which might be from leo.yan(a)linaro.org are
queue-4.14/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch
queue-4.14/clk-hi6220-mark-clock-cs_atb_syspll-as-critical.patch
This is a note to let you know that I've just added the patch titled
btrfs: undo writable superblocke when sprouting fails
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:
btrfs-undo-writable-superblocke-when-sprouting-fails.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Anand Jain <anand.jain(a)oracle.com>
Date: Thu, 28 Sep 2017 14:51:09 +0800
Subject: btrfs: undo writable superblocke when sprouting fails
From: Anand Jain <anand.jain(a)oracle.com>
[ Upstream commit 0af2c4bf5a012a40a2f9230458087d7f068339d0 ]
When new device is being added to seed FS, seed FS is marked writable,
but when we fail to bring in the new device, we missed to undo the
writable part. This patch fixes it.
Signed-off-by: Anand Jain <anand.jain(a)oracle.com>
Reviewed-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2501,6 +2501,8 @@ int btrfs_init_new_device(struct btrfs_f
return ret;
error_trans:
+ if (seeding_dev)
+ sb->s_flags |= MS_RDONLY;
btrfs_end_transaction(trans);
rcu_string_free(device->name);
btrfs_sysfs_rm_device_link(fs_info->fs_devices, device);
Patches currently in stable-queue which might be from anand.jain(a)oracle.com are
queue-4.14/btrfs-undo-writable-superblocke-when-sprouting-fails.patch
queue-4.14/btrfs-fix-false-eio-for-missing-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: tests: Fix a memory leak in error handling path in 'run_test()'
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:
btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 10 Sep 2017 13:19:38 +0200
Subject: btrfs: tests: Fix a memory leak in error handling path in 'run_test()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 9ca2e97fa3c3216200afe35a3b111ec51cc796d2 ]
If 'btrfs_alloc_path()' fails, we must free the resources already
allocated, as done in the other error handling paths in this function.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Reviewed-by: Qu Wenruo <quwenruo.btrfs(a)gmx.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tests/free-space-tree-tests.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/btrfs/tests/free-space-tree-tests.c
+++ b/fs/btrfs/tests/free-space-tree-tests.c
@@ -500,7 +500,8 @@ static int run_test(test_func_t test_fun
path = btrfs_alloc_path();
if (!path) {
test_msg("Couldn't allocate path\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
ret = add_block_group_free_space(&trans, root->fs_info, cache);
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/video-fbdev-au1200fb-release-some-resources-if-a-memory-allocation-fails.patch
queue-4.14/video-fbdev-au1200fb-return-an-error-code-if-a-memory-allocation-fails.patch
queue-4.14/btrfs-tests-fix-a-memory-leak-in-error-handling-path-in-run_test.patch
This is a note to let you know that I've just added the patch titled
btrfs: fix false EIO for missing device
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:
btrfs-fix-false-eio-for-missing-device.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Anand Jain <anand.jain(a)oracle.com>
Date: Sat, 14 Oct 2017 08:34:02 +0800
Subject: btrfs: fix false EIO for missing device
From: Anand Jain <anand.jain(a)oracle.com>
[ Upstream commit 102ed2c5ff932439bbbe74c7bd63e6d5baa9f732 ]
When one of the device is missing, bbio_error() takes care of setting
the error status. And if its only IO that is pending in that stripe, it
fails to check the status of the other IO at %bbio_error before setting
the error %bi_status for the %orig_bio. Fix this by checking if
%bbio->error has exceeded the %bbio->max_errors.
Reproducer as below fdatasync error is seen intermittently.
mount -o degraded /dev/sdc /btrfs
dd status=none if=/dev/zero of=$(mktemp /btrfs/XXX) bs=4096 count=1 conv=fdatasync
dd: fdatasync failed for ‘/btrfs/LSe’: Input/output error
The reason for the intermittences of the problem is because
the following conditions have to be met, which depends on timing:
In btrfs_map_bio()
- the RAID1 the missing device has to be at %dev_nr = 1
In bbio_error()
. before bbio_error() is called the bio of the not-missing
device at %dev_nr = 0 must be completed so that the below
condition is true
if (atomic_dec_and_test(&bbio->stripes_pending)) {
Signed-off-by: Anand Jain <anand.jain(a)oracle.com>
Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6144,7 +6144,10 @@ static void bbio_error(struct btrfs_bio
btrfs_io_bio(bio)->mirror_num = bbio->mirror_num;
bio->bi_iter.bi_sector = logical >> 9;
- bio->bi_status = BLK_STS_IOERR;
+ if (atomic_read(&bbio->error) > bbio->max_errors)
+ bio->bi_status = BLK_STS_IOERR;
+ else
+ bio->bi_status = BLK_STS_OK;
btrfs_end_bbio(bbio, bio);
}
}
Patches currently in stable-queue which might be from anand.jain(a)oracle.com are
queue-4.14/btrfs-undo-writable-superblocke-when-sprouting-fails.patch
queue-4.14/btrfs-fix-false-eio-for-missing-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: Explicitly handle btrfs_update_root failure
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:
btrfs-explicitly-handle-btrfs_update_root-failure.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Thu, 28 Sep 2017 10:53:17 +0300
Subject: btrfs: Explicitly handle btrfs_update_root failure
From: Nikolay Borisov <nborisov(a)suse.com>
[ Upstream commit 9417ebc8a676487c6ec8825f92fb28f7dbeb5f4b ]
btrfs_udpate_root can fail and it aborts the transaction, the correct
way to handle an aborted transaction is to explicitly end with
btrfs_end_transaction. Even now the code is correct since
btrfs_commit_transaction would handle an aborted transaction but this is
more of an implementation detail. So let's be explicit in handling
failure in btrfs_update_root.
Furthermore btrfs_commit_transaction can also fail and by ignoring it's
return value we could have left the in-memory copy of the root item in
an inconsistent state. So capture the error value which allows us to
correctly revert the RO/RW flags in case of commit failure.
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/ioctl.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1842,8 +1842,13 @@ static noinline int btrfs_ioctl_subvol_s
ret = btrfs_update_root(trans, fs_info->tree_root,
&root->root_key, &root->root_item);
+ if (ret < 0) {
+ btrfs_end_transaction(trans);
+ goto out_reset;
+ }
+
+ ret = btrfs_commit_transaction(trans);
- btrfs_commit_transaction(trans);
out_reset:
if (ret)
btrfs_set_root_flags(&root->root_item, root_flags);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-explicitly-handle-btrfs_update_root-failure.patch
queue-4.14/btrfs-undo-writable-superblocke-when-sprouting-fails.patch
This is a note to let you know that I've just added the patch titled
btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit
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:
btrfs-avoid-null-pointer-dereference-on-fs_info-when-calling-btrfs_crit.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Mon, 11 Sep 2017 16:15:28 +0100
Subject: btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 3993b112dac968612b0b213ed59cb30f50b0015b ]
There are checks on fs_info in __btrfs_panic to avoid dereferencing a
null fs_info, however, there is a call to btrfs_crit that may also
dereference a null fs_info. Fix this by adding a check to see if fs_info
is null and only print the s_id if fs_info is non-null.
Detected by CoverityScan CID#401973 ("Dereference after null check")
Fixes: efe120a067c8 ("Btrfs: convert printk to btrfs_ and fix BTRFS prefix")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -202,7 +202,6 @@ static struct ratelimit_state printk_lim
void btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt, ...)
{
- struct super_block *sb = fs_info->sb;
char lvl[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = "\0";
struct va_format vaf;
va_list args;
@@ -228,7 +227,8 @@ void btrfs_printk(const struct btrfs_fs_
vaf.va = &args;
if (__ratelimit(ratelimit))
- printk("%sBTRFS %s (device %s): %pV\n", lvl, type, sb->s_id, &vaf);
+ printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
+ fs_info ? fs_info->sb->s_id : "<unknown>", &vaf);
va_end(args);
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/btrfs-avoid-null-pointer-dereference-on-fs_info-when-calling-btrfs_crit.patch
queue-4.14/ipmi_si-fix-memory-leak-on-new_smi.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_ldisc: Fix another race when closing the tty.
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:
bluetooth-hci_ldisc-fix-another-race-when-closing-the-tty.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Ronald Tschalär <ronald(a)innovation.ch>
Date: Wed, 25 Oct 2017 22:15:19 -0700
Subject: Bluetooth: hci_ldisc: Fix another race when closing the tty.
From: Ronald Tschalär <ronald(a)innovation.ch>
[ Upstream commit 0338b1b393ec7910898e8f7b25b3bf31a7282e16 ]
The following race condition still existed:
P1 P2
cancel_work_sync()
hci_uart_tx_wakeup()
hci_uart_write_work()
hci_uart_dequeue()
clear_bit(HCI_UART_PROTO_READY)
hci_unregister_dev(hdev)
hci_free_dev(hdev)
hu->proto->close(hu)
kfree(hu)
access to hdev and hu
Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids
this as any hci_uart_tx_wakeup() issued after the flag is cleared will
detect that and not schedule further work.
Signed-off-by: Ronald Tschalär <ronald(a)innovation.ch>
Reviewed-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_ldisc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -510,13 +510,13 @@ static void hci_uart_tty_close(struct tt
if (hdev)
hci_uart_close(hdev);
- cancel_work_sync(&hu->write_work);
-
if (test_bit(HCI_UART_PROTO_READY, &hu->flags)) {
write_lock_irqsave(&hu->proto_lock, flags);
clear_bit(HCI_UART_PROTO_READY, &hu->flags);
write_unlock_irqrestore(&hu->proto_lock, flags);
+ cancel_work_sync(&hu->write_work);
+
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, &hu->flags))
hci_unregister_dev(hdev);
Patches currently in stable-queue which might be from ronald(a)innovation.ch are
queue-4.14/bluetooth-hci_ldisc-fix-another-race-when-closing-the-tty.patch
This is a note to let you know that I've just added the patch titled
blk-mq-sched: dispatch from scheduler IFF progress is made in ->dispatch
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:
blk-mq-sched-dispatch-from-scheduler-iff-progress-is-made-in-dispatch.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Ming Lei <ming.lei(a)redhat.com>
Date: Sat, 14 Oct 2017 17:22:25 +0800
Subject: blk-mq-sched: dispatch from scheduler IFF progress is made in ->dispatch
From: Ming Lei <ming.lei(a)redhat.com>
[ Upstream commit 5e3d02bbafad38975099b5848f5ebadedcf7bb7e ]
When the hw queue is busy, we shouldn't take requests from the scheduler
queue any more, otherwise it is difficult to do IO merge.
This patch fixes the awful IO performance on some SCSI devices(lpfc,
qla2xxx, ...) when mq-deadline/kyber is used by not taking requests if
hw queue is busy.
Reviewed-by: Omar Sandoval <osandov(a)fb.com>
Reviewed-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-mq-sched.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -94,7 +94,7 @@ void blk_mq_sched_dispatch_requests(stru
struct request_queue *q = hctx->queue;
struct elevator_queue *e = q->elevator;
const bool has_sched_dispatch = e && e->type->ops.mq.dispatch_request;
- bool did_work = false;
+ bool do_sched_dispatch = true;
LIST_HEAD(rq_list);
/* RCU or SRCU read lock is needed before checking quiesced flag */
@@ -125,18 +125,18 @@ void blk_mq_sched_dispatch_requests(stru
*/
if (!list_empty(&rq_list)) {
blk_mq_sched_mark_restart_hctx(hctx);
- did_work = blk_mq_dispatch_rq_list(q, &rq_list);
+ do_sched_dispatch = blk_mq_dispatch_rq_list(q, &rq_list);
} else if (!has_sched_dispatch) {
blk_mq_flush_busy_ctxs(hctx, &rq_list);
blk_mq_dispatch_rq_list(q, &rq_list);
}
/*
- * We want to dispatch from the scheduler if we had no work left
- * on the dispatch list, OR if we did have work but weren't able
- * to make progress.
+ * We want to dispatch from the scheduler if there was nothing
+ * on the dispatch list or we were able to dispatch from the
+ * dispatch list.
*/
- if (!did_work && has_sched_dispatch) {
+ if (do_sched_dispatch && has_sched_dispatch) {
do {
struct request *rq;
Patches currently in stable-queue which might be from ming.lei(a)redhat.com are
queue-4.14/scsi-core-fix-a-scsi_show_rq-null-pointer-dereference.patch
queue-4.14/blk-mq-sched-dispatch-from-scheduler-iff-progress-is-made-in-dispatch.patch
This is a note to let you know that I've just added the patch titled
bcache: fix wrong cache_misses statistics
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:
bcache-fix-wrong-cache_misses-statistics.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: "tang.junhui" <tang.junhui(a)zte.com.cn>
Date: Mon, 30 Oct 2017 14:46:34 -0700
Subject: bcache: fix wrong cache_misses statistics
From: "tang.junhui" <tang.junhui(a)zte.com.cn>
[ Upstream commit c157313791a999646901b3e3c6888514ebc36d62 ]
Currently, Cache missed IOs are identified by s->cache_miss, but actually,
there are many situations that missed IOs are not assigned a value for
s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO
(s->iop.bypass = 1), or the cache_bio allocate failed. In these situations,
it will go to out_put or out_submit, and s->cache_miss is null, which leads
bch_mark_cache_accounting() to treat this IO as a hit IO.
[ML: applied by 3-way merge]
Signed-off-by: tang.junhui <tang.junhui(a)zte.com.cn>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Coly Li <colyli(a)suse.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/request.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -463,6 +463,7 @@ struct search {
unsigned recoverable:1;
unsigned write:1;
unsigned read_dirty_data:1;
+ unsigned cache_missed:1;
unsigned long start_time;
@@ -649,6 +650,7 @@ static inline struct search *search_allo
s->orig_bio = bio;
s->cache_miss = NULL;
+ s->cache_missed = 0;
s->d = d;
s->recoverable = 1;
s->write = op_is_write(bio_op(bio));
@@ -767,7 +769,7 @@ static void cached_dev_read_done_bh(stru
struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
bch_mark_cache_accounting(s->iop.c, s->d,
- !s->cache_miss, s->iop.bypass);
+ !s->cache_missed, s->iop.bypass);
trace_bcache_read(s->orig_bio, !s->cache_miss, s->iop.bypass);
if (s->iop.status)
@@ -786,6 +788,8 @@ static int cached_dev_cache_miss(struct
struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
struct bio *miss, *cache_bio;
+ s->cache_missed = 1;
+
if (s->cache_miss || s->iop.bypass) {
miss = bio_next_split(bio, sectors, GFP_NOIO, s->d->bio_split);
ret = miss == bio ? MAP_DONE : MAP_CONTINUE;
Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are
queue-4.14/bcache-fix-wrong-cache_misses-statistics.patch
This is a note to let you know that I've just added the patch titled
bcache: explicitly destroy mutex while exiting
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:
bcache-explicitly-destroy-mutex-while-exiting.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Liang Chen <liangchen.linux(a)gmail.com>
Date: Mon, 30 Oct 2017 14:46:35 -0700
Subject: bcache: explicitly destroy mutex while exiting
From: Liang Chen <liangchen.linux(a)gmail.com>
[ Upstream commit 330a4db89d39a6b43f36da16824eaa7a7509d34d ]
mutex_destroy does nothing most of time, but it's better to call
it to make the code future proof and it also has some meaning
for like mutex debug.
As Coly pointed out in a previous review, bcache_exit() may not be
able to handle all the references properly if userspace registers
cache and backing devices right before bch_debug_init runs and
bch_debug_init failes later. So not exposing userspace interface
until everything is ready to avoid that issue.
Signed-off-by: Liang Chen <liangchen.linux(a)gmail.com>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Coly Li <colyli(a)suse.de>
Reviewed-by: Eric Wheeler <bcache(a)linux.ewheeler.net>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/super.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -2085,6 +2085,7 @@ static void bcache_exit(void)
if (bcache_major)
unregister_blkdev(bcache_major, "bcache");
unregister_reboot_notifier(&reboot);
+ mutex_destroy(&bch_register_lock);
}
static int __init bcache_init(void)
@@ -2103,14 +2104,15 @@ static int __init bcache_init(void)
bcache_major = register_blkdev(0, "bcache");
if (bcache_major < 0) {
unregister_reboot_notifier(&reboot);
+ mutex_destroy(&bch_register_lock);
return bcache_major;
}
if (!(bcache_wq = alloc_workqueue("bcache", WQ_MEM_RECLAIM, 0)) ||
!(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) ||
- sysfs_create_files(bcache_kobj, files) ||
bch_request_init() ||
- bch_debug_init(bcache_kobj))
+ bch_debug_init(bcache_kobj) ||
+ sysfs_create_files(bcache_kobj, files))
goto err;
return 0;
Patches currently in stable-queue which might be from liangchen.linux(a)gmail.com are
queue-4.14/bcache-explicitly-destroy-mutex-while-exiting.patch
PATCH 1/2 is to fix switch upstream/downstream port error report.
PATCH 2/2 is to make AER device configuration more reasonable.
Delete the upstream/downstream port AER configuraion in PATCH 2/2,
but if firmware does not enable upstream/downstream port error reporting,
it seems current no place to enable them, so PATCH 2/2 need more
suggestion. Please see the commit log for more information.
Changes from v1:
- Rebase on v4.15-rc2.
- Modify the change log.
- Add PATCH 2/2.
Dongdong Liu (2):
PCI/portdrv: Fix switch devctrl error report enable
PCI/AER: Fix AER device configuration
drivers/pci/pcie/aer/aerdrv.c | 49 ++++-------------------------------------
drivers/pci/pcie/portdrv_core.c | 4 +++-
2 files changed, 7 insertions(+), 46 deletions(-)
--
1.9.1
This is a note to let you know that I've just added the patch titled
badblocks: fix wrong return value in badblocks_set if badblocks are disabled
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:
badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Fri, 3 Nov 2017 11:24:44 -0600
Subject: badblocks: fix wrong return value in badblocks_set if badblocks are disabled
From: Liu Bo <bo.li.liu(a)oracle.com>
[ Upstream commit 39b4954c0a1556f8f7f1fdcf59a227117fcd8a0b ]
MD's rdev_set_badblocks() expects that badblocks_set() returns 1 if
badblocks are disabled, otherwise, rdev_set_badblocks() will record
superblock changes and return success in that case and md will fail to
report an IO error which it should.
This bug has existed since badblocks were introduced in commit
9e0e252a048b ("badblocks: Add core badblock management code").
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Acked-by: Guoqing Jiang <gqjiang(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/badblocks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/block/badblocks.c
+++ b/block/badblocks.c
@@ -178,7 +178,7 @@ int badblocks_set(struct badblocks *bb,
if (bb->shift < 0)
/* badblocks are disabled */
- return 0;
+ return 1;
if (bb->shift) {
/* round the start down, and the end up */
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.14/badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.patch
queue-4.14/btrfs-fix-false-eio-for-missing-device.patch
This is a note to let you know that I've just added the patch titled
ath9k: fix tx99 potential info leak
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:
ath9k-fix-tx99-potential-info-leak.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 foo@baz Mon Dec 18 13:29:00 CET 2017
From: Miaoqing Pan <miaoqing(a)codeaurora.org>
Date: Wed, 27 Sep 2017 09:13:34 +0800
Subject: ath9k: fix tx99 potential info leak
From: Miaoqing Pan <miaoqing(a)codeaurora.org>
[ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ]
When the user sets count to zero the string buffer would remain
completely uninitialized which causes the kernel to parse its
own stack data, potentially leading to an info leak. In addition
to that, the string might be not terminated properly when the
user data does not contain a 0-terminator.
Signed-off-by: Miaoqing Pan <miaoqing(a)codeaurora.org>
Reviewed-by: Christoph Böhmwalder <christoph(a)boehmwalder.at>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/tx99.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -179,6 +179,9 @@ static ssize_t write_file_tx99(struct fi
ssize_t len;
int r;
+ if (count < 1)
+ return -EINVAL;
+
if (sc->cur_chan->nvifs > 1)
return -EOPNOTSUPP;
@@ -186,6 +189,8 @@ static ssize_t write_file_tx99(struct fi
if (copy_from_user(buf, user_buf, len))
return -EFAULT;
+ buf[len] = '\0';
+
if (strtobool(buf, &start))
return -EINVAL;
Patches currently in stable-queue which might be from miaoqing(a)codeaurora.org are
queue-4.14/ath9k-fix-tx99-potential-info-leak.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix core PCI suspend when WoWLAN is supported but disabled
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:
ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.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 foo@baz Mon Dec 18 13:29:00 CET 2017
From: Brian Norris <briannorris(a)chromium.org>
Date: Wed, 4 Oct 2017 12:22:55 +0300
Subject: ath10k: fix core PCI suspend when WoWLAN is supported but disabled
From: Brian Norris <briannorris(a)chromium.org>
[ Upstream commit 96378bd2c6cda5f04d0f6da2cd35d4670a982c38 ]
For devices where the FW supports WoWLAN but user-space has not
configured it, we don't do any PCI-specific suspend/resume operations,
because mac80211 doesn't call drv_suspend() when !wowlan. This has
particularly bad effects for some platforms, because we don't stop the
power-save timer, and if this timer goes off after the PCI controller
has suspended the link, Bad Things will happen.
Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
got some of this right, in that it understood there was a problem on
non-WoWLAN firmware. But it forgot the $subject case.
Fix this by moving all the PCI driver suspend/resume logic exclusively
into the driver PM hooks. This shouldn't affect WoWLAN support much
(this just gets executed later on).
I would just as well kill the entirety of ath10k_hif_suspend(), as it's
not even implemented on the USB or SDIO drivers. I expect that we don't
need the callback, except to return "supported" (i.e., 0) or "not
supported" (i.e., -EOPNOTSUPP).
Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
Cc: Ryan Hsu <ryanhsu(a)qti.qualcomm.com>
Cc: Kalle Valo <kvalo(a)qca.qualcomm.com>
Cc: Michal Kazior <michal.kazior(a)tieto.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/pci.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2581,6 +2581,12 @@ void ath10k_pci_hif_power_down(struct at
static int ath10k_pci_hif_suspend(struct ath10k *ar)
{
+ /* Nothing to do; the important stuff is in the driver suspend. */
+ return 0;
+}
+
+static int ath10k_pci_suspend(struct ath10k *ar)
+{
/* The grace timer can still be counting down and ar->ps_awake be true.
* It is known that the device may be asleep after resuming regardless
* of the SoC powersave state before suspending. Hence make sure the
@@ -2593,6 +2599,12 @@ static int ath10k_pci_hif_suspend(struct
static int ath10k_pci_hif_resume(struct ath10k *ar)
{
+ /* Nothing to do; the important stuff is in the driver resume. */
+ return 0;
+}
+
+static int ath10k_pci_resume(struct ath10k *ar)
+{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
struct pci_dev *pdev = ar_pci->pdev;
u32 val;
@@ -3401,11 +3413,7 @@ static __maybe_unused int ath10k_pci_pm_
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
- ar->running_fw->fw_file.fw_features))
- return 0;
-
- ret = ath10k_hif_suspend(ar);
+ ret = ath10k_pci_suspend(ar);
if (ret)
ath10k_warn(ar, "failed to suspend hif: %d\n", ret);
@@ -3417,11 +3425,7 @@ static __maybe_unused int ath10k_pci_pm_
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
- if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
- ar->running_fw->fw_file.fw_features))
- return 0;
-
- ret = ath10k_hif_resume(ar);
+ ret = ath10k_pci_resume(ar);
if (ret)
ath10k_warn(ar, "failed to resume hif: %d\n", ret);
Patches currently in stable-queue which might be from briannorris(a)chromium.org are
queue-4.14/ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch
queue-4.14/ath10k-fix-build-errors-with-config_pm.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix build errors with !CONFIG_PM
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:
ath10k-fix-build-errors-with-config_pm.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 foo@baz Mon Dec 18 13:29:00 CET 2017
From: Brian Norris <briannorris(a)chromium.org>
Date: Thu, 19 Oct 2017 11:45:19 -0700
Subject: ath10k: fix build errors with !CONFIG_PM
From: Brian Norris <briannorris(a)chromium.org>
[ Upstream commit 20665a9076d48e9abd9a2db13d307f58f7ef6647 ]
Build errors have been reported with CONFIG_PM=n:
drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
declaration of function 'ath10k_pci_suspend'
[-Werror=implicit-function-declaration]
drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
declaration of function 'ath10k_pci_resume'
[-Werror=implicit-function-declaration]
These are caused by the combination of the following two commits:
6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused")
96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but
disabled")
Both build fine on their own.
But now that ath10k_pci_pm_{suspend,resume}() is compiled
unconditionally, we should also compile ath10k_pci_{suspend,resume}()
unconditionally.
And drop the #ifdef around ath10k_pci_hif_{suspend,resume}() too; they
are trivial (empty), so we're not saving much space by compiling them
out. And the alternatives would be to sprinkle more __maybe_unused, or
spread the #ifdef's further.
Build tested with the following combinations:
CONFIG_PM=y && CONFIG_PM_SLEEP=y
CONFIG_PM=y && CONFIG_PM_SLEEP=n
CONFIG_PM=n
Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but disabled")
Fixes: 096ad2a15fd8 ("Merge branch 'ath-next'")
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/pci.c | 5 -----
1 file changed, 5 deletions(-)
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2577,8 +2577,6 @@ void ath10k_pci_hif_power_down(struct at
*/
}
-#ifdef CONFIG_PM
-
static int ath10k_pci_hif_suspend(struct ath10k *ar)
{
/* Nothing to do; the important stuff is in the driver suspend. */
@@ -2627,7 +2625,6 @@ static int ath10k_pci_resume(struct ath1
return ret;
}
-#endif
static bool ath10k_pci_validate_cal(void *data, size_t size)
{
@@ -2782,10 +2779,8 @@ static const struct ath10k_hif_ops ath10
.power_down = ath10k_pci_hif_power_down,
.read32 = ath10k_pci_read32,
.write32 = ath10k_pci_write32,
-#ifdef CONFIG_PM
.suspend = ath10k_pci_hif_suspend,
.resume = ath10k_pci_hif_resume,
-#endif
.fetch_cal_eeprom = ath10k_pci_hif_fetch_cal_eeprom,
};
Patches currently in stable-queue which might be from briannorris(a)chromium.org are
queue-4.14/ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch
queue-4.14/ath10k-fix-build-errors-with-config_pm.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod
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:
asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 1 Nov 2017 07:16:58 +0000
Subject: ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
[ Upstream commit 21781e87881f9c420871b1d1f3f29d4cd7bffb10 ]
SSI parent mod might be NULL. ssi_parent_mod() needs to care
about it. Otherwise, it uses negative shift.
This patch fixes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/ssi.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -198,10 +198,15 @@ static u32 rsnd_ssi_run_mods(struct rsnd
{
struct rsnd_mod *ssi_mod = rsnd_io_to_mod_ssi(io);
struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
+ u32 mods;
- return rsnd_ssi_multi_slaves_runtime(io) |
- 1 << rsnd_mod_id(ssi_mod) |
- 1 << rsnd_mod_id(ssi_parent_mod);
+ mods = rsnd_ssi_multi_slaves_runtime(io) |
+ 1 << rsnd_mod_id(ssi_mod);
+
+ if (ssi_parent_mod)
+ mods |= 1 << rsnd_mod_id(ssi_parent_mod);
+
+ return mods;
}
u32 rsnd_ssi_multi_slaves_runtime(struct rsnd_dai_stream *io)
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.14/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
queue-4.14/asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch
This is a note to let you know that I've just added the patch titled
ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case
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:
asoc-intel-skylake-fix-uuid_module-memory-leak-in-failure-case.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com>
Date: Tue, 7 Nov 2017 16:16:19 +0530
Subject: ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case
From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com>
[ Upstream commit f8e066521192c7debe59127d90abbe2773577e25 ]
In the loop that adds the uuid_module to the uuid_list list, allocated
memory is not properly freed in the error path free uuid_list whenever
any of the memory allocation in the loop fails to avoid memory leak.
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com>
Signed-off-by: Guneshwor Singh <guneshwor.o.singh(a)intel.com>
Acked-By: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/intel/skylake/skl-sst-utils.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/sound/soc/intel/skylake/skl-sst-utils.c
+++ b/sound/soc/intel/skylake/skl-sst-utils.c
@@ -251,6 +251,7 @@ int snd_skl_parse_uuids(struct sst_dsp *
struct uuid_module *module;
struct firmware stripped_fw;
unsigned int safe_file;
+ int ret = 0;
/* Get the FW pointer to derive ADSP header */
stripped_fw.data = fw->data;
@@ -299,8 +300,10 @@ int snd_skl_parse_uuids(struct sst_dsp *
for (i = 0; i < num_entry; i++, mod_entry++) {
module = kzalloc(sizeof(*module), GFP_KERNEL);
- if (!module)
- return -ENOMEM;
+ if (!module) {
+ ret = -ENOMEM;
+ goto free_uuid_list;
+ }
uuid_bin = (uuid_le *)mod_entry->uuid.id;
memcpy(&module->uuid, uuid_bin, sizeof(module->uuid));
@@ -311,8 +314,8 @@ int snd_skl_parse_uuids(struct sst_dsp *
size = sizeof(int) * mod_entry->instance_max_count;
module->instance_id = devm_kzalloc(ctx->dev, size, GFP_KERNEL);
if (!module->instance_id) {
- kfree(module);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto free_uuid_list;
}
list_add_tail(&module->list, &skl->uuid_list);
@@ -323,6 +326,10 @@ int snd_skl_parse_uuids(struct sst_dsp *
}
return 0;
+
+free_uuid_list:
+ skl_freeup_uuid_list(skl);
+ return ret;
}
void skl_freeup_uuid_list(struct skl_sst *ctx)
Patches currently in stable-queue which might be from pankaj.laxminarayan.bharadiya(a)intel.com are
queue-4.14/asoc-intel-skylake-fix-uuid_module-memory-leak-in-failure-case.patch
This is a note to let you know that I've just added the patch titled
arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27
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:
arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Nick Desaulniers <ndesaulniers(a)google.com>
Date: Fri, 27 Oct 2017 09:33:41 -0700
Subject: arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27
From: Nick Desaulniers <ndesaulniers(a)google.com>
[ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ]
Upon upgrading to binutils 2.27, we found that our lz4 and gzip
compressed kernel images were significantly larger, resulting is 10ms
boot time regressions.
As noted by Rahul:
"aarch64 binaries uses RELA relocations, where each relocation entry
includes an addend value. This is similar to x86_64. On x86_64, the
addend values are also stored at the relocation offset for relative
relocations. This is an optimization: in the case where code does not
need to be relocated, the loader can simply skip processing relative
relocations. In binutils-2.25, both bfd and gold linkers did this for
x86_64, but only the gold linker did this for aarch64. The kernel build
here is using the bfd linker, which stored zeroes at the relocation
offsets for relative relocations. Since a set of zeroes compresses
better than a set of non-zero addend values, this behavior was resulting
in much better lz4 compression.
The bfd linker in binutils-2.27 is now storing the actual addend values
at the relocation offsets. The behavior is now consistent with what it
does for x86_64 and what gold linker does for both architectures. The
change happened in this upstream commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad8980…
Since a bunch of zeroes got replaced by non-zero addend values, we see
the side effect of lz4 compressed image being a bit bigger.
To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs"
flag can be used:
$ LDFLAGS="--no-apply-dynamic-relocs" make
With this flag, the compressed image size is back to what it was with
binutils-2.25.
If the kernel is using ASLR, there aren't additional runtime costs to
--no-apply-dynamic-relocs, as the relocations will need to be applied
again anyway after the kernel is relocated to a random address.
If the kernel is not using ASLR, then presumably the current default
behavior of the linker is better. Since the static linker performed the
dynamic relocs, and the kernel is not moved to a different address at
load time, it can skip applying the relocations all over again."
Some measurements:
$ ld -v
GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117
^
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb
$ ld -v
GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315
^
pre patch:
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb
post patch:
$ ls -l vmlinux
-rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux
$ ls -l Image.lz4-dtb
-rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb
By Siqi's measurement w/ gzip:
binutils 2.27 with this patch (with --no-apply-dynamic-relocs):
Image 41535488
Image.gz 13404067
binutils 2.27 without this patch (without --no-apply-dynamic-relocs):
Image 41535488
Image.gz 14125516
Any compression scheme should be able to get better results from the
longer runs of zeros, not just GZIP and LZ4.
10ms boot time savings isn't anything to get excited about, but users of
arm64+compression+bfd-2.27 should not have to pay a penalty for no
runtime improvement.
Reported-by: Gopinath Elanchezhian <gelanchezhian(a)google.com>
Reported-by: Sindhuri Pentyala <spentyala(a)google.com>
Reported-by: Wei Wang <wvw(a)google.com>
Suggested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Suggested-by: Rahul Chaudhry <rahulchaudhry(a)google.com>
Suggested-by: Siqi Lin <siqilin(a)google.com>
Suggested-by: Stephen Hines <srhines(a)google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[will: added comment to Makefile]
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/Makefile | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -14,8 +14,12 @@ LDFLAGS_vmlinux :=-p --no-undefined -X
CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
GZFLAGS :=-9
-ifneq ($(CONFIG_RELOCATABLE),)
-LDFLAGS_vmlinux += -pie -shared -Bsymbolic
+ifeq ($(CONFIG_RELOCATABLE), y)
+# Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour
+# for relative relocs, since this leads to better Image compression
+# with the relocation offsets always being zero.
+LDFLAGS_vmlinux += -pie -shared -Bsymbolic \
+ $(call ld-option, --no-apply-dynamic-relocs)
endif
ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
Patches currently in stable-queue which might be from ndesaulniers(a)google.com are
queue-4.14/arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch
This is a note to let you know that I've just added the patch titled
ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply
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:
arm64-dts-meson-gxbb-odroidc2-fix-usb1-power-supply.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Neil Armstrong <narmstrong(a)baylibre.com>
Date: Thu, 19 Oct 2017 12:31:09 +0200
Subject: ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply
From: Neil Armstrong <narmstrong(a)baylibre.com>
[ Upstream commit e841ec956e539f4002f5e9fe9f9e904dcca12d5d ]
Looking at the schematics, the USB Power Supply is shared between the
two USB interfaces,
If the usb0 fails to initialize, the second one won't have power.
Fixes: 5a0803bd5ae2 ("ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes")
Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com>
Signed-off-by: Kevin Hilman <khilman(a)baylibre.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -301,6 +301,7 @@
&usb1_phy {
status = "okay";
+ phy-supply = <&usb_otg_pwr>;
};
&usb0 {
Patches currently in stable-queue which might be from narmstrong(a)baylibre.com are
queue-4.14/arm64-dts-meson-gxbb-odroidc2-fix-usb1-power-supply.patch
This is a note to let you know that I've just added the patch titled
arm-ccn: perf: Prevent module unload while PMU is in use
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:
arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.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 foo@baz Mon Dec 18 13:28:59 CET 2017
From: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Date: Fri, 3 Nov 2017 11:45:18 +0000
Subject: arm-ccn: perf: Prevent module unload while PMU is in use
From: Suzuki K Poulose <suzuki.poulose(a)arm.com>
[ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ]
When the PMU driver is built as a module, the perf expects the
pmu->module to be valid, so that the driver is prevented from
being unloaded while it is in use. Fix the CCN pmu driver to
fill in this field.
Fixes: a33b0daab73a0 ("bus: ARM CCN PMU driver")
Cc: Pawel Moll <pawel.moll(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Acked-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bus/arm-ccn.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/bus/arm-ccn.c
+++ b/drivers/bus/arm-ccn.c
@@ -1280,6 +1280,7 @@ static int arm_ccn_pmu_init(struct arm_c
/* Perf driver registration */
ccn->dt.pmu = (struct pmu) {
+ .module = THIS_MODULE,
.attr_groups = arm_ccn_pmu_attr_groups,
.task_ctx_nr = perf_invalid_context,
.event_init = arm_ccn_pmu_event_init,
Patches currently in stable-queue which might be from suzuki.poulose(a)arm.com are
queue-4.14/arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch
This is a note to let you know that I've just added the patch titled
usb: add helper to extract bits 12:11 of wMaxPacketSize
to the 4.9-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:
usb-add-helper-to-extract-bits-12-11-of-wmaxpacketsize.patch
and it can be found in the queue-4.9 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 541b6fe63023f3059cf85d47ff2767a3e42a8e44 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Date: Mon, 26 Sep 2016 10:51:18 +0300
Subject: usb: add helper to extract bits 12:11 of wMaxPacketSize
From: Felipe Balbi <felipe.balbi(a)linux.intel.com>
commit 541b6fe63023f3059cf85d47ff2767a3e42a8e44 upstream.
According to USB Specification 2.0 table 9-4,
wMaxPacketSize is a bitfield. Endpoint's maxpacket
is laid out in bits 10:0. For high-speed,
high-bandwidth isochronous endpoints, bits 12:11
contain a multiplier to tell us how many
transactions we want to try per uframe.
This means that if we want an isochronous endpoint
to issue 3 transfers of 1024 bytes per uframe,
wMaxPacketSize should contain the value:
1024 | (2 << 11)
or 5120 (0x1400). In order to make Host and
Peripheral controller drivers' life easier, we're
adding a helper which returns bits 12:11. Note that
no care is made WRT to checking endpoint type and
gadget's speed. That's left for drivers to handle.
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/usb/ch9.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -423,6 +423,11 @@ struct usb_endpoint_descriptor {
#define USB_ENDPOINT_XFER_INT 3
#define USB_ENDPOINT_MAX_ADJUSTABLE 0x80
+#define USB_EP_MAXP_MULT_SHIFT 11
+#define USB_EP_MAXP_MULT_MASK (3 << USB_EP_MAXP_MULT_SHIFT)
+#define USB_EP_MAXP_MULT(m) \
+ (((m) & USB_EP_MAXP_MULT_MASK) >> USB_EP_MAXP_MULT_SHIFT)
+
/* The USB 3.0 spec redefines bits 5:4 of bmAttributes as interrupt ep type. */
#define USB_ENDPOINT_INTRTYPE 0x30
#define USB_ENDPOINT_INTR_PERIODIC (0 << 4)
@@ -630,6 +635,20 @@ static inline int usb_endpoint_maxp(cons
return __le16_to_cpu(epd->wMaxPacketSize);
}
+/**
+ * usb_endpoint_maxp_mult - get endpoint's transactional opportunities
+ * @epd: endpoint to be checked
+ *
+ * Return @epd's wMaxPacketSize[12:11] + 1
+ */
+static inline int
+usb_endpoint_maxp_mult(const struct usb_endpoint_descriptor *epd)
+{
+ int maxp = __le16_to_cpu(epd->wMaxPacketSize);
+
+ return USB_EP_MAXP_MULT(maxp) + 1;
+}
+
static inline int usb_endpoint_interrupt_type(
const struct usb_endpoint_descriptor *epd)
{
Patches currently in stable-queue which might be from felipe.balbi(a)linux.intel.com are
queue-4.9/usb-add-helper-to-extract-bits-12-11-of-wmaxpacketsize.patch
On Wed, Nov 22, 2017 at 8:27 PM, Amir Goldstein <amir73il(a)gmail.com> wrote:
> Conform two stray warning messages to the standard overlayfs: prefix.
>
> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
> ---
Greg,
Upstream commit ("da2e6b7eeda8 ovl: fix overlay: warning prefix")
was not marked for stable, because it is not a bug fix per-se.
Nevertheless, it may be useful to apply it to stable kernels to keep
overlayfs bug reports/analysis consistent.
The first hunk fixes (#v4.10):
a6c606551141 ovl: redirect on rename-dir
The second hunk fixes (#v4.14):
b5efccbe0a12 ovl: constant d_ino across copy up
For your consideration.
If you wish, I can send a patch for v4.10 with just the first hunk.
Thanks,
Amir.
Hi,
Can following commit be included in stable kernel releases starting from
v4.11?
d9018976cdb6eefc62a7ba79a405f6c9661b08a7 ("mfd: lpc_ich: Do not touch SPI-NOR write protection bit on Haswell/Broadwell")
This makes sure older kernels will not accidentally lose the BIOS
settings.
Thanks!