[PATCH 4.18 149/235] audit: fix use-after-free in audit_add_watch
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Ronny Chevalier
[ Upstream commit baa2a4fdd525c8c4b0f704d20457195b29437839 ]
audit_add_watch stores locally krule->watch without taking a reference
on watch. Then, it calls audit_add_to_parent, and uses the watch stored
locally.
Unfortunately, it is possible that audit_add_to_parent updates
krule->watch.
When it happens, it also drops a reference of watch which
could free the watch.
How to reproduce (with KASAN enabled):
auditctl -w /etc/passwd -F success=0 -k test_passwd
auditctl -w /etc/passwd -F success=1 -k test_passwd2
The second call to auditctl triggers the use-after-free, because
audit_to_parent updates krule->watch to use a previous existing watch
and drops the reference to the newly created watch.
To fix the issue, we grab a reference of watch and we release it at the
end of the function.
Signed-off-by: Ronny Chevalier
Reviewed-by: Richard Guy Briggs
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
kernel/audit_watch.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -419,6 +419,13 @@ int audit_add_watch(struct audit_krule *
struct path parent_path;
int h, ret = 0;
+ /*
+* When we will be calling audit_add_to_parent, krule->watch might have
+* been updated and watch might have been freed.
+* So we need to keep a reference of watch.
+*/
+ audit_get_watch(watch);
+
mutex_unlock(_filter_mutex);
/* Avoid calling path_lookup under audit_filter_mutex. */
@@ -427,8 +434,10 @@ int audit_add_watch(struct audit_krule *
/* caller expects mutex locked */
mutex_lock(_filter_mutex);
- if (ret)
+ if (ret) {
+ audit_put_watch(watch);
return ret;
+ }
/* either find an old parent or attach a new one */
parent = audit_find_parent(d_backing_inode(parent_path.dentry));
@@ -446,6 +455,7 @@ int audit_add_watch(struct audit_krule *
*list = _inode_hash[h];
error:
path_put(_path);
+ audit_put_watch(watch);
return ret;
}
[PATCH 4.18 148/235] arm64: dts: uniphier: Add missing cooling device properties for CPUs
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Viresh Kumar
[ Upstream commit af0e09d0c6762e486b0eb5cc4737396964c34fad ]
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi |2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -58,6 +58,7 @@
clocks = <_clk 32>;
enable-method = "psci";
operating-points-v2 = <_opp>;
+ #cooling-cells = <2>;
};
cpu2: cpu@100 {
@@ -77,6 +78,7 @@
clocks = <_clk 33>;
enable-method = "psci";
operating-points-v2 = <_opp>;
+ #cooling-cells = <2>;
};
};
[PATCH 4.18 152/235] bpf: fix rcu annotations in compute_effective_progs()
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Roman Gushchin
[ Upstream commit 3960f4fd6585608e8cc285d9665821985494e147 ]
The progs local variable in compute_effective_progs() is marked
as __rcu, which is not correct. This is a local pointer, which
is initialized by bpf_prog_array_alloc(), which also now
returns a generic non-rcu pointer.
The real rcu-protected pointer is *array (array is a pointer
to an RCU-protected pointer), so the assignment should be performed
using rcu_assign_pointer().
Fixes: 324bda9e6c5a ("bpf: multi program support for cgroup+bpf")
Signed-off-by: Roman Gushchin
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Signed-off-by: Daniel Borkmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
kernel/bpf/cgroup.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -95,7 +95,7 @@ static int compute_effective_progs(struc
enum bpf_attach_type type,
struct bpf_prog_array __rcu **array)
{
- struct bpf_prog_array __rcu *progs;
+ struct bpf_prog_array *progs;
struct bpf_prog_list *pl;
struct cgroup *p = cgrp;
int cnt = 0;
@@ -120,13 +120,12 @@ static int compute_effective_progs(struc
>bpf.progs[type], node) {
if (!pl->prog)
continue;
- rcu_dereference_protected(progs, 1)->
- progs[cnt++] = pl->prog;
+ progs->progs[cnt++] = pl->prog;
}
p = cgroup_parent(p);
} while (p);
- *array = progs;
+ rcu_assign_pointer(*array, progs);
return 0;
}
[PATCH 4.18 154/235] Bluetooth: Use lock_sock_nested in bt_accept_enqueue
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Philipp Puschmann
[ Upstream commit b71c69c26b4916d11b8d403d8e667bbd191f1b8f ]
Fixes this warning that was provoked by a pairing:
[60258.016221] WARNING: possible recursive locking detected
[60258.021558] 4.15.0-RD1812-BSP #1 Tainted: G O
[60258.027146]
[60258.032464] kworker/u5:0/70 is trying to acquire lock:
[60258.037609] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<87759073>]
bt_accept_enqueue+0x3c/0x74
[60258.046863]
[60258.046863] but task is already holding lock:
[60258.052704] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: []
l2cap_sock_new_connection_cb+0x1c/0x88
[60258.062905]
[60258.062905] other info that might help us debug this:
[60258.069441] Possible unsafe locking scenario:
[60258.069441]
[60258.075368]CPU0
[60258.077821]
[60258.080272] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.085510] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.090748]
[60258.090748] *** DEADLOCK ***
[60258.090748]
[60258.096676] May be due to missing lock nesting notation
[60258.096676]
[60258.103472] 5 locks held by kworker/u5:0/70:
[60258.107747] #0: ((wq_completion)%shdev->name#2){+.+.}, at: [<9460d092>]
process_one_work+0x130/0x4fc
[60258.117263] #1: ((work_completion)(>rx_work)){+.+.}, at:
[<9460d092>] process_one_work+0x130/0x4fc
[60258.126942] #2: (>chan_lock){+.+.}, at: [<7877c8c3>]
l2cap_connect+0x80/0x4f8
[60258.134806] #3: (>lock/2){+.+.}, at: [<2e16c724>]
l2cap_connect+0x8c/0x4f8
[60258.142410] #4: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at:
[] l2cap_sock_new_connection_cb+0x1c/0x88
[60258.153043]
[60258.153043] stack backtrace:
[60258.157413] CPU: 1 PID: 70 Comm: kworker/u5:0 Tainted: G O
4.15.0-RD1812-BSP #1
[60258.165945] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[60258.172485] Workqueue: hci0 hci_rx_work
[60258.176331] Backtrace:
[60258.178797] [<8010c9fc>] (dump_backtrace) from [<8010ccbc>]
(show_stack+0x18/0x1c)
[60258.186379] r7:80e55fe4 r6:80e55fe4 r5:20050093 r4:
[60258.192058] [<8010cca4>] (show_stack) from [<809864e8>]
(dump_stack+0xb0/0xdc)
[60258.199301] [<80986438>] (dump_stack) from [<8016ecc8>]
(__lock_acquire+0xffc/0x11d4)
[60258.207144] r9:5e2bb019 r8:630f974c r7:ba8a5940 r6:ba8a5ed8 r5:815b5220
r4:80fa081c
[60258.214901] [<8016dccc>] (__lock_acquire) from [<8016f620>]
(lock_acquire+0x78/0x98)
[60258.222655] r10:0040 r9:0040 r8:808729f0 r7:0001 r6:
r5:60050013
[60258.230491] r4:
[60258.233045] [<8016f5a8>] (lock_acquire) from [<806ee974>]
(lock_sock_nested+0x64/0x88)
[60258.240970] r7: r6:b796e870 r5:0001 r4:b796e800
[60258.246643] [<806ee910>] (lock_sock_nested) from [<808729f0>]
(bt_accept_enqueue+0x3c/0x74)
[60258.255004] r8:0001 r7:ba7d3c00 r6:ba7d3ea4 r5:ba7d2000 r4:b796e800
[60258.261717] [<808729b4>] (bt_accept_enqueue) from [<808aa39c>]
(l2cap_sock_new_connection_cb+0x68/0x88)
[60258.271117] r5:b796e800 r4:ba7d2000
[60258.274708] [<808aa334>] (l2cap_sock_new_connection_cb) from [<808a294c>]
(l2cap_connect+0x190/0x4f8)
[60258.283933] r5:0001 r4:ba6dce00
[60258.287524] [<808a27bc>] (l2cap_connect) from [<808a4a14>]
(l2cap_recv_frame+0x744/0x2cf8)
[60258.295800] r10:ba6dcf24 r9:0004 r8:b78d8014 r7:0004 r6:bb05d000
r5:0004
[60258.303635] r4:bb05d008
[60258.306183] [<808a42d0>] (l2cap_recv_frame) from [<808a7808>]
(l2cap_recv_acldata+0x210/0x214)
[60258.314805] r10:b78e7800 r9:bb05d960 r8:0001 r7:bb05d000 r6:000c
r5:b7957a80
[60258.322641] r4:ba6dce00
[60258.325188] [<808a75f8>] (l2cap_recv_acldata) from [<8087630c>]
(hci_rx_work+0x35c/0x4e8)
[60258.74] r6:80e5743c r5:bb05d7c8 r4:b7957a80
[60258.338004] [<80875fb0>] (hci_rx_work) from [<8013dc7c>]
(process_one_work+0x1a4/0x4fc)
[60258.346018] r10:0001 r9: r8:baabfef8 r7:ba997500 r6:baaba800
r5:baaa5d00
[60258.353853] r4:bb05d7c8
[60258.356401] [<8013dad8>] (process_one_work) from [<8013e028>]
(worker_thread+0x54/0x5cc)
[60258.364503] r10:baabe038 r9:baaba834 r8:80e05900 r7:0088 r6:baaa5d18
r5:baaba800
[60258.372338] r4:baaa5d00
[60258.374888] [<8013dfd4>] (worker_thread) from [<801448f8>]
(kthread+0x134/0x160)
[60258.382295] r10:ba8310b8 r9:bb07dbfc r8:8013dfd4 r7:baaa5d00 r6:
r5:baaa8ac0
[60258.390130] r4:ba831080
[60258.392682] [<801447c4>] (kthread) from [<801080b4>]
(ret_from_fork+0x14/0x20)
[60258.399915] r10: r9: r8: r7: r6:
r5:801447c4
[60258.407751] r4:baaa8ac0 r3:baabe000
Signed-off-by: Philipp Puschmann
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/bluetooth/af_bluetooth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -159,7 +159,7 @@ void
[PATCH 4.18 151/235] vfs: fix freeze protection in mnt_want_write_file() for overlayfs
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Miklos Szeredi
[ Upstream commit a6795a585929d94ca3e931bc8518f8deb8bbe627 ]
The underlying real file used by overlayfs still contains the overlay path.
This results in mnt_want_write_file() calls by the filesystem getting
freeze protection on the wrong inode (the overlayfs one instead of the real
one).
Fix by using file_inode(file)->i_sb instead of file->f_path.mnt->mnt_sb.
Reported-by: Amir Goldstein
Signed-off-by: Miklos Szeredi
Reviewed-by: Christoph Hellwig
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/namespace.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -446,10 +446,10 @@ int mnt_want_write_file_path(struct file
{
int ret;
- sb_start_write(file->f_path.mnt->mnt_sb);
+ sb_start_write(file_inode(file)->i_sb);
ret = __mnt_want_write_file(file);
if (ret)
- sb_end_write(file->f_path.mnt->mnt_sb);
+ sb_end_write(file_inode(file)->i_sb);
return ret;
}
@@ -540,7 +540,8 @@ void __mnt_drop_write_file(struct file *
void mnt_drop_write_file_path(struct file *file)
{
- mnt_drop_write(file->f_path.mnt);
+ __mnt_drop_write_file(file);
+ sb_end_write(file_inode(file)->i_sb);
}
void mnt_drop_write_file(struct file *file)
[PATCH 4.18 153/235] spi: dw: fix possible race condition
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Alexandre Belloni
[ Upstream commit 66b19d762378785d1568b5650935205edfeb0503 ]
It is possible to get an interrupt as soon as it is requested. dw_spi_irq
does spi_controller_get_devdata(master) and expects it to be different than
NULL. However, spi_controller_set_devdata() is called after request_irq(),
resulting in the following crash:
CPU 0 Unable to handle kernel paging request at virtual address 0030, epc
== 8058e09c, ra == 8018ff90
[...]
Call Trace:
[<8058e09c>] dw_spi_irq+0x8/0x64
[<8018ff90>] __handle_irq_event_percpu+0x70/0x1d4
[<80190128>] handle_irq_event_percpu+0x34/0x8c
[<801901c4>] handle_irq_event+0x44/0x80
[<801951a8>] handle_level_irq+0xdc/0x194
[<8018f580>] generic_handle_irq+0x38/0x50
[<804c6924>] ocelot_irq_handler+0x104/0x1c0
Signed-off-by: Alexandre Belloni
Reviewed-by: Andy Shevchenko
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/spi/spi-dw.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -485,6 +485,8 @@ int dw_spi_add_host(struct device *dev,
dws->dma_inited = 0;
dws->dma_addr = (dma_addr_t)(dws->paddr + DW_SPI_DR);
+ spi_controller_set_devdata(master, dws);
+
ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED, dev_name(dev),
master);
if (ret < 0) {
@@ -518,7 +520,6 @@ int dw_spi_add_host(struct device *dev,
}
}
- spi_controller_set_devdata(master, dws);
ret = devm_spi_register_controller(dev, master);
if (ret) {
dev_err(>dev, "problem registering spi master\n");
[PATCH 4.18 146/235] binfmt_elf: Respect error return from `regset->active
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: "Maciej W. Rozycki"
[ Upstream commit 2f819db565e82e5f73cd42b39925098986693378 ]
The regset API documented in defines -ENODEV as the
result of the `->active' handler to be used where the feature requested
is not available on the hardware found. However code handling core file
note generation in `fill_thread_core_info' interpretes any non-zero
result from the `->active' handler as the regset requested being active.
Consequently processing continues (and hopefully gracefully fails later
on) rather than being abandoned right away for the regset requested.
Fix the problem then by making the code proceed only if a positive
result is returned from the `->active' handler.
Signed-off-by: Maciej W. Rozycki
Signed-off-by: Paul Burton
Fixes: 4206d3aa1978 ("elf core dump: notes user_regset")
Patchwork: https://patchwork.linux-mips.org/patch/19332/
Cc: Alexander Viro
Cc: James Hogan
Cc: Ralf Baechle
Cc: linux-fsde...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/binfmt_elf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1751,7 +1751,7 @@ static int fill_thread_core_info(struct
const struct user_regset *regset = >regsets[i];
do_thread_regset_writeback(t->task, regset);
if (regset->core_note_type && regset->get &&
- (!regset->active || regset->active(t->task, regset))) {
+ (!regset->active || regset->active(t->task, regset) > 0)) {
int ret;
size_t size = regset_size(t->task, regset);
void *data = kmalloc(size, GFP_KERNEL);
[PATCH 4.18 145/235] mmc: meson-mx-sdio: fix OF child-node lookup
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit c483a5cc9d09f4ceaa9abb106f863cc89cb643d9 upstream.
Use the new of_get_compatible_child() helper to lookup the slot child
node instead of using of_find_compatible_node(), which searches the
entire tree from a given start node and thus can return an unrelated
(i.e. non-child) node.
This also addresses a potential use-after-free (e.g. after probe
deferral) as the tree-wide helper drops a reference to its first
argument (i.e. the node of the device being probed).
While at it, also fix up the related slot-node reference leak.
Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8
and Meson8b SoCs")
Cc: stable # 4.15
Cc: Carlo Caione
Cc: Martin Blumenstingl
Cc: Ulf Hansson
Acked-by: Martin Blumenstingl
Signed-off-by: Johan Hovold
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/meson-mx-sdio.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/meson-mx-sdio.c
+++ b/drivers/mmc/host/meson-mx-sdio.c
@@ -517,19 +517,23 @@ static struct mmc_host_ops meson_mx_mmc_
static struct platform_device *meson_mx_mmc_slot_pdev(struct device *parent)
{
struct device_node *slot_node;
+ struct platform_device *pdev;
/*
* TODO: the MMC core framework currently does not support
* controllers with multiple slots properly. So we only register
* the first slot for now
*/
- slot_node = of_find_compatible_node(parent->of_node, NULL, "mmc-slot");
+ slot_node = of_get_compatible_child(parent->of_node, "mmc-slot");
if (!slot_node) {
dev_warn(parent, "no 'mmc-slot' sub-node found\n");
return ERR_PTR(-ENOENT);
}
- return of_platform_device_create(slot_node, NULL, parent);
+ pdev = of_platform_device_create(slot_node, NULL, parent);
+ of_node_put(slot_node);
+
+ return pdev;
}
static int meson_mx_mmc_add_host(struct meson_mx_mmc_host *host)
Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection
On Mon, 24 Sep 2018, Jiri Kosina wrote: > On Sat, 22 Sep 2018, Thomas Gleixner wrote: > > > Lunch and coffee indeed made brain work better. The simple solution was way > > too obvious. > > Ah, cool, I like it a lot. > > Do you want me to fold this into v7, or are you on it already? Please do so. I'm traveling/conferencing and only spotty online. Thanks, tglx
Re: [PATCH net-next] tcp: expose sk_state in tcp_retransmit_skb tracepoint
On Mon, Sep 24, 2018 at 5:42 AM, Eric Dumazet wrote: > > > On 09/23/2018 12:49 PM, Yafang Shao wrote: >> With sk_state, we can know whether this connection is in SYN_SENT state >> or ESTBLISHED state. >> The reason to distinguish between these two scenario is that the >> retransmission in ESTABLISHED state always mean network congestion while >> in SYN_SENT state it always mean server issue, i.e. the syn packet is >> dropped due to syn backlog queue full. > > You mean, a packet drop on the remote peer ? > Yes, I mean drop on the remote peer. > It could also be a packet drop in the network. > Yes of course. > Your patch is good, but changelog is quite misleading. Will modify the changelog. Thanks Yafang
[PATCH 4.18 142/235] NFSv4: Fix a tracepoint Oops in initiate_file_draining()
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit 2a534a7473bf4e7f1c12805113f80c795fc8e89a upstream.
Now that the value of 'ino' can be NULL or an ERR_PTR(), we need to
change the test in the tracepoint.
Fixes: ce5624f7e6675 ("NFSv4: Return NFS4ERR_DELAY when a layout fails...")
Signed-off-by: Trond Myklebust
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Anna Schumaker
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/nfs4trace.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/nfs4trace.h
+++ b/fs/nfs/nfs4trace.h
@@ -1194,7 +1194,7 @@ DECLARE_EVENT_CLASS(nfs4_inode_stateid_c
TP_fast_assign(
__entry->error = error;
__entry->fhandle = nfs_fhandle_hash(fhandle);
- if (inode != NULL) {
+ if (!IS_ERR_OR_NULL(inode)) {
__entry->fileid = NFS_FILEID(inode);
__entry->dev = inode->i_sb->s_dev;
} else {
[PATCH 4.18 158/235] PM / devfreq: use put_device() instead of kfree()
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Arvind Yadav
[ Upstream commit 2d803dc8f7a5f622ac47c3b650834ada3a2659b9 ]
Never directly free @dev after calling device_register() or
device_unregister(), even if device_register() returned an error.
Always use put_device() to give up the reference initialized.
Signed-off-by: Arvind Yadav
Reviewed-by: Chanwoo Choi
Signed-off-by: MyungJoo Ham
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/devfreq/devfreq.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struc
err = device_register(>dev);
if (err) {
mutex_unlock(>lock);
- goto err_dev;
+ put_device(>dev);
+ goto err_out;
}
devfreq->trans_table =
@@ -672,6 +673,7 @@ err_init:
mutex_unlock(_list_lock);
device_unregister(>dev);
+ devfreq = NULL;
err_dev:
if (devfreq)
kfree(devfreq);
[PATCH 4.9 074/111] audit: fix use-after-free in audit_add_watch
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ronny Chevalier
[ Upstream commit baa2a4fdd525c8c4b0f704d20457195b29437839 ]
audit_add_watch stores locally krule->watch without taking a reference
on watch. Then, it calls audit_add_to_parent, and uses the watch stored
locally.
Unfortunately, it is possible that audit_add_to_parent updates
krule->watch.
When it happens, it also drops a reference of watch which
could free the watch.
How to reproduce (with KASAN enabled):
auditctl -w /etc/passwd -F success=0 -k test_passwd
auditctl -w /etc/passwd -F success=1 -k test_passwd2
The second call to auditctl triggers the use-after-free, because
audit_to_parent updates krule->watch to use a previous existing watch
and drops the reference to the newly created watch.
To fix the issue, we grab a reference of watch and we release it at the
end of the function.
Signed-off-by: Ronny Chevalier
Reviewed-by: Richard Guy Briggs
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
kernel/audit_watch.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -419,6 +419,13 @@ int audit_add_watch(struct audit_krule *
struct path parent_path;
int h, ret = 0;
+ /*
+* When we will be calling audit_add_to_parent, krule->watch might have
+* been updated and watch might have been freed.
+* So we need to keep a reference of watch.
+*/
+ audit_get_watch(watch);
+
mutex_unlock(_filter_mutex);
/* Avoid calling path_lookup under audit_filter_mutex. */
@@ -427,8 +434,10 @@ int audit_add_watch(struct audit_krule *
/* caller expects mutex locked */
mutex_lock(_filter_mutex);
- if (ret)
+ if (ret) {
+ audit_put_watch(watch);
return ret;
+ }
/* either find an old parent or attach a new one */
parent = audit_find_parent(d_backing_inode(parent_path.dentry));
@@ -446,6 +455,7 @@ int audit_add_watch(struct audit_krule *
*list = _inode_hash[h];
error:
path_put(_path);
+ audit_put_watch(watch);
return ret;
}
[PATCH 4.14 117/173] MIPS: loongson64: cs5536: Fix PCI_OHCI_INT_REG reads
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Paul Burton [ Upstream commit cd87668d601f622e0ebcfea4f78d116d5f572f4d ] The PCI_OHCI_INT_REG case in pci_ohci_read_reg() contains the following if statement: if ((lo & 0x0f00) == CS5536_USB_INTR) CS5536_USB_INTR expands to the constant 11, which gives us the following condition which can never evaluate true: if ((lo & 0xf00) == 11) At least when using GCC 8.1.0 this falls foul of the tautoligcal-compare warning, and since the code is built with the -Werror flag the build fails. Fix this by shifting lo right by 8 bits in order to match the corresponding PCI_OHCI_INT_REG case in pci_ohci_write_reg(). Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/19861/ Cc: Huacai Chen Cc: James Hogan Cc: Ralf Baechle Cc: linux-m...@linux-mips.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/mips/loongson64/common/cs5536/cs5536_ohci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/loongson64/common/cs5536/cs5536_ohci.c +++ b/arch/mips/loongson64/common/cs5536/cs5536_ohci.c @@ -138,7 +138,7 @@ u32 pci_ohci_read_reg(int reg) break; case PCI_OHCI_INT_REG: _rdmsr(DIVIL_MSR_REG(PIC_YSEL_LOW), , ); - if ((lo & 0x0f00) == CS5536_USB_INTR) + if (((lo >> PIC_YSEL_LOW_USB_SHIFT) & 0xf) == CS5536_USB_INTR) conf_data = 1; break; default:
Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags
On Mon, Sep 24, 2018 at 01:37:45PM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > I have thought a little more about splitting up the mount flags into
> > sensible sets. I think the following four sets make sense:
> >
> > enum {
> > MOUNT_ATTR_PROPAGATION = 1,
> > MOUNT_ATTR_SECURITY,
> > MOUNT_ATTR_SYNC,
> > MOUNT_ATTR_TIME,
> > };
>
> Al (I think it was) has been against splitting them up before (I've previously
> proposed splitting the topology propagation flags from the mount attributes).
Right, that request could probably be fulfilled by the first draft for
this idea that I had but didn't send out.
Basically, having a sequential enum that only ever gets bumped when we
run out of flags in a set, i.e.
enum {
MOUNT_ATTR_SET_1 = 1,
MOUNT_ATTR_SET_2 = 2,
MOUNT_ATTR_SET_3 = 3,
.
.
.
};
Then we would currently only define a single set
enum {
MOUNT_ATTR_SET_1 = 1,
};
dump all the current mount flags we would like to support in there and
call it a day until we run out of flags at which point we introduce
MOUNT_ATTR_SET_2.
But honestly, I find defining cuts by forming sets of logically related
flags to be more intuitive and transparent for kernel- and userspace.
But I'm just another muppet with an opinion. :)
>
> > #define MOUNT_ATTR_NOATIME (1<<1)
> > #define MOUNT_ATTR_RELATIME(1<<3)
> > #define MOUNT_ATTR_STRICTATIME (1<<4)
>
> These aren't independent, but are actually settings on the same dial, so I
> would suggest that they shouldn't be separate flags. I'm not sure about
> LAZYTIME though.
So what you or Miklos suggested before, namely making them an enum too?
>
> > enum {
> > MOUNT_ATTR_PROPAGATION = 1,
> > MOUNT_ATTR_SECURITY,
> > MOUNT_ATTR_SECURITY_1 = MOUNT_ATTR_SECURITY,
> > MOUNT_ATTR_SYNC,
> > MOUNT_ATTR_TIME,
> > MOUNT_ATTR_SECURITY_2,
> > };
>
> In UAPI headers, always explicitly number your symbols, even in an enum, just
> to make sure that the numbers don't get transparently changed by accident.
+1 and thanks for the tip!
>
> > These flags will likely become AT_* flags or be tied to a syscall
> > afaict.
> >
> > #define MS_REMOUNT 32
> > #define MS_BIND 4096
> > #define MS_MOVE 8192
> > #define MS_REC 16384
>
> MS_REMOUNT: fd = fspick(); fscommand(fd, FSCONFIG_CMD_RECONFIGURE);
>
> MS_REMOUNT|MS_BIND: mount_setattr().
>
> MS_BIND: fd = open_tree(..., OPEN_TREE_CLONE); move_mount(fd, "", ...);
>
> MS_MOVE: fd = open_tree(..., 0); move_mount(fd, "", ...);
>
> MS_REC: AT_RECURSIVE
>
> > Internal sb flags will not be part of the new mount attr sets. (They
> > should - imho - not be exposed to userspace at all.):
>
> Agreed.
>
> > What remains is an odd duck that probably could be thrown into security
> > but also *shrug*
> >
> > #define MS_I_VERSION(1<<23)
>
> Um. I think it would probably belong with atime settings.
>
> David
signature.asc
Description: PGP signature
RE: [PATCH v7 2/7] edac: synps: Add platform specific structures for ddrc controller
Hi Boris, Thanks for the review. > -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Friday, September 21, 2018 2:46 PM > To: Manish Narani > Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org; > Michal Simek ; leoyang...@nxp.com; > sudeep.ho...@arm.com; amit.kuche...@linaro.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v7 2/7] edac: synps: Add platform specific structures for > ddrc controller > > There's more: > > I said: > > > > @@ -370,12 +398,12 @@ static int synps_edac_init_csrows(struct > > > mem_ctl_info *mci) > > > That function returns 0 unconditionally. Make it a void in a prepatch. > > But you've lumped this change together with a bunch more. Maybe my request > wasn't clear so let me rephrase it: > > That function returns 0 unconditionally. Make it a void in a *separate* > prepatch. > > Ok? Yes, okay. I will keep it in a separate prepatch in v8. Thanks, Manish
[PATCH 14/14] dt-bindings: serial: lantiq: Add optional properties for CCF
Clocks and clock-names are updated in device tree binding.
Reviewed-by: Rob Herring
Signed-off-by: Songjun Wu
---
Documentation/devicetree/bindings/serial/lantiq_asc.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
index 3acbd309ab9d..40e81a5818f6 100644
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
@@ -6,8 +6,23 @@ Required properties:
- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
depends on the interrupt-parent interrupt controller.
+Optional properties:
+- clocks: Should contain frequency clock and gate clock
+- clock-names: Should be "freq" and "asc"
+
Example:
+asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+};
+
asc1: serial@e100c00 {
compatible = "lantiq,asc";
reg = <0xE100C00 0x400>;
--
2.11.0
[PATCH 13/14] serial: lantiq: Change init_lqasc to static declaration
init_lqasc() is only used internally, change to static declaration.
Signed-off-by: Songjun Wu
---
drivers/tty/serial/lantiq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index ba0c70b16bda..e052b69ceb98 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -784,7 +784,7 @@ static struct platform_driver lqasc_driver = {
},
};
-int __init
+static int __init
init_lqasc(void)
{
int ret;
--
2.11.0
[PATCH 03/14] serial: lantiq: Get serial id from dts
Get serial id from dts, also keep backward compatible when dts is not
updated.
Signed-off-by: Songjun Wu
---
drivers/tty/serial/lantiq.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 044128277248..66c671677761 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -688,7 +688,7 @@ lqasc_probe(struct platform_device *pdev)
struct ltq_uart_port *ltq_port;
struct uart_port *port;
struct resource *mmres, irqres[3];
- int line = 0;
+ int line;
int ret;
mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -699,9 +699,20 @@ lqasc_probe(struct platform_device *pdev)
return -ENODEV;
}
- /* check if this is the console port */
- if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
- line = 1;
+ /* get serial id */
+ line = of_alias_get_id(node, "serial");
+ if (line < 0) {
+ if (IS_ENABLED(CONFIG_LANTIQ)) {
+ if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+ line = 0;
+ else
+ line = 1;
+ } else {
+ dev_err(>dev, "failed to get alias id, errno
%d\n",
+ line);
+ return line;
+ }
+ }
if (lqasc_port[line]) {
dev_err(>dev, "port %d already allocated\n", line);
--
2.11.0
[PATCH v4] block/loop: Serialize ioctl operations.
On 2018/09/24 7:03, Ming Lei wrote:
> On Sat, Sep 22, 2018 at 09:39:02PM +0900, Tetsuo Handa wrote:
>> Hello, Ming Lei.
>>
>> I'd like to hear your comment on this patch regarding the ordering of
>> stopping kernel thread.
>>
>> > In order to enforce this strategy, this patch inversed
>> > loop_reread_partitions() and loop_unprepare_queue() in loop_clr_fd().
>> > I don't know whether it breaks something, but I don't have testcases.
>>
>> Until 3.19, kthread_stop(lo->lo_thread) was called before
>> ioctl_by_bdev(bdev, BLKRRPART, 0) is called.
>> During 4.0 to 4.3, the loop module was using "kloopd" workqueue.
>> But since 4.4, loop_reread_partitions(lo, bdev) is called before
>> loop_unprepare_queue(lo) is called. And this patch is trying to change to
>> call loop_unprepare_queue() before loop_reread_partitions() is called.
>> Is there some reason we need to preserve current ordering?
>
> IMO, both the two orders are fine, and what matters is that 'lo->lo_state'
> is updated before loop_reread_partitions(), then any IO from
> loop_reread_partitions
> will be failed, so it shouldn't be a big deal wrt. the order between
> loop_reread_partitions() and loop_unprepare_queue().
OK. Thank you. Here is v4 patch (only changelog was updated).
Andrew, can we test this patch in the -mm tree?
>From 2278250ac8c5b912f7eb7af55e36ed40e2f7116b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 24 Sep 2018 18:58:37 +0900
Subject: [PATCH v4] block/loop: Serialize ioctl operations.
syzbot is reporting NULL pointer dereference [1] which is caused by
race condition between ioctl(loop_fd, LOOP_CLR_FD, 0) versus
ioctl(other_loop_fd, LOOP_SET_FD, loop_fd) due to traversing other
loop devices without holding corresponding locks.
syzbot is also reporting circular locking dependency between bdev->bd_mutex
and lo->lo_ctl_mutex [2] which is caused by calling blkdev_reread_part()
with lock held.
Since ioctl() request on loop devices is not frequent operation, we don't
need fine grained locking. Let's use global lock and simplify the locking
order.
Strategy is that the global lock is held upon entry of ioctl() request,
and release it before either starting operations which might deadlock or
leaving ioctl() request. After the global lock is released, current thread
no longer uses "struct loop_device" memory because it might be modified
by next ioctl() request which was waiting for current ioctl() request.
In order to enforce this strategy, this patch inverted
loop_reread_partitions() and loop_unprepare_queue() in loop_clr_fd().
According to Ming Lei, calling loop_unprepare_queue() before
loop_reread_partitions() (like we did until 3.19) is fine.
Since this patch serializes using global lock, race bugs should no longer
exist. Thus, it will be easy to test whether this patch broke something.
Since syzbot is reporting various bugs [3] where a race in the loop module
is suspected, let's check whether this patch affects these bugs too.
[1]
https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3
[2]
https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889
[3]
https://syzkaller.appspot.com/bug?id=b3c7e1440aa8ece16bf557dbac427fdff1dad9d6
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Reported-by: syzbot
Cc: Ming Lei
Cc: Jan Kara
Cc: Jens Axboe
---
drivers/block/loop.c | 231 ---
drivers/block/loop.h | 1 -
2 files changed, 128 insertions(+), 104 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ea9debf..a7058ec 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -83,11 +83,50 @@
#include
static DEFINE_IDR(loop_index_idr);
-static DEFINE_MUTEX(loop_index_mutex);
+static DEFINE_MUTEX(loop_mutex);
+static void *loop_mutex_owner; /* == __mutex_owner(_mutex) */
static int max_part;
static int part_shift;
+/*
+ * lock_loop - Lock loop_mutex.
+ */
+static void lock_loop(void)
+{
+ mutex_lock(_mutex);
+ loop_mutex_owner = current;
+}
+
+/*
+ * lock_loop_killable - Lock loop_mutex unless killed.
+ */
+static int lock_loop_killable(void)
+{
+ int err = mutex_lock_killable(_mutex);
+
+ if (err)
+ return err;
+ loop_mutex_owner = current;
+ return 0;
+}
+
+/*
+ * unlock_loop - Unlock loop_mutex as needed.
+ *
+ * Explicitly call this function before calling fput() or blkdev_reread_part()
+ * in order to avoid circular lock dependency. After this function is called,
+ * current thread is no longer allowed to access "struct loop_device" memory,
+ * for another thread would access that memory as soon as loop_mutex is held.
+ */
+static void unlock_loop(void)
+{
+ if (loop_mutex_owner == current) {
+ loop_mutex_owner = NULL;
+ mutex_unlock(_mutex);
+ }
+}
+
static int transfer_xor(struct loop_device *lo, int cmd,
struct page *raw_page, unsigned raw_off,
RE: [PATCH v7 4/7] edac: synopsys: Add macro defines for ZynqMP DDRC
Hi Boris, Thanks for the review. > -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Monday, September 24, 2018 2:52 PM > To: Manish Narani > Cc: robh...@kernel.org; mark.rutl...@arm.com; mche...@kernel.org; > Michal Simek ; leoyang...@nxp.com; > sudeep.ho...@arm.com; amit.kuche...@linaro.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v7 4/7] edac: synopsys: Add macro defines for ZynqMP > DDRC > > On Mon, Sep 17, 2018 at 07:55:02PM +0530, Manish Narani wrote: > > Add macro defines for ZynqMP DDR controller. These macros will be used > > for ZyqnMP ECC operations. > > > > Signed-off-by: Manish Narani > > --- > > drivers/edac/synopsys_edac.c | 168 > > +++ > > 1 file changed, 168 insertions(+) > > > > diff --git a/drivers/edac/synopsys_edac.c > > b/drivers/edac/synopsys_edac.c index eb458e5..6bf7959 100644 > > --- a/drivers/edac/synopsys_edac.c > > +++ b/drivers/edac/synopsys_edac.c > > @@ -97,6 +97,174 @@ > > #define SCRUB_MODE_MASK0x7 > > #define SCRUB_MODE_SECDED 0x4 > > > > +/* DDR ECC Quirks */ > > +#define DDR_ECC_INTR_SUPPORT BIT(0) > > +#define DDR_ECC_DATA_POISON_SUPPORTBIT(1) > > All those new additions are one column further to the left than the old ones. > Why? > > Is there some significance here or can they all be vertically aligned? Should I increase the alignment of the existing macros in the 'code formatting' patches? New macros will need an increased indentation. Thanks, Manish
Re: [RFC/PATCH 2/5] device property: introduce notion of subnodes for legacy boards
Hi Linus, On Fri, Sep 21, 2018 at 08:36:53AM -0700, Linus Walleij wrote: > On Thu, Sep 20, 2018 at 6:53 AM Heikki Krogerus > wrote: > > > The child nodes will change the purpose of the build-in property > > support. Originally the goal was just to support adding of build-in > > device properties to real firmware nodes, but things have changed > > quite a bit from that. These child nodes are purely tied to the > > build-in device property support, so we should be talking about adding > > pset type child nodes to pset type parent nodes in the API: > > fwnode_pset_add_child_node(), or something like that. > > > > I'm sorry to be a bit of pain in the butt with this. The build-in > > property support is a hack, it always was. A useful hack, but hack > > nevertheless. That means we need to be extra careful when expanding > > it, like here. > > I dunno how we got to here, what I tried to solve and Dmitry tries > to make more general is converting old boardfiles to use fwnode, because > I initially tried to just support gpio descriptors from board files. I understand that, but what I'm trying to say is that the solution for the child nodes is not generic enough. I'll try to explain below. > If boardfiles is what you mean with "build-in property support" I don't > know, it predates both device tree and ACPI and any other hardware > descriptions on the ARM architecture, from the perspective of these > systems things are fine and the hardware description languages > are the novelty... Rafael talked about "build-in properties" at one point, and I just started using that expression after that, but it's probable not the best term to describe this thing. But please note that we are not talking about only static information with these property sets. They can be populated dynamically as well, so this kind of extensions must consider and support that. On top of board files we need to consider things like glue and probing drivers and even buses in some cases. > But I guess you know because you worked with OMAP :) > > So there is something I don't understand here. Sorry for the poor choice of words on my behalf. I guess I'm not explaining my point properly. Let me try again. So I'm seeing a case that this solution does not seem to be able to support, but ultimately it will need to do so: with USB ports we are going to need to be able to assign a device to the child nodes that represent those ports. To be honest, normally I would not care about that, and I would simply wait for this to go into mainline, and then propose a modification to it so it can also support that other case. However, this time I feel that we should not do that. The solution for the child nodes should be implemented so that it can support all the known cases from the beginning. The reason for that is because I fear that we'll end up having a pile of ad-hoc style solutions, each solving an individual problem, and a whole lot of duplicated stuff for these property sets. In the end we will have spaghetti with meatballs that nobody is able fully understand nor handle. And I really see a strong possibility for that to happen here. Thanks, -- heikki
[PATCH 08/14] serial: lantiq: Replace clk_enable/clk_disable with clk generic API
The clk driver has introduced new clock APIs that replace the existing clk_enable and clk_disable. - clk_enable() APIs is replaced with clk_prepare_enable() - clk_disable() API is replaced with clk_disable_unprepare() Signed-off-by: Songjun Wu --- drivers/tty/serial/lantiq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index 4acdbdf8fe7a..34b1ef3c12ce 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -308,7 +308,7 @@ lqasc_startup(struct uart_port *port) int retval; if (!IS_ERR(ltq_port->clk)) - clk_enable(ltq_port->clk); + clk_prepare_enable(ltq_port->clk); port->uartclk = clk_get_rate(ltq_port->freqclk); asc_update_bits(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET), @@ -376,7 +376,7 @@ lqasc_shutdown(struct uart_port *port) asc_update_bits(ASCTXFCON_TXFEN, ASCTXFCON_TXFFLU, port->membase + LTQ_ASC_TXFCON); if (!IS_ERR(ltq_port->clk)) - clk_disable(ltq_port->clk); + clk_disable_unprepare(ltq_port->clk); } static void @@ -630,7 +630,7 @@ lqasc_console_setup(struct console *co, char *options) port = _port->port; if (!IS_ERR(ltq_port->clk)) - clk_enable(ltq_port->clk); + clk_prepare_enable(ltq_port->clk); port->uartclk = clk_get_rate(ltq_port->freqclk); -- 2.11.0
Re: [PATCH v10 10/26] KVM: s390: interfaces to clear CRYCB masks
On Wed, 12 Sep 2018 15:43:00 -0400
Tony Krowiak wrote:
> From: Tony Krowiak
>
> Introduces two new KVM interface to clear the APM, AQM and ADM masks in
> the guest's CRYCB. The VCPUs are taken out of SIE to ensure the VCPUs do
> not get out of sync.
Hm, that patch description does not quite match what the patch actually
does...
>
> Signed-off-by: Tony Krowiak
> Acked-by: Halil Pasic
> Tested-by: Michael Mueller
> Tested-by: Farhan Ali
> Tested-by: Pierre Morel
> Signed-off-by: Christian Borntraeger
> ---
> arch/s390/include/asm/kvm_host.h |2 ++
> arch/s390/kvm/kvm-s390.c | 15 +++
> 2 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/arch/s390/include/asm/kvm_host.h
> b/arch/s390/include/asm/kvm_host.h
> index 423cce7..1e758fe 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -858,6 +858,8 @@ void kvm_arch_async_page_not_present(struct kvm_vcpu
> *vcpu,
> void kvm_arch_async_page_present(struct kvm_vcpu *vcpu,
>struct kvm_async_pf *work);
>
> +void kvm_arch_crypto_clear_masks(struct kvm *kvm);
> +
> extern int sie64a(struct kvm_s390_sie_block *, u64 *);
> extern char sie_exit;
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index d717041..ac4c93f 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2033,6 +2033,21 @@ static void kvm_s390_set_crycb_format(struct kvm *kvm)
> kvm->arch.crypto.crycbd |= CRYCB_FORMAT1;
> }
>
> +void kvm_arch_crypto_clear_masks(struct kvm *kvm)
> +{
> + mutex_lock(>lock);
> + kvm_s390_vcpu_block_all(kvm);
> +
> + memset(>arch.crypto.crycb->apcb0, 0,
> +sizeof(kvm->arch.crypto.crycb->apcb0));
> + memset(>arch.crypto.crycb->apcb1, 0,
> +sizeof(kvm->arch.crypto.crycb->apcb1));
> +
> + kvm_s390_vcpu_unblock_all(kvm);
> + mutex_unlock(>lock);
> +}
> +EXPORT_SYMBOL_GPL(kvm_arch_crypto_clear_masks);
...although this function looks fine.
> +
> static u64 kvm_s390_get_initial_cpuid(void)
> {
> struct cpuid cpuid;
[PATCH 4.4 15/70] perf powerpc: Fix callchain ip filtering when return address is in a register
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Sandipan Das [ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ] For powerpc64, perf will filter out the second entry in the callchain, i.e. the LR value, if the return address of the function corresponding to the probed location has already been saved on its caller's stack. The state of the return address is determined using debug information. At any point within a function, if the return address is already saved somewhere, a DWARF expression can tell us about its location. If the return address in still in LR only, no DWARF expression would exist. Typically, the instructions in a function's prologue first copy the LR value to R0 and then pushes R0 on to the stack. If LR has already been copied to R0 but R0 is yet to be pushed to the stack, we can still get a DWARF expression that says that the return address is in R0. This is indicating that getting a DWARF expression for the return address does not guarantee the fact that it has already been saved on the stack. This can be observed on a powerpc64le system running Fedora 27 as shown below. # objdump -d /usr/lib64/libc-2.26.so | less ... 0015af20 : 15af20: 0b 00 4c 3c addis r2,r12,11 15af24: e0 c1 42 38 addir2,r2,-15904 15af28: a6 02 08 7c mflrr0 15af2c: f0 ff c1 fb std r30,-16(r1) 15af30: f8 ff e1 fb std r31,-8(r1) 15af34: 78 1b 7f 7c mr r31,r3 15af38: 78 23 83 7c mr r3,r4 15af3c: 78 2b be 7c mr r30,r5 15af40: 10 00 01 f8 std r0,16(r1) 15af44: c1 ff 21 f8 stdur1,-64(r1) 15af48: 28 00 81 f8 std r4,40(r1) ... # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less ... 00027024 0024 00027028 FDE cie= pc=0015af20..0015af88 LOC CFA r30 r31 ra 0015af20 r1+0 u u u 0015af34 r1+0 c-16 c-8 r0 0015af48 r1+64c-16 c-8 c+16 0015af5c r1+0 c-16 c-8 c+16 0015af78 r1+0 u u ... # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18 # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1 # perf script Before: ping 2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38) 7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so) 7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so) 12f152d70 _init+0xbfc (/usr/bin/ping) 7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so) 7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so) 0 [unknown] ([unknown]) After: ping 2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38) 7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so) 7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so) 7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so) 12f152d70 _init+0xbfc (/usr/bin/ping) 7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so) 7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so) 0 [unknown] ([unknown]) Reported-by: Ravi Bangoria Signed-off-by: Sandipan Das Cc: Jiri Olsa Cc: Maynard Johnson Cc: Naveen N. Rao Cc: Ravi Bangoria Cc: Sukadev Bhattiprolu Link: http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandi...@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- tools/perf/arch/powerpc/util/skip-callchain-idx.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c +++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c @@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno } /* -* Check if return address is on the stack. +* Check if return address is on the stack. If return address +* is in a register (typically R0), it is yet to be saved on +* the stack. */ - if (nops != 0 || ops != NULL) + if ((nops != 0 || ops != NULL) && + !(nops == 1 && ops[0].atom == DW_OP_regx && + ops[0].number2 == 0 && ops[0].offset == 0)) return 0; /*
[PATCH 4.4 14/70] fbdev/via: fix defined but not used warning
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]
Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.
../drivers/video/fbdev/via/viafbdev.c:1471:12: warning:
'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]
Signed-off-by: Randy Dunlap
Cc: Florian Tobias Schandinat
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/via/viafbdev.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -19,6 +19,7 @@
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
+#include
#include
#include
#include
@@ -1468,7 +1469,7 @@ static const struct file_operations viaf
#endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
{
via_odev_to_seq(m, supported_odev_map[
viaparinfo->shared->chip_info.gfx_chip_name]);
[PATCH 4.4 13/70] video: goldfishfb: fix memory leak on driver remove
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Anton Vasilyev [ Upstream commit 5958fde72d04e7b8c6de3669d1f794a90997e3eb ] goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does not have deallocation of fb, which leads to memory leak on probe/remove. The patch adds deallocation into goldfish_fb_remove(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Anton Vasilyev Cc: Aleksandar Markovic Cc: Miodrag Dinic Cc: Goran Ferenc Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/video/fbdev/goldfishfb.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/video/fbdev/goldfishfb.c +++ b/drivers/video/fbdev/goldfishfb.c @@ -301,6 +301,7 @@ static int goldfish_fb_remove(struct pla dma_free_coherent(>dev, framesize, (void *)fb->fb.screen_base, fb->fb.fix.smem_start); iounmap(fb->reg_base); + kfree(fb); return 0; }
[PATCH 4.4 19/70] powerpc/powernv: opal_put_chars partial write fix
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Piggin
[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]
The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.
This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.
Reviewed-by: Benjamin Herrenschmidt
Signed-off-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/platforms/powernv/opal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -371,7 +371,7 @@ int opal_put_chars(uint32_t vtermno, con
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
- written = total_len;
+ written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
[PATCH 4.4 17/70] ARM: exynos: Clear global variable on init error path
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Krzysztof Kozlowski
[ Upstream commit cd4806911cee3901bc2b5eb95603cf1958720b57 ]
For most of Exynos SoCs, Power Management Unit (PMU) address space is
mapped into global variable 'pmu_base_addr' very early when initializing
PMU interrupt controller. A lot of other machine code depends on it so
when doing iounmap() on this address, clear the global as well to avoid
usage of invalid value (pointing to unmapped memory region).
Properly mapped PMU address space is a requirement for all other machine
code so this fix is purely theoretical. Boot will fail immediately in
many other places after following this error path.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/mach-exynos/suspend.c |1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -260,6 +260,7 @@ static int __init exynos_pmu_irq_init(st
NULL);
if (!domain) {
iounmap(pmu_base_addr);
+ pmu_base_addr = NULL;
return -ENOMEM;
}
[PATCH 4.4 12/70] fbdev: omapfb: off by one in omapfb_register_client()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 ]
The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.
Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter
Cc: Imre Deak
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/omap/omapfb_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -977,7 +977,7 @@ int omapfb_register_client(struct omapfb
{
int r;
- if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+ if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
if (!notifier_inited) {
[PATCH 4.4 23/70] arm64: dts: qcom: db410c: Fix Bluetooth LED trigger
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Loic Poulain
[ Upstream commit e53db018315b7660bb7000a29e79faff2496c2c2 ]
Current LED trigger, 'bt', is not known/used by any existing driver.
Fix this by renaming it to 'bluetooth-power' trigger which is
controlled by the Bluetooth subsystem.
Fixes: 9943230c8860 ("arm64: dts: qcom: Add apq8016-sbc board LED's related
device nodes")
Signed-off-by: Loic Poulain
Signed-off-by: Andy Gross
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -105,7 +105,7 @@
led@6 {
label = "apq8016-sbc:blue:bt";
gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "bt";
+ linux,default-trigger = "bluetooth-power";
default-state = "off";
};
};
[PATCH 4.4 28/70] xen-netfront: fix warn message as irq device name has /
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Xiao Liang
[ Upstream commit 21f2706b20100bb3db378461ab9b8e2035309b5b ]
There is a call trace generated after commit
2d408c0d4574b01b9ed45e02516888bf925e11a9(
xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file
found
under /proc/irq/xx/.
This patch only picks up device type and id as its name.
With the patch, now /proc/interrupts looks like below and the warning message
gone:
70: 21 0 0 0 xen-dyn-event
vif0-q0-tx
71: 15 0 0 0 xen-dyn-event
vif0-q0-rx
72: 14 0 0 0 xen-dyn-event
vif0-q1-tx
73: 33 0 0 0 xen-dyn-event
vif0-q1-rx
74: 12 0 0 0 xen-dyn-event
vif0-q2-tx
75: 24 0 0 0 xen-dyn-event
vif0-q2-rx
76: 19 0 0 0 xen-dyn-event
vif0-q3-tx
77: 21 0 0 0 xen-dyn-event
vif0-q3-rx
Below is call trace information without this patch:
name 'device/vif/0-q0-tx'
WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0
RIP: 0010:__xlate_proc_name+0x85/0xa0
RSP: 0018:b85c40473c18 EFLAGS: 00010286
RAX: RBX: 0006 RCX: 0006
RDX: 0007 RSI: 0096 RDI: 984c7f516930
RBP: b85c40473cb8 R08: 002c R09: 0229
R10: R11: 0001 R12: b85c40473c98
R13: b85c40473cb8 R14: b85c40473c50 R15:
FS: () GS:984c7f50() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f69b6899038 CR3: 1c20a006 CR4: 001606e0
Call Trace:
__proc_create+0x45/0x230
? snprintf+0x49/0x60
proc_mkdir_data+0x35/0x90
register_handler_proc+0xef/0x110
? proc_register+0xfc/0x110
? proc_create_data+0x70/0xb0
__setup_irq+0x39b/0x660
? request_threaded_irq+0xad/0x160
request_threaded_irq+0xf5/0x160
? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront]
bind_evtchn_to_irqhandler+0x3d/0x70
? xenbus_alloc_evtchn+0x41/0xa0
netback_changed+0xa46/0xcda [xen_netfront]
? find_watch+0x40/0x40
xenwatch_thread+0xc5/0x160
? finish_wait+0x80/0x80
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41
5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff ff
5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f
---[ end trace 650e5561b0caab3a ]---
Signed-off-by: Xiao Liang
Reviewed-by: Juergen Gross
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netfront.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1608,6 +1608,7 @@ static int xennet_init_queue(struct netf
{
unsigned short i;
int err = 0;
+ char *devid;
spin_lock_init(>tx_lock);
spin_lock_init(>rx_lock);
@@ -1615,8 +1616,9 @@ static int xennet_init_queue(struct netf
setup_timer(>rx_refill_timer, rx_refill_timeout,
(unsigned long)queue);
- snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-queue->info->xbdev->nodename, queue->id);
+ devid = strrchr(queue->info->xbdev->nodename, '/') + 1;
+ snprintf(queue->name, sizeof(queue->name), "vif%s-q%u",
+devid, queue->id);
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
[PATCH 4.4 18/70] perf powerpc: Fix callchain ip filtering
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Sandipan Das [ Upstream commit c715fcfda5a08edabaa15508742be926b7ee51db ] For powerpc64, redundant entries in the callchain are filtered out by determining the state of the return address and the stack frame using DWARF debug information. For making these filtering decisions we must analyze the debug information for the location corresponding to the program counter value, i.e. the first entry in the callchain, and not the LR value; otherwise, perf may filter out either the second or the third entry in the callchain incorrectly. This can be observed on a powerpc64le system running Fedora 27 as shown below. Case 1 - Attaching a probe at inet_pton+0x8 (binary offset 0x15af28). Return address is still in LR and a new stack frame is not yet allocated. The LR value, i.e. the second entry, should not be filtered out. # objdump -d /usr/lib64/libc-2.26.so | less ... 0010eb10 : ... 10fa48: 78 bb e4 7e mr r4,r23 10fa4c: 0a 00 60 38 li r3,10 10fa50: d9 b4 04 48 bl 15af28 10fa54: 00 00 00 60 nop 10fa58: ac f4 ff 4b b 10ef04 ... 00110450 : ... 1105a8: 54 00 ff 38 addir7,r31,84 1105ac: 58 00 df 38 addir6,r31,88 1105b0: 69 e5 ff 4b bl 10eb18 1105b4: 78 1b 71 7c mr r17,r3 1105b8: 50 01 7f e8 ld r3,336(r31) ... 0015af20 : 15af20: 0b 00 4c 3c addis r2,r12,11 15af24: e0 c1 42 38 addir2,r2,-15904 15af28: a6 02 08 7c mflrr0 15af2c: f0 ff c1 fb std r30,-16(r1) 15af30: f8 ff e1 fb std r31,-8(r1) ... # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x8 # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1 # perf script Before: ping 4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28) 7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so) 7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so) 13fb52d70 _init+0xbfc (/usr/bin/ping) 7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so) 7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so) 0 [unknown] ([unknown]) After: ping 4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28) 7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so) 7fffa7d6fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so) 7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so) 13fb52d70 _init+0xbfc (/usr/bin/ping) 7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so) 7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so) 0 [unknown] ([unknown]) Case 2 - Attaching a probe at _int_malloc+0x180 (binary offset 0x9cf10). Return address in still in LR and a new stack frame has already been allocated but not used. The caller's caller, i.e. the third entry, is invalid and should be filtered out and not the second one. # objdump -d /usr/lib64/libc-2.26.so | less ... 0009cd90 <_int_malloc>: 9cd90: 17 00 4c 3c addis r2,r12,23 9cd94: 70 a3 42 38 addir2,r2,-23696 9cd98: 26 00 80 7d mfcrr12 9cd9c: f8 ff e1 fb std r31,-8(r1) 9cda0: 17 00 e4 3b addir31,r4,23 9cda4: d8 ff 61 fb std r27,-40(r1) 9cda8: 78 23 9b 7c mr r27,r4 9cdac: 1f 00 bf 2b cmpldi cr7,r31,31 9cdb0: f0 ff c1 fb std r30,-16(r1) 9cdb4: b0 ff c1 fa std r22,-80(r1) 9cdb8: 78 1b 7e 7c mr r30,r3 9cdbc: 08 00 81 91 stw r12,8(r1) 9cdc0: 11 ff 21 f8 stdur1,-240(r1) 9cdc4: 4c 01 9d 41 bgt cr7,9cf10 <_int_malloc+0x180> 9cdc8: 20 00 a4 2b cmpldi cr7,r4,32 ... 9cf08: 00 00 00 60 nop 9cf0c: 00 00 42 60 ori r2,r2,0 9cf10: e4 06 ff 7b rldicr r31,r31,0,59 9cf14: 40 f8 a4 7f cmpld cr7,r4,r31 9cf18: 68 05 9d 41 bgt cr7,9d480 <_int_malloc+0x6f0> ... 0009e3c0 : ... 9e420: 40 02 80 38 li r4,576 9e424: 78 fb e3 7f mr r3,r31 9e428: 71 e9 ff 4b bl 9cd98 <_int_malloc+0x8> 9e42c: 00 00 a3 2f cmpdi cr7,r3,0 9e430: 78 1b 7e 7c mr r30,r3 ... 0009f7a0 <__libc_malloc>: ... 9f8f8: 00 00 89 2f cmpwi cr7,r9,0 9f8fc: 1c ff 9e 40 bne cr7,9f818 <__libc_malloc+0x78>
[PATCH 4.4 02/70] ALSA: msnd: Fix the default sample sizes
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
[ Upstream commit 7c500f9ea139d0c9b80fdea5a9c911db3166ea54 ]
The default sample sizes set by msnd driver are bogus; it sets ALSA
PCM format, not the actual bit width.
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
sound/isa/msnd/msnd_pinnacle.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/isa/msnd/msnd_pinnacle.c
+++ b/sound/isa/msnd/msnd_pinnacle.c
@@ -82,10 +82,10 @@
static void set_default_audio_parameters(struct snd_msnd *chip)
{
- chip->play_sample_size = DEFSAMPLESIZE;
+ chip->play_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->play_sample_rate = DEFSAMPLERATE;
chip->play_channels = DEFCHANNELS;
- chip->capture_sample_size = DEFSAMPLESIZE;
+ chip->capture_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->capture_sample_rate = DEFSAMPLERATE;
chip->capture_channels = DEFCHANNELS;
}
[PATCH 4.4 25/70] s390/qeth: reset layer2 attribute on layer switch
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Julian Wiedmann
[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]
After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.
If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.
Signed-off-by: Julian Wiedmann
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/s390/net/qeth_core_sys.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -419,6 +419,7 @@ static ssize_t qeth_dev_layer2_store(str
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+ card->options.layer2 = -1;
}
rc = qeth_core_load_discipline(card, newdis);
[PATCH 4.4 22/70] xen-netfront: fix queue name setting
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vitaly Kuznetsov
[ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]
Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up with the following in
/proc/interrupts:
60:139 0 xen-dyn-event eth%d-q0-tx
61:265 0 xen-dyn-event eth%d-q0-rx
62:234 0 xen-dyn-event eth%d-q1-tx
63: 1 0 xen-dyn-event eth%d-q1-rx
and this looks ugly. Actually, using early netdev name (even when it's
already set) is also not ideal: nowadays we tend to rename eth devices
and queue name may end up not corresponding to the netdev name.
Use nodename from xenbus device for queue naming: this can't change in VM's
lifetime. Now /proc/interrupts looks like
62:202 0 xen-dyn-event device/vif/0-q0-tx
63:317 0 xen-dyn-event device/vif/0-q0-rx
64:262 0 xen-dyn-event device/vif/0-q1-tx
65: 17 0 xen-dyn-event device/vif/0-q1-rx
Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Ross Lagerwall
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netfront.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1616,7 +1616,7 @@ static int xennet_init_queue(struct netf
(unsigned long)queue);
snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-queue->info->netdev->name, queue->id);
+queue->info->xbdev->nodename, queue->id);
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
[PATCH 4.4 20/70] MIPS: jz4740: Bump zload address
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Paul Cercueil [ Upstream commit c6ea7e9747318e5a6774995f4f8e3e0f7c0fa8ba ] Having the zload address at 0x8060. means the size of the uncompressed kernel cannot be bigger than around 6 MiB, as it is deflated at address 0x8001.. This limit is too small; a kernel with some built-in drivers and things like debugfs enabled will already be over 6 MiB in size, and so will fail to extract properly. To fix this, we bump the zload address from 0x8060. to 0x8100.. This is fine, as all the boards featuring Ingenic JZ SoCs have at least 32 MiB of RAM, and use u-boot or compatible bootloaders which won't hardcode the load address but read it from the uImage's header. Signed-off-by: Paul Cercueil Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/19787/ Cc: Ralf Baechle Cc: James Hogan Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/mips/jz4740/Platform |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/jz4740/Platform +++ b/arch/mips/jz4740/Platform @@ -1,4 +1,4 @@ platform-$(CONFIG_MACH_INGENIC)+= jz4740/ cflags-$(CONFIG_MACH_INGENIC) += -I$(srctree)/arch/mips/include/asm/mach-jz4740 load-$(CONFIG_MACH_INGENIC)+= 0x8001 -zload-$(CONFIG_MACH_INGENIC) += 0x8060 +zload-$(CONFIG_MACH_INGENIC) += 0x8100
[PATCH 4.4 21/70] mac80211: restrict delayed tailroom needed decrement
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Manikanta Pubbisetty
[ Upstream commit 133bf90dbb8b873286f8ec2e81ba26e863114b8c ]
As explained in ieee80211_delayed_tailroom_dec(), during roam,
keys of the old AP will be destroyed and new keys will be
installed. Deletion of the old key causes
crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
installation causes a transition from 0 to 1.
Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
we invoke synchronize_net(); the reason for doing this is to avoid
a race in the TX path as explained in increment_tailroom_need_count().
This synchronize_net() operation can be slow and can affect the station
roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
is delayed for a while so that upon installation of new key the
transition would be from 1 to 2 instead of 0 to 1 and thereby
improving the roam time.
This is all correct for a STA iftype, but deferring the tailroom_needed
decrement for other iftypes may be unnecessary.
For example, let's consider the case of a 4-addr client connecting to
an AP for which AP_VLAN interface is also created, let the initial
value for tailroom_needed on the AP be 1.
* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_needed count
* AP_VLAN is created, it takes the tailroom count from master
(AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
* Install new key for the station, assume key is plumbed in the HW,
there won't be any change in tailroom_needed count on AP iface
* Delayed decrement of tailroom_needed count on AP
(AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)
Because of the delayed decrement on AP iface, tailroom_needed count goes
out of sync between AP(master iface) and AP_VLAN(slave iface) and
there would be unnecessary tailroom created for the packets going
through AP_VLAN iface.
Also, WARN_ONs were observed while trying to bring down the AP_VLAN
interface:
(warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
(warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
(ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
(ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
(ieee80211_stop) (__dev_close_many+0x94/0xb8)
(__dev_close_many) (dev_close_many+0x5c/0xc8)
Restricting delayed decrement to station interface alone fixes the problem
and it makes sense to do so because delayed decrement is done to improve
roam time which is applicable only for client devices.
Signed-off-by: Manikanta Pubbisetty
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/mac80211/cfg.c |2 +-
net/mac80211/key.c | 24 +++-
2 files changed, 16 insertions(+), 10 deletions(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -286,7 +286,7 @@ static int ieee80211_del_key(struct wiph
goto out_unlock;
}
- ieee80211_key_free(key, true);
+ ieee80211_key_free(key, sdata->vif.type == NL80211_IFTYPE_STATION);
ret = 0;
out_unlock:
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -647,11 +647,15 @@ int ieee80211_key_link(struct ieee80211_
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_key *old_key;
- int idx, ret;
- bool pairwise;
-
- pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
- idx = key->conf.keyidx;
+ int idx = key->conf.keyidx;
+ bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+ /*
+* We want to delay tailroom updates only for station - in that
+* case it helps roaming speed, but in other cases it hurts and
+* can cause warnings to appear.
+*/
+ bool delay_tailroom = sdata->vif.type == NL80211_IFTYPE_STATION;
+ int ret;
mutex_lock(>local->key_mtx);
@@ -679,14 +683,14 @@ int ieee80211_key_link(struct ieee80211_
increment_tailroom_need_count(sdata);
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
- ieee80211_key_destroy(old_key, true);
+ ieee80211_key_destroy(old_key, delay_tailroom);
ieee80211_debugfs_key_add(key);
if (!local->wowlan) {
ret = ieee80211_key_enable_hw_accel(key);
if (ret)
- ieee80211_key_free(key, true);
+ ieee80211_key_free(key, delay_tailroom);
} else {
ret = 0;
}
@@ -874,7 +878,8 @@ void ieee80211_free_sta_keys(struct ieee
ieee80211_key_replace(key->sdata, key->sta,
key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
key, NULL);
- __ieee80211_key_destroy(key, true);
+ __ieee80211_key_destroy(key, key->sdata->vif.type ==
+
[PATCH 4.4 24/70] s390/qeth: fix race in used-buffer accounting
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Julian Wiedmann
[ Upstream commit a702349a4099cd5a7bab0904689d8e0bf8dcd622 ]
By updating q->used_buffers only _after_ do_QDIO() has completed, there
is a potential race against the buffer's TX completion. In the unlikely
case that the TX completion path wins, qeth_qdio_output_handler() would
decrement the counter before qeth_flush_buffers() even incremented it.
Signed-off-by: Julian Wiedmann
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/s390/net/qeth_core_main.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3505,13 +3505,14 @@ static void qeth_flush_buffers(struct qe
qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
if (atomic_read(>set_pci_flags_count))
qdio_flags |= QDIO_FLAG_PCI_OUT;
+ atomic_add(count, >used_buffers);
+
rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
queue->queue_no, index, count);
if (queue->card->options.performance_stats)
queue->card->perf_stats.outbound_do_qdio_time +=
qeth_get_micros() -
queue->card->perf_stats.outbound_do_qdio_start_time;
- atomic_add(count, >used_buffers);
if (rc) {
queue->card->stats.tx_errors += count;
/* ignore temporary SIGA errors without busy condition */
[PATCH 4.4 26/70] platform/x86: toshiba_acpi: Fix defined but not used build warnings
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]
Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.
../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show'
defined but not used [-Wunused-function]
Signed-off-by: Randy Dunlap
Cc: Azael Avalos
Cc: platform-driver-...@vger.kernel.org
Cc: Andy Shevchenko
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/platform/x86/toshiba_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -34,6 +34,7 @@
#define TOSHIBA_ACPI_VERSION "0.23"
#define PROC_INTERFACE_VERSION 1
+#include
#include
#include
#include
@@ -1472,7 +1473,7 @@ static const struct file_operations keys
.write = keys_proc_write,
};
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
{
seq_printf(m, "driver: %s\n", TOSHIBA_ACPI_VERSION);
seq_printf(m, "proc_interface: %d\n", PROC_INTERFACE_VERSION);
[PATCH 4.4 10/70] media: videobuf2-core: check for q->error in vb2_core_qbuf()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Hans Verkuil
[ Upstream commit b509d733d337417bcb7fa4a35be3b9a49332b724 ]
The vb2_core_qbuf() function didn't check if q->error was set. It is
checked in __buf_prepare(), but that function isn't called if the buffer
was already prepared before with VIDIOC_PREPARE_BUF.
So check it at the start of vb2_core_qbuf() as well.
Signed-off-by: Hans Verkuil
Acked-by: Sakari Ailus
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/v4l2-core/videobuf2-core.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1366,6 +1366,11 @@ int vb2_core_qbuf(struct vb2_queue *q, u
struct vb2_buffer *vb;
int ret;
+ if (q->error) {
+ dprintk(1, "fatal error occurred on queue\n");
+ return -EIO;
+ }
+
vb = q->bufs[index];
switch (vb->state) {
[PATCH 4.4 11/70] mtd/maps: fix solutionengine.c printk format warnings
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]
Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".
Fixes these build warnings:
../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov
Signed-off-by: Randy Dunlap
Signed-off-by: Boris Brezillon
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/maps/solutionengine.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
- printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at
0x%08lx\n",
- soleng_flash_map.phys & 0x1fff,
- soleng_eprom_map.phys & 0x1fff);
+ printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at
0x%pap\n",
+ _flash_map.phys,
+ _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
eprom_mtd = do_map_probe("map_rom", _eprom_map);
[PATCH 4.4 01/70] iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Miao Zhong [ Upstream commit 0d535967ac658966c6ade8f82b5799092f7d5441 ] When PRI queue occurs overflow, driver should update the OVACKFLG to the PRIQ consumer register, otherwise subsequent PRI requests will not be processed. Cc: Will Deacon Cc: Robin Murphy Signed-off-by: Miao Zhong Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/iommu/arm-smmu-v3.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -1219,6 +1219,7 @@ static irqreturn_t arm_smmu_priq_thread( /* Sync our overflow flag, as we believe we're up to speed */ q->cons = Q_OVF(q, q->prod) | Q_WRP(q, q->cons) | Q_IDX(q, q->cons); + writel(q->cons, q->cons_reg); return IRQ_HANDLED; }
[PATCH 4.4 16/70] fbdev: Distinguish between interlaced and progressive modes
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Fredrik Noring
[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]
I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:
}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},
In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.
In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.
Signed-off-by: Fredrik Noring
Cc: "Maciej W. Rozycki"
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/video/fbdev/core/modedb.c | 41 +++---
1 file changed, 30 insertions(+), 11 deletions(-)
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_scr
*
* Valid mode specifiers for @mode_option:
*
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
* [-][@]
*
* with , , and decimal numbers and
@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_scr
* If 'M' is present after yres (and before refresh/bpp if present),
* the function will compute the timings using VESA(tm) Coordinated
* Video Timings (CVT). If 'R' is present after 'M', will compute with
- * reduced blanking (for flatpanels). If 'i' is present, compute
- * interlaced mode. If 'm' is present, add margins equal to 1.8%
- * of xres rounded down to 8 pixels, and 1.8% of yres. The char
- * 'i' and 'm' must be after 'M' and 'R'. Example:
+ * reduced blanking (for flatpanels). If 'i' or 'p' are present, compute
+ * interlaced or progressive mode. If 'm' is present, add margins equal
+ * to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ * 'i', 'p' and 'm' must be after 'M' and 'R'. Example:
*
* 1024x768MR-8@60m - Reduced blank with margins at 60Hz.
*
@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninf
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
- int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+ int yres_specified = 0, cvt = 0, rb = 0;
+ int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninf
if (!cvt)
margins = 1;
break;
+ case 'p':
+ if (!cvt) {
+ interlace = 0;
+ interlace_specified = 1;
+ }
+ break;
case 'i':
- if (!cvt)
+ if (!cvt) {
interlace = 1;
+ interlace_specified = 1;
+ }
break;
default:
goto done;
@@ -819,11 +828,21 @@ done:
if ((name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres)))
&&
!fb_try_mode(var, info, [i], bpp)) {
- if (refresh_specified && db[i].refresh ==
refresh)
- return 1;
+ const int db_interlace = (db[i].vmode &
+ FB_VMODE_INTERLACED ? 1 : 0);
+ int score = abs(db[i].refresh - refresh);
+
+ if (interlace_specified)
+ score += abs(db_interlace - interlace);
+
+ if (!interlace_specified ||
+ db_interlace == interlace)
+ if (refresh_specified &&
+
[PATCH 4.4 03/70] ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
[ Upstream commit bd1cd0eb2ce9141100628d476ead4de485501b29 ]
AU0828_DEVICE() macro in quirks-table.h uses USB_DEVICE_VENDOR_SPEC()
for expanding idVendor and idProduct fields. However, the latter
macro adds also match_flags and bInterfaceClass, which are different
from the values AU0828_DEVICE() macro sets after that.
For fixing them, just expand idVendor and idProduct fields manually in
AU0828_DEVICE().
This fixes sparse warnings like:
sound/usb/quirks-table.h:2892:1: warning: Initializer entry defined twice
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
sound/usb/quirks-table.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2875,7 +2875,8 @@ YAMAHA_DEVICE(0x7010, "UB99"),
*/
#define AU0828_DEVICE(vid, pid, vname, pname) { \
- USB_DEVICE_VENDOR_SPEC(vid, pid), \
+ .idVendor = vid, \
+ .idProduct = pid, \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
USB_DEVICE_ID_MATCH_INT_CLASS | \
USB_DEVICE_ID_MATCH_INT_SUBCLASS, \
[PATCH 4.4 27/70] crypto: sharah - Unregister correct algorithms for SAHARA 3
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Michael Müller [ Upstream commit 0e7d4d932ffc23f75efb31a8c2ac2396c1b81c55 ] This patch fixes two typos related to unregistering algorithms supported by SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered in case of an error. In sahara_unregister_algs the wrong array is used to determine the iteration count. Signed-off-by: Michael Müller Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/crypto/sahara.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/crypto/sahara.c +++ b/drivers/crypto/sahara.c @@ -1363,7 +1363,7 @@ err_sha_v4_algs: err_sha_v3_algs: for (j = 0; j < k; j++) - crypto_unregister_ahash(_v4_algs[j]); + crypto_unregister_ahash(_v3_algs[j]); err_aes_algs: for (j = 0; j < i; j++) @@ -1379,7 +1379,7 @@ static void sahara_unregister_algs(struc for (i = 0; i < ARRAY_SIZE(aes_algs); i++) crypto_unregister_alg(_algs[i]); - for (i = 0; i < ARRAY_SIZE(sha_v4_algs); i++) + for (i = 0; i < ARRAY_SIZE(sha_v3_algs); i++) crypto_unregister_ahash(_v3_algs[i]); if (dev->version > SAHARA_VERSION_3)
Re: [PATCH] Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name"
On Mon, 2018-09-24 at 13:00 +0100, David Howells wrote:
> Lubomir Rintel wrote:
>
> > This changes UAPI, breaking iwd and libell:
> >
> > ell/key.c: In function 'kernel_dh_compute':
> > ell/key.c:205:38: error: 'struct keyctl_dh_params' has no member
> > named 'private'; did you mean 'dh_private'?
> > struct keyctl_dh_params params = { .private = private,
> > ^~~
> > dh_private
> >
> > This reverts commit 8a2336e549d385bb0b46880435b411df8d8200e8.
> >
> > Cc: David Howells
> > Cc: James Morris
> > Cc: "Serge E. Hallyn"
> > Cc: Mat Martineau
> > Cc: Andrew Morton
> > Cc: Linus Torvalds
> > Cc:
>
> Can I stick your Signed-off-by on it?
1. Yes, please do.
Signed-off-by: Lubomir Rintel
>
> David
Re: [PATCH v4] remoteproc: qcom: Introduce Non-PAS ADSP PIL driver
Hi Rohit,
Thanks for the quick turnaround, the patches look fine.
Reviewed-by: Sibi Sankar
Tested-by: Sibi Sankar
On 2018-09-24 16:37, Rohit kumar wrote:
This adds Non PAS ADSP PIL driver for Qualcomm
Technologies Inc SoCs.
Added initial support for SDM845 with ADSP bootup and
shutdown operation handled from Application Processor
SubSystem(APSS).
Signed-off-by: Rohit kumar
---
Changes since v3:
Addressed comments posted by Sibi
This patch is dependent on the rpmh powerdomain driver
https://lkml.org/lkml/2018/6/27/7
and renaming of Hexagon v5 PAS driver
https://patchwork.kernel.org/patch/10601119/ .
drivers/remoteproc/Kconfig | 14 ++
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/qcom_adsp_pil.c | 502
+
3 files changed, 517 insertions(+)
create mode 100644 drivers/remoteproc/qcom_adsp_pil.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 8894935..f554669 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -140,6 +140,20 @@ config QCOM_Q6V5_WCSS
Say y here to support the Qualcomm Peripheral Image Loader for the
Hexagon V5 based WCSS remote processors.
+config QCOM_ADSP_PIL
+ tristate "Qualcomm Technology Inc ADSP Peripheral Image Loader"
+ depends on OF && ARCH_QCOM
+ depends on QCOM_SMEM
+ depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
+ depends on QCOM_SYSMON || QCOM_SYSMON=n
+ select MFD_SYSCON
+ select QCOM_MDT_LOADER
+ select QCOM_Q6V5_COMMON
+ select QCOM_RPROC_COMMON
+ help
+ Say y here to support the Peripheral Image Loader
+ for the Qualcomm Technology Inc. ADSP remote processors.
+
config QCOM_SYSMON
tristate "Qualcomm sysmon driver"
depends on RPMSG
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 050f41a..0e1b89c 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_QCOM_Q6V5_COMMON)+= qcom_q6v5.o
obj-$(CONFIG_QCOM_Q6V5_MSS)+= qcom_q6v5_mss.o
obj-$(CONFIG_QCOM_Q6V5_PAS)+= qcom_q6v5_pas.o
obj-$(CONFIG_QCOM_Q6V5_WCSS) += qcom_q6v5_wcss.o
+obj-$(CONFIG_QCOM_ADSP_PIL)+= qcom_adsp_pil.o
obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
obj-$(CONFIG_QCOM_WCNSS_PIL) += qcom_wcnss_pil.o
qcom_wcnss_pil-y += qcom_wcnss.o
diff --git a/drivers/remoteproc/qcom_adsp_pil.c
b/drivers/remoteproc/qcom_adsp_pil.c
new file mode 100644
index 000..f2f5e56
--- /dev/null
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -0,0 +1,502 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Qualcomm Technology Inc. ADSP Peripheral Image Loader for SDM845.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "qcom_common.h"
+#include "qcom_q6v5.h"
+#include "remoteproc_internal.h"
+
+/* time out value */
+#define ACK_TIMEOUT1000
+#define BOOT_FSM_TIMEOUT 1
+/* mask values */
+#define EVB_MASK GENMASK(27, 4)
+/*QDSP6SS register offsets*/
+#define RST_EVB_REG0x10
+#define CORE_START_REG 0x400
+#define BOOT_CMD_REG 0x404
+#define BOOT_STATUS_REG0x408
+#define RET_CFG_REG0x1C
+/*TCSR register offsets*/
+#define LPASS_MASTER_IDLE_REG 0x8
+#define LPASS_HALTACK_REG 0x4
+#define LPASS_PWR_ON_REG 0x10
+#define LPASS_HALTREQ_REG 0x0
+
+/* list of clocks required by ADSP PIL */
+static const char * const adsp_clk_id[] = {
+ "sway_cbcr", "lpass_aon", "lpass_ahbs_aon_cbcr",
"lpass_ahbm_aon_cbcr",
+ "qdsp6ss_xo", "qdsp6ss_sleep", "qdsp6ss_core",
+};
+
+struct adsp_pil_data {
+ int crash_reason_smem;
+ const char *firmware_name;
+
+ const char *ssr_name;
+ const char *sysmon_name;
+ int ssctl_id;
+};
+
+struct qcom_adsp {
+ struct device *dev;
+ struct rproc *rproc;
+
+ struct qcom_q6v5 q6v5;
+
+ struct clk *xo;
+
+ int num_clks;
+ struct clk_bulk_data *clks;
+
+ void __iomem *qdsp6ss_base;
+
+ struct reset_control *pdc_sync_reset;
+ struct reset_control *cc_lpass_restart;
+
+ struct regmap *halt_map;
+ unsigned int halt_lpass;
+
+ int crash_reason_smem;
+
+ struct completion start_done;
+ struct completion stop_done;
+
+ phys_addr_t mem_phys;
+ phys_addr_t mem_reloc;
+ void *mem_region;
+ size_t mem_size;
+
+ struct qcom_rproc_glink glink_subdev;
+ struct qcom_rproc_ssr ssr_subdev;
+ struct
[PATCH 4.9 106/111] Partial revert "e1000e: Avoid receiver overrun interrupt bursts"
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Benjamin Poirier
commit 1f0ea19722ef9dfa229a9540f70b8d1c34a98a6a upstream.
This partially reverts commit 4aea7a5c5e940c1723add439f4088844cd26196d.
We keep the fix for the first part of the problem (1) described in the log
of that commit, that is to read ICR in the other interrupt handler. We
remove the fix for the second part of the problem (2), Other interrupt
throttling.
Bursts of "Other" interrupts may once again occur during rxo (receive
overflow) traffic conditions. This is deemed acceptable in the interest of
avoiding unforeseen fallout from changes that are not strictly necessary.
As discussed, the e1000e driver should be in "maintenance mode".
Link: https://www.spinics.net/lists/netdev/msg480675.html
Signed-off-by: Benjamin Poirier
Acked-by: Alexander Duyck
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Cc: Yanhui He
Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/intel/e1000e/netdev.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1912,21 +1912,10 @@ static irqreturn_t e1000_msix_other(int
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = >hw;
u32 icr;
- bool enable = true;
icr = er32(ICR);
ew32(ICR, E1000_ICR_OTHER);
- if (icr & E1000_ICR_RXO) {
- ew32(ICR, E1000_ICR_RXO);
- enable = false;
- /* napi poll will re-enable Other, make sure it runs */
- if (napi_schedule_prep(>napi)) {
- adapter->total_rx_bytes = 0;
- adapter->total_rx_packets = 0;
- __napi_schedule(>napi);
- }
- }
if (icr & E1000_ICR_LSC) {
ew32(ICR, E1000_ICR_LSC);
hw->mac.get_link_status = true;
@@ -1935,7 +1924,7 @@ static irqreturn_t e1000_msix_other(int
mod_timer(>watchdog_timer, jiffies + 1);
}
- if (enable && !test_bit(__E1000_DOWN, >state))
+ if (!test_bit(__E1000_DOWN, >state))
ew32(IMS, E1000_IMS_OTHER);
return IRQ_HANDLED;
@@ -2706,8 +2695,7 @@ static int e1000e_poll(struct napi_struc
napi_complete_done(napi, work_done);
if (!test_bit(__E1000_DOWN, >state)) {
if (adapter->msix_entries)
- ew32(IMS, adapter->rx_ring->ims_val |
-E1000_IMS_OTHER);
+ ew32(IMS, adapter->rx_ring->ims_val);
else
e1000_irq_enable(adapter);
}
[PATCH 4.9 108/111] e1000e: Avoid missed interrupts following ICR read
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Benjamin Poirier
commit 116f4a640b3197401bc93b8adc6c35040308ceff upstream.
The 82574 specification update errata 12 states that interrupts may be
missed if ICR is read while INT_ASSERTED is not set. Avoid that problem by
setting all bits related to events that can trigger the Other interrupt in
IMS.
The Other interrupt is raised for such events regardless of whether or not
they are set in IMS. However, only when they are set is the INT_ASSERTED
bit also set in ICR.
By doing this, we ensure that INT_ASSERTED is always set when we read ICR
in e1000_msix_other() and steer clear of the errata. This also ensures that
ICR will automatically be cleared on read, therefore we no longer need to
clear bits explicitly.
Signed-off-by: Benjamin Poirier
Acked-by: Alexander Duyck
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
[bwh: Backported to 4.9: adjust context]
Cc: Yanhui He
Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/intel/e1000e/defines.h | 21 -
drivers/net/ethernet/intel/e1000e/netdev.c | 11 ---
2 files changed, 24 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/defines.h
+++ b/drivers/net/ethernet/intel/e1000e/defines.h
@@ -400,6 +400,10 @@
#define E1000_ICR_RXDMT00x0010 /* Rx desc min. threshold (0) */
#define E1000_ICR_RXO 0x0040 /* Receiver Overrun */
#define E1000_ICR_RXT0 0x0080 /* Rx timer intr (ring 0) */
+#define E1000_ICR_MDAC 0x0200 /* MDIO Access Complete */
+#define E1000_ICR_SRPD 0x0001 /* Small Receive Packet Detected */
+#define E1000_ICR_ACK 0x0002 /* Receive ACK Frame Detected */
+#define E1000_ICR_MNG 0x0004 /* Manageability Event Detected */
#define E1000_ICR_ECCER 0x0040 /* Uncorrectable ECC Error */
/* If this bit asserted, the driver should claim the interrupt */
#define E1000_ICR_INT_ASSERTED 0x8000
@@ -407,7 +411,7 @@
#define E1000_ICR_RXQ1 0x0020 /* Rx Queue 1 Interrupt */
#define E1000_ICR_TXQ0 0x0040 /* Tx Queue 0 Interrupt */
#define E1000_ICR_TXQ1 0x0080 /* Tx Queue 1 Interrupt */
-#define E1000_ICR_OTHER 0x0100 /* Other Interrupts */
+#define E1000_ICR_OTHER 0x0100 /* Other Interrupt */
/* PBA ECC Register */
#define E1000_PBA_ECC_COUNTER_MASK 0xFFF0 /* ECC counter mask */
@@ -431,12 +435,27 @@
E1000_IMS_RXSEQ |\
E1000_IMS_LSC)
+/* These are all of the events related to the OTHER interrupt.
+ */
+#define IMS_OTHER_MASK ( \
+ E1000_IMS_LSC | \
+ E1000_IMS_RXO | \
+ E1000_IMS_MDAC | \
+ E1000_IMS_SRPD | \
+ E1000_IMS_ACK | \
+ E1000_IMS_MNG)
+
/* Interrupt Mask Set */
#define E1000_IMS_TXDW E1000_ICR_TXDW /* Transmit desc written back
*/
#define E1000_IMS_LSC E1000_ICR_LSC /* Link Status Change */
#define E1000_IMS_RXSEQ E1000_ICR_RXSEQ /* Rx sequence error */
#define E1000_IMS_RXDMT0E1000_ICR_RXDMT0/* Rx desc min. threshold */
+#define E1000_IMS_RXO E1000_ICR_RXO /* Receiver Overrun */
#define E1000_IMS_RXT0 E1000_ICR_RXT0 /* Rx timer intr */
+#define E1000_IMS_MDAC E1000_ICR_MDAC /* MDIO Access Complete */
+#define E1000_IMS_SRPD E1000_ICR_SRPD /* Small Receive Packet */
+#define E1000_IMS_ACK E1000_ICR_ACK /* Receive ACK Frame Detected
*/
+#define E1000_IMS_MNG E1000_ICR_MNG /* Manageability Event */
#define E1000_IMS_ECCER E1000_ICR_ECCER /* Uncorrectable ECC Error */
#define E1000_IMS_RXQ0 E1000_ICR_RXQ0 /* Rx Queue 0 Interrupt */
#define E1000_IMS_RXQ1 E1000_ICR_RXQ1 /* Rx Queue 1 Interrupt */
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1911,16 +1911,12 @@ static irqreturn_t e1000_msix_other(int
struct net_device *netdev = data;
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = >hw;
- u32 icr;
-
- icr = er32(ICR);
- ew32(ICR, E1000_ICR_OTHER);
+ u32 icr = er32(ICR);
if (icr & adapter->eiac_mask)
ew32(ICS, (icr & adapter->eiac_mask));
if (icr & E1000_ICR_LSC) {
- ew32(ICR, E1000_ICR_LSC);
hw->mac.get_link_status = true;
/* guard against interrupt when we're going down */
if (!test_bit(__E1000_DOWN, >state))
@@ -1928,7 +1924,7 @@ static irqreturn_t e1000_msix_other(int
}
if (!test_bit(__E1000_DOWN, >state))
- ew32(IMS, E1000_IMS_OTHER);
+ ew32(IMS, E1000_IMS_OTHER | IMS_OTHER_MASK);
return IRQ_HANDLED;
}
@@ -2255,7 +2251,8 @@ static void e1000_irq_enable(struct e100
if
[PATCH 4.9 104/111] MIPS: VDSO: Match data page cache colouring when D$ aliases
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Burton
commit 0f02cfbc3d9e413d450d8d0fd660077c23f67eff upstream.
When a system suffers from dcache aliasing a user program may observe
stale VDSO data from an aliased cache line. Notably this can break the
expectation that clock_gettime(CLOCK_MONOTONIC, ...) is, as its name
suggests, monotonic.
In order to ensure that users observe updates to the VDSO data page as
intended, align the user mappings of the VDSO data page such that their
cache colouring matches that of the virtual address range which the
kernel will use to update the data page - typically its unmapped address
within kseg0.
This ensures that we don't introduce aliasing cache lines for the VDSO
data page, and therefore that userland will observe updates without
requiring cache invalidation.
Signed-off-by: Paul Burton
Reported-by: Hauke Mehrtens
Reported-by: Rene Nielsen
Reported-by: Alexandre Belloni
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Patchwork: https://patchwork.linux-mips.org/patch/20344/
Tested-by: Alexandre Belloni
Tested-by: Hauke Mehrtens
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: sta...@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman
---
arch/mips/kernel/vdso.c | 20
1 file changed, 20 insertions(+)
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -14,12 +14,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
/* Kernel-provided data used by the VDSO. */
@@ -129,12 +131,30 @@ int arch_setup_additional_pages(struct l
vvar_size = gic_size + PAGE_SIZE;
size = vvar_size + image->size;
+ /*
+* Find a region that's large enough for us to perform the
+* colour-matching alignment below.
+*/
+ if (cpu_has_dc_aliases)
+ size += shm_align_mask + 1;
+
base = get_unmapped_area(NULL, 0, size, 0, 0);
if (IS_ERR_VALUE(base)) {
ret = base;
goto out;
}
+ /*
+* If we suffer from dcache aliasing, ensure that the VDSO data page
+* mapping is coloured the same as the kernel's mapping of that memory.
+* This ensures that when the kernel updates the VDSO data userland
+* will observe it without requiring cache invalidations.
+*/
+ if (cpu_has_dc_aliases) {
+ base = __ALIGN_MASK(base, shm_align_mask);
+ base += ((unsigned long)_data - gic_size) & shm_align_mask;
+ }
+
data_addr = base + gic_size;
vdso_addr = data_addr + PAGE_SIZE;
[PATCH 4.9 107/111] e1000e: Fix queue interrupt re-raising in Other interrupt
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Benjamin Poirier
commit 361a954e6a7215de11a6179ad9bdc07d7e394b04 upstream.
Restores the ICS write for Rx/Tx queue interrupts which was present before
commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1)
but was not restored in commit 4aea7a5c5e94
("e1000e: Avoid receiver overrun interrupt bursts", v4.15-rc1).
This re-raises the queue interrupts in case the txq or rxq bits were set in
ICR and the Other interrupt handler read and cleared ICR before the queue
interrupt was raised.
Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
Signed-off-by: Benjamin Poirier
Acked-by: Alexander Duyck
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Cc: Yanhui He
Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/intel/e1000e/netdev.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1916,6 +1916,9 @@ static irqreturn_t e1000_msix_other(int
icr = er32(ICR);
ew32(ICR, E1000_ICR_OTHER);
+ if (icr & adapter->eiac_mask)
+ ew32(ICS, (icr & adapter->eiac_mask));
+
if (icr & E1000_ICR_LSC) {
ew32(ICR, E1000_ICR_LSC);
hw->mac.get_link_status = true;
[PATCH 4.9 109/111] Revert "e1000e: Separate signaling for link check/link up"
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Benjamin Poirier
commit 3016e0a0c91246e55418825ba9aae271be267522 upstream.
This reverts commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013.
This reverts commit 4110e02eb45ea447ec6f5459c9934de0a273fb91.
This reverts commit d3604515c9eda464a92e8e67aae82dfe07fe3c98.
Commit 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
changed what happens to the link status when there is an error which
happens after "get_link_status = false" in the copper check_for_link
callbacks. Previously, such an error would be ignored and the link
considered up. After that commit, any error implies that the link is down.
Revert commit 19110cfbb34d ("e1000e: Separate signaling for link check/link
up") and its followups. After reverting, the race condition described in
the log of commit 19110cfbb34d is reintroduced. It may still be triggered
by LSC events but this should keep the link down in case the link is
electrically unstable, as discussed. The race may no longer be
triggered by RXO events because commit 4aea7a5c5e94 ("e1000e: Avoid
receiver overrun interrupt bursts") restored reading icr in the Other
handler.
Link: https://lkml.org/lkml/2018/3/1/789
Signed-off-by: Benjamin Poirier
Acked-by: Alexander Duyck
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Cc: Yanhui He
Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 13 -
drivers/net/ethernet/intel/e1000e/mac.c | 13 -
drivers/net/ethernet/intel/e1000e/netdev.c |2 +-
3 files changed, 9 insertions(+), 19 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1364,9 +1364,6 @@ out:
* Checks to see of the link status of the hardware has changed. If a
* change in link status has been detected, then we read the PHY registers
* to get the current speed/duplex if link exists.
- *
- * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
- * up).
**/
static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
{
@@ -1382,7 +1379,7 @@ static s32 e1000_check_for_copper_link_i
* Change or Rx Sequence Error interrupt.
*/
if (!mac->get_link_status)
- return 1;
+ return 0;
/* First we want to see if the MII Status Register reports
* link. If so, then we want to get the current speed/duplex
@@ -1600,7 +1597,7 @@ static s32 e1000_check_for_copper_link_i
* we have already determined whether we have link or not.
*/
if (!mac->autoneg)
- return 1;
+ return -E1000_ERR_CONFIG;
/* Auto-Neg is enabled. Auto Speed Detection takes care
* of MAC speed/duplex configuration. So we only need to
@@ -1614,12 +1611,10 @@ static s32 e1000_check_for_copper_link_i
* different link partner.
*/
ret_val = e1000e_config_fc_after_link_up(hw);
- if (ret_val) {
+ if (ret_val)
e_dbg("Error configuring flow control\n");
- return ret_val;
- }
- return 1;
+ return ret_val;
}
static s32 e1000_get_variants_ich8lan(struct e1000_adapter *adapter)
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -410,9 +410,6 @@ void e1000e_clear_hw_cntrs_base(struct e
* Checks to see of the link status of the hardware has changed. If a
* change in link status has been detected, then we read the PHY registers
* to get the current speed/duplex if link exists.
- *
- * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
- * up).
**/
s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
{
@@ -426,7 +423,7 @@ s32 e1000e_check_for_copper_link(struct
* Change or Rx Sequence Error interrupt.
*/
if (!mac->get_link_status)
- return 1;
+ return 0;
/* First we want to see if the MII Status Register reports
* link. If so, then we want to get the current speed/duplex
@@ -450,7 +447,7 @@ s32 e1000e_check_for_copper_link(struct
* we have already determined whether we have link or not.
*/
if (!mac->autoneg)
- return 1;
+ return -E1000_ERR_CONFIG;
/* Auto-Neg is enabled. Auto Speed Detection takes care
* of MAC speed/duplex configuration. So we only need to
@@ -464,12 +461,10 @@ s32 e1000e_check_for_copper_link(struct
* different link partner.
*/
ret_val = e1000e_config_fc_after_link_up(hw);
- if (ret_val) {
+ if (ret_val)
e_dbg("Error configuring flow control\n");
- return ret_val;
- }
- return 1;
+ return ret_val;
}
/**
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++
Re: [PATCH 0/3] fuse: Solve request_find() bottleneck
2 weeks passed, so ping. Miklos, any reaction on this? Thanks, Kirill On 11.09.2018 13:11, Kirill Tkhai wrote: > Hi, > > We noticed the performance bottle neck in FUSE running our > Virtuozzo storage over rdma. On some types of workload > we observe 20% of time spent in request_find() in profiler. > This function is iterating over long list of requests, and it > scales bad. > > The patch introduces hash table to reduce the number > of iterations, we do in this function. Also, algorithm > of generating IDs for interrupt requests is changed, > simplified request_find() function and killed > fuse_req::intr_unique field. > > Kirill > --- > > Kirill Tkhai (3): > fuse: Change interrupt requests allocation algorhythm > fuse: Kill fuse_req::intr_unique > fuse: Use hash table to link processing request > > > fs/fuse/dev.c| 47 +-- > fs/fuse/fuse_i.h | 11 +-- > fs/fuse/inode.c |5 - > 3 files changed, 46 insertions(+), 17 deletions(-) > > -- > Signed-off-by: Kirill Tkhai >
[PATCH 4.14 094/173] USB: net2280: Fix erroneous synchronization change
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Alan Stern
commit dec3c23c9aa1815f07d98ae0375b4cbc10971e13 upstream.
Commit f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking
for callbacks") was based on a serious misunderstanding. It
introduced regressions into both the dummy-hcd and net2280 drivers.
The problem in dummy-hcd was fixed by commit 7dbd8f4cabd9 ("USB:
dummy-hcd: Fix erroneous synchronization change"), but the problem in
net2280 remains. Namely: the ->disconnect(), ->suspend(), ->resume(),
and ->reset() callbacks must be invoked without the private lock held;
otherwise a deadlock will occur when the callback routine tries to
interact with the UDC driver.
This patch largely is a reversion of the relevant parts of
f16443a034c7. It also drops the private lock around the calls to
->suspend() and ->resume() (something the earlier patch forgot to do).
This is safe from races with device interrupts because it occurs
within the interrupt handler.
Finally, the patch changes where the ->disconnect() callback is
invoked when net2280_pullup() turns the pullup off. Rather than
making the callback from within stop_activity() at a time when dropping
the private lock could be unsafe, the callback is moved to a point
after the lock has already been dropped.
Signed-off-by: Alan Stern
Fixes: f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for
callbacks")
Reported-by: D. Ziesche
Tested-by: D. Ziesche
CC:
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/gadget/udc/net2280.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -1549,11 +1549,14 @@ static int net2280_pullup(struct usb_gad
writel(tmp | BIT(USB_DETECT_ENABLE), >usb->usbctl);
} else {
writel(tmp & ~BIT(USB_DETECT_ENABLE), >usb->usbctl);
- stop_activity(dev, dev->driver);
+ stop_activity(dev, NULL);
}
spin_unlock_irqrestore(>lock, flags);
+ if (!is_on && dev->driver)
+ dev->driver->disconnect(>gadget);
+
return 0;
}
@@ -2470,8 +2473,11 @@ static void stop_activity(struct net2280
nuke(>ep[i]);
/* report disconnect; the driver is already quiesced */
- if (driver)
+ if (driver) {
+ spin_unlock(>lock);
driver->disconnect(>gadget);
+ spin_lock(>lock);
+ }
usb_reinit(dev);
}
@@ -3345,6 +3351,8 @@ next_endpoints:
BIT(PCI_RETRY_ABORT_INTERRUPT))
static void handle_stat1_irqs(struct net2280 *dev, u32 stat)
+__releases(dev->lock)
+__acquires(dev->lock)
{
struct net2280_ep *ep;
u32 tmp, num, mask, scratch;
@@ -3385,12 +3393,14 @@ static void handle_stat1_irqs(struct net
if (disconnect || reset) {
stop_activity(dev, dev->driver);
ep0_start(dev);
+ spin_unlock(>lock);
if (reset)
usb_gadget_udc_reset
(>gadget, dev->driver);
else
(dev->driver->disconnect)
(>gadget);
+ spin_lock(>lock);
return;
}
}
@@ -3409,6 +3419,7 @@ static void handle_stat1_irqs(struct net
tmp = BIT(SUSPEND_REQUEST_CHANGE_INTERRUPT);
if (stat & tmp) {
writel(tmp, >regs->irqstat1);
+ spin_unlock(>lock);
if (stat & BIT(SUSPEND_REQUEST_INTERRUPT)) {
if (dev->driver->suspend)
dev->driver->suspend(>gadget);
@@ -3419,6 +3430,7 @@ static void handle_stat1_irqs(struct net
dev->driver->resume(>gadget);
/* at high speed, note erratum 0133 */
}
+ spin_lock(>lock);
stat &= ~tmp;
}
[PATCH 4.14 093/173] usb: gadget: udc: renesas_usb3: fix maxpacket size of ep0
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Yoshihiro Shimoda
commit dfe1a51d2a36647f74cbad478801efa7cf394376 upstream.
This patch fixes an issue that maxpacket size of ep0 is incorrect
for SuperSpeed. Otherwise, CDC NCM class with SuperSpeed doesn't
work correctly on this driver because its control read data size
is more than 64 bytes.
Reported-by: Junki Kato
Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0
peripheral controller")
Cc: # v4.5+
Signed-off-by: Yoshihiro Shimoda
Tested-by: Junki Kato
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/gadget/udc/renesas_usb3.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -788,12 +788,15 @@ static void usb3_irq_epc_int_1_speed(str
switch (speed) {
case USB_STA_SPEED_SS:
usb3->gadget.speed = USB_SPEED_SUPER;
+ usb3->gadget.ep0->maxpacket = USB3_EP0_SS_MAX_PACKET_SIZE;
break;
case USB_STA_SPEED_HS:
usb3->gadget.speed = USB_SPEED_HIGH;
+ usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE;
break;
case USB_STA_SPEED_FS:
usb3->gadget.speed = USB_SPEED_FULL;
+ usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE;
break;
default:
usb3->gadget.speed = USB_SPEED_UNKNOWN;
@@ -2458,7 +2461,7 @@ static int renesas_usb3_init_ep(struct r
/* for control pipe */
usb3->gadget.ep0 = _ep->ep;
usb_ep_set_maxpacket_limit(_ep->ep,
- USB3_EP0_HSFS_MAX_PACKET_SIZE);
+ USB3_EP0_SS_MAX_PACKET_SIZE);
usb3_ep->ep.caps.type_control = true;
usb3_ep->ep.caps.dir_in = true;
usb3_ep->ep.caps.dir_out = true;
[PATCH 4.14 091/173] usb: host: u132-hcd: Fix a sleep-in-atomic-context bug in u132_get_frame()
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Jia-Ju Bai
commit 6d4f268fa132742fe96dad22307c68d237356d88 upstream.
i_usX2Y_subs_startup in usbusx2yaudio.c is a completion handler function
for the USB driver. So it should not sleep, but it is can sleep
according to the function call paths (from bottom to top) in Linux-4.16.
[FUNC] msleep
drivers/usb/host/u132-hcd.c, 2558:
msleep in u132_get_frame
drivers/usb/core/hcd.c, 2231:
[FUNC_PTR]u132_get_frame in usb_hcd_get_frame_number
drivers/usb/core/usb.c, 822:
usb_hcd_get_frame_number in usb_get_current_frame_number
sound/usb/usx2y/usbusx2yaudio.c, 303:
usb_get_current_frame_number in i_usX2Y_urb_complete
sound/usb/usx2y/usbusx2yaudio.c, 366:
i_usX2Y_urb_complete in i_usX2Y_subs_startup
Note that [FUNC_PTR] means a function pointer call is used.
To fix this bug, msleep() is replaced with mdelay().
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/u132-hcd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -2559,7 +2559,7 @@ static int u132_get_frame(struct usb_hcd
} else {
int frame = 0;
dev_err(>platform_dev->dev, "TODO: u132_get_frame\n");
- msleep(100);
+ mdelay(100);
return frame;
}
}
[PATCH 4.14 095/173] USB: serial: io_ti: fix array underflow in completion handler
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit 691a03cfe8ca483f9c48153b869d354e4ae3abef upstream.
As reported by Dan Carpenter, a malicious USB device could set
port_number to a negative value and we would underflow the port array in
the interrupt completion handler.
As these devices only have one or two ports, fix this by making sure we
only consider the seventh bit when determining the port number (and
ignore bits 0xb0 which are typically set to 0x30).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Reported-by: Dan Carpenter
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/io_ti.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/io_ti.h
+++ b/drivers/usb/serial/io_ti.h
@@ -178,7 +178,7 @@ struct ump_interrupt {
} __attribute__((packed));
-#define TIUMP_GET_PORT_FROM_CODE(c)(((c) >> 4) - 3)
+#define TIUMP_GET_PORT_FROM_CODE(c)(((c) >> 6) & 0x01)
#define TIUMP_GET_FUNC_FROM_CODE(c)((c) & 0x0f)
#define TIUMP_INTERRUPT_CODE_LSR 0x03
#define TIUMP_INTERRUPT_CODE_MSR 0x04
[PATCH 4.14 096/173] usb: misc: uss720: Fix two sleep-in-atomic-context bugs
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Jia-Ju Bai
commit bc8acc214d3f1cafebcbcd101a695bbac716595d upstream.
async_complete() in uss720.c is a completion handler function for the
USB driver. So it should not sleep, but it is can sleep according to the
function call paths (from bottom to top) in Linux-4.16.
[FUNC] set_1284_register(GFP_KERNEL)
drivers/usb/misc/uss720.c, 372:
set_1284_register in parport_uss720_frob_control
drivers/parport/ieee1284.c, 560:
[FUNC_PTR]parport_uss720_frob_control in parport_ieee1284_ack_data_avail
drivers/parport/ieee1284.c, 577:
parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
./include/linux/parport.h, 474:
parport_ieee1284_interrupt in parport_generic_irq
drivers/usb/misc/uss720.c, 116:
parport_generic_irq in async_complete
[FUNC] get_1284_register(GFP_KERNEL)
drivers/usb/misc/uss720.c, 382:
get_1284_register in parport_uss720_read_status
drivers/parport/ieee1284.c, 555:
[FUNC_PTR]parport_uss720_read_status in parport_ieee1284_ack_data_avail
drivers/parport/ieee1284.c, 577:
parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
./include/linux/parport.h, 474:
parport_ieee1284_interrupt in parport_generic_irq
drivers/usb/misc/uss720.c, 116:
parport_generic_irq in async_complete
Note that [FUNC_PTR] means a function pointer call is used.
To fix these bugs, GFP_KERNEL is replaced with GFP_ATOMIC.
These bugs are found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/misc/uss720.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -382,7 +382,7 @@ static unsigned char parport_uss720_frob
mask &= 0x0f;
val &= 0x0f;
d = (priv->reg[1] & (~mask)) ^ val;
- if (set_1284_register(pp, 2, d, GFP_KERNEL))
+ if (set_1284_register(pp, 2, d, GFP_ATOMIC))
return 0;
priv->reg[1] = d;
return d & 0xf;
@@ -392,7 +392,7 @@ static unsigned char parport_uss720_read
{
unsigned char ret;
- if (get_1284_register(pp, 1, , GFP_KERNEL))
+ if (get_1284_register(pp, 1, , GFP_ATOMIC))
return 0;
return ret & 0xf8;
}
[PATCH 4.14 101/173] cifs: prevent integer overflow in nxt_dir_entry()
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
commit 8ad8aa353524d89fa2e09522f3078166ff78ec42 upstream.
The "old_entry + le32_to_cpu(pDirInfo->NextEntryOffset)" can wrap
around so I have added a check for integer overflow.
Reported-by: Dr Silvio Cesare of InfoSect
Reviewed-by: Ronnie Sahlberg
Reviewed-by: Aurelien Aptel
Signed-off-by: Dan Carpenter
Signed-off-by: Steve French
CC: Stable
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/readdir.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -376,8 +376,15 @@ static char *nxt_dir_entry(char *old_ent
new_entry = old_entry + sizeof(FIND_FILE_STANDARD_INFO) +
pfData->FileNameLength;
- } else
- new_entry = old_entry + le32_to_cpu(pDirInfo->NextEntryOffset);
+ } else {
+ u32 next_offset = le32_to_cpu(pDirInfo->NextEntryOffset);
+
+ if (old_entry + next_offset < old_entry) {
+ cifs_dbg(VFS, "invalid offset %u\n", next_offset);
+ return NULL;
+ }
+ new_entry = old_entry + next_offset;
+ }
cifs_dbg(FYI, "new entry %p old entry %p\n", new_entry, old_entry);
/* validate that new_entry is not past end of SMB */
if (new_entry >= end_of_smb) {
[PATCH 4.14 067/173] drivers/base: stop new probing during shutdown
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Pingfan Liu
[ Upstream commit 3297c8fc65af5d40501ea7cddff1b195cae57e4e ]
There is a race window in device_shutdown(), which may cause
-1. parent device shut down before child or
-2. no shutdown on a new probing device.
For 1st, taking the following scenario:
device_shutdownnew plugin device
list_del_init(parent_dev);
spin_unlock(list_lock);
device_add(child)
probe child
shutdown parent_dev
--> now child is on the tail of devices_kset
For 2nd, taking the following scenario:
device_shutdownnew plugin device
device_add(dev)
device_lock(dev);
...
device_unlock(dev);
probe dev
--> now, the new occurred dev has no opportunity to shutdown
To fix this race issue, just prevent the new probing request. With this
logic, device_shutdown() is more similar to dpm_prepare().
Signed-off-by: Pingfan Liu
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2783,6 +2783,9 @@ void device_shutdown(void)
{
struct device *dev, *parent;
+ wait_for_device_probe();
+ device_block_probing();
+
spin_lock(_kset->list_lock);
/*
* Walk the devices list backward, shutting down each in turn.
[PATCH 0/2] KEYS: Revert and replace incorrect UAPI fix
Hi James, Here's a pair of fixes that need to go upstream asap, please: (1) Revert an incorrect fix to the keyrings UAPI for a C++ reserved word used as a struct member name. This change being reverted breaks existing userspace code and is thus incorrect. Further, *neither* name is consistent with the one in the keyutils package public header. (2) Fix the problem by using a union to make the name from keyutils available in parallel and make the 'private' name unavailable in C++ with cpp-conditionals. David --- David Howells (1): keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h Lubomir Rintel (1): Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name" include/uapi/linux/keyctl.h |7 ++- security/keys/dh.c |2 +- 2 files changed, 7 insertions(+), 2 deletions(-)
[PATCH 4.14 064/173] s390/qeth: reset layer2 attribute on layer switch
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Julian Wiedmann
[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]
After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.
If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.
Signed-off-by: Julian Wiedmann
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/s390/net/qeth_core_sys.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -423,6 +423,7 @@ static ssize_t qeth_dev_layer2_store(str
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+ card->options.layer2 = -1;
}
rc = qeth_core_load_discipline(card, newdis);
[PATCH 4.14 099/173] usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Jia-Ju Bai
commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427 upstream.
wdm_in_callback() is a completion handler function for the USB driver.
So it should not sleep. But it calls service_outstanding_interrupt(),
which calls usb_submit_urb() with GFP_KERNEL.
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/class/cdc-wdm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -457,7 +457,7 @@ static int service_outstanding_interrupt
set_bit(WDM_RESPONDING, >flags);
spin_unlock_irq(>iuspin);
- rv = usb_submit_urb(desc->response, GFP_KERNEL);
+ rv = usb_submit_urb(desc->response, GFP_ATOMIC);
spin_lock_irq(>iuspin);
if (rv) {
dev_err(>intf->dev,
[PATCH 4.14 062/173] ARM: dts: qcom: msm8974-hammerhead: increase load on l20 for sdhci
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Bhushan Shah
[ Upstream commit 03864e57770a9541e7ff3990bacf2d9a2fffcd5d ]
The kernel would not boot on the hammerhead hardware due to the
following error:
mmc0: Timeout waiting for hardware interrupt.
mmc0: sdhci: SDHCI REGISTER DUMP ===
mmc0: sdhci: Sys addr: 0x0200 | Version: 0x3802
mmc0: sdhci: Blk size: 0x0200 | Blk cnt: 0x0200
mmc0: sdhci: Argument: 0x | Trn mode: 0x0023
mmc0: sdhci: Present: 0x03e8 | Host ctl: 0x0034
mmc0: sdhci: Power: 0x0001 | Blk gap: 0x
mmc0: sdhci: Wake-up: 0x | Clock:0x0007
mmc0: sdhci: Timeout: 0x000e | Int stat: 0x
mmc0: sdhci: Int enab: 0x02ff900b | Sig enab: 0x02ff100b
mmc0: sdhci: AC12 err: 0x | Slot int: 0x
mmc0: sdhci: Caps: 0x642dc8b2 | Caps_1: 0x8007
mmc0: sdhci: Cmd: 0x0c1b | Max curr: 0x
mmc0: sdhci: Resp[0]: 0x0c00 | Resp[1]: 0x
mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x
mmc0: sdhci: Host ctl2: 0x0008
mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x70040220
mmc0: sdhci:
mmc0: Card stuck in wrong state! mmcblk0 card_busy_detect status: 0xe00
mmc0: cache flush error -110
mmc0: Reset 0x1 never completed.
This patch increases the load on l20 to 0.2 amps for the sdhci
and allows the device to boot normally.
Signed-off-by: Bhushan Shah
Signed-off-by: Brian Masney
Suggested-by: Bjorn Andersson
Tested-by: Brian Masney
Signed-off-by: Andy Gross
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts |2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -189,6 +189,8 @@
regulator-max-microvolt =
<295>;
regulator-boot-on;
+ regulator-system-load =
<20>;
+ regulator-allow-set-load;
};
l21 {
[PATCH 4.14 098/173] USB: yurex: Fix buffer over-read in yurex_write()
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit 7e10f14ebface44a48275c8d6dc1caae3668d5a9 upstream.
If the written data starts with a digit, yurex_write() tries to parse
it as an integer using simple_strtoull(). This requires a null-
terminator, and currently there's no guarantee that there is one.
(The sample program at
https://github.com/NeoCat/YUREX-driver-for-Linux/blob/master/sample/yurex_clock.pl
writes an integer without a null terminator. It seems like it must
have worked by chance!)
Always add a null byte after the written data. Enlarge the buffer
to allow for this.
Cc: sta...@vger.kernel.org
Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/misc/yurex.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -425,13 +425,13 @@ static ssize_t yurex_write(struct file *
{
struct usb_yurex *dev;
int i, set = 0, retval = 0;
- char buffer[16];
+ char buffer[16 + 1];
char *data = buffer;
unsigned long long c, c2 = 0;
signed long timeout = 0;
DEFINE_WAIT(wait);
- count = min(sizeof(buffer), count);
+ count = min(sizeof(buffer) - 1, count);
dev = file->private_data;
/* verify that we actually have some data to write */
@@ -450,6 +450,7 @@ static ssize_t yurex_write(struct file *
retval = -EFAULT;
goto error;
}
+ buffer[count] = 0;
memset(dev->cntl_buffer, CMD_PADDING, YUREX_BUF_SIZE);
switch (buffer[0]) {
[PATCH 4.14 063/173] s390/qeth: fix race in used-buffer accounting
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Julian Wiedmann
[ Upstream commit a702349a4099cd5a7bab0904689d8e0bf8dcd622 ]
By updating q->used_buffers only _after_ do_QDIO() has completed, there
is a potential race against the buffer's TX completion. In the unlikely
case that the TX completion path wins, qeth_qdio_output_handler() would
decrement the counter before qeth_flush_buffers() even incremented it.
Signed-off-by: Julian Wiedmann
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/s390/net/qeth_core_main.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3507,13 +3507,14 @@ static void qeth_flush_buffers(struct qe
qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
if (atomic_read(>set_pci_flags_count))
qdio_flags |= QDIO_FLAG_PCI_OUT;
+ atomic_add(count, >used_buffers);
+
rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
queue->queue_no, index, count);
if (queue->card->options.performance_stats)
queue->card->perf_stats.outbound_do_qdio_time +=
qeth_get_micros() -
queue->card->perf_stats.outbound_do_qdio_start_time;
- atomic_add(count, >used_buffers);
if (rc) {
queue->card->stats.tx_errors += count;
/* ignore temporary SIGA errors without busy condition */
[PATCH 4.14 113/173] Bluetooth: Use lock_sock_nested in bt_accept_enqueue
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Philipp Puschmann
[ Upstream commit b71c69c26b4916d11b8d403d8e667bbd191f1b8f ]
Fixes this warning that was provoked by a pairing:
[60258.016221] WARNING: possible recursive locking detected
[60258.021558] 4.15.0-RD1812-BSP #1 Tainted: G O
[60258.027146]
[60258.032464] kworker/u5:0/70 is trying to acquire lock:
[60258.037609] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<87759073>]
bt_accept_enqueue+0x3c/0x74
[60258.046863]
[60258.046863] but task is already holding lock:
[60258.052704] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: []
l2cap_sock_new_connection_cb+0x1c/0x88
[60258.062905]
[60258.062905] other info that might help us debug this:
[60258.069441] Possible unsafe locking scenario:
[60258.069441]
[60258.075368]CPU0
[60258.077821]
[60258.080272] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.085510] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.090748]
[60258.090748] *** DEADLOCK ***
[60258.090748]
[60258.096676] May be due to missing lock nesting notation
[60258.096676]
[60258.103472] 5 locks held by kworker/u5:0/70:
[60258.107747] #0: ((wq_completion)%shdev->name#2){+.+.}, at: [<9460d092>]
process_one_work+0x130/0x4fc
[60258.117263] #1: ((work_completion)(>rx_work)){+.+.}, at:
[<9460d092>] process_one_work+0x130/0x4fc
[60258.126942] #2: (>chan_lock){+.+.}, at: [<7877c8c3>]
l2cap_connect+0x80/0x4f8
[60258.134806] #3: (>lock/2){+.+.}, at: [<2e16c724>]
l2cap_connect+0x8c/0x4f8
[60258.142410] #4: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at:
[] l2cap_sock_new_connection_cb+0x1c/0x88
[60258.153043]
[60258.153043] stack backtrace:
[60258.157413] CPU: 1 PID: 70 Comm: kworker/u5:0 Tainted: G O
4.15.0-RD1812-BSP #1
[60258.165945] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[60258.172485] Workqueue: hci0 hci_rx_work
[60258.176331] Backtrace:
[60258.178797] [<8010c9fc>] (dump_backtrace) from [<8010ccbc>]
(show_stack+0x18/0x1c)
[60258.186379] r7:80e55fe4 r6:80e55fe4 r5:20050093 r4:
[60258.192058] [<8010cca4>] (show_stack) from [<809864e8>]
(dump_stack+0xb0/0xdc)
[60258.199301] [<80986438>] (dump_stack) from [<8016ecc8>]
(__lock_acquire+0xffc/0x11d4)
[60258.207144] r9:5e2bb019 r8:630f974c r7:ba8a5940 r6:ba8a5ed8 r5:815b5220
r4:80fa081c
[60258.214901] [<8016dccc>] (__lock_acquire) from [<8016f620>]
(lock_acquire+0x78/0x98)
[60258.222655] r10:0040 r9:0040 r8:808729f0 r7:0001 r6:
r5:60050013
[60258.230491] r4:
[60258.233045] [<8016f5a8>] (lock_acquire) from [<806ee974>]
(lock_sock_nested+0x64/0x88)
[60258.240970] r7: r6:b796e870 r5:0001 r4:b796e800
[60258.246643] [<806ee910>] (lock_sock_nested) from [<808729f0>]
(bt_accept_enqueue+0x3c/0x74)
[60258.255004] r8:0001 r7:ba7d3c00 r6:ba7d3ea4 r5:ba7d2000 r4:b796e800
[60258.261717] [<808729b4>] (bt_accept_enqueue) from [<808aa39c>]
(l2cap_sock_new_connection_cb+0x68/0x88)
[60258.271117] r5:b796e800 r4:ba7d2000
[60258.274708] [<808aa334>] (l2cap_sock_new_connection_cb) from [<808a294c>]
(l2cap_connect+0x190/0x4f8)
[60258.283933] r5:0001 r4:ba6dce00
[60258.287524] [<808a27bc>] (l2cap_connect) from [<808a4a14>]
(l2cap_recv_frame+0x744/0x2cf8)
[60258.295800] r10:ba6dcf24 r9:0004 r8:b78d8014 r7:0004 r6:bb05d000
r5:0004
[60258.303635] r4:bb05d008
[60258.306183] [<808a42d0>] (l2cap_recv_frame) from [<808a7808>]
(l2cap_recv_acldata+0x210/0x214)
[60258.314805] r10:b78e7800 r9:bb05d960 r8:0001 r7:bb05d000 r6:000c
r5:b7957a80
[60258.322641] r4:ba6dce00
[60258.325188] [<808a75f8>] (l2cap_recv_acldata) from [<8087630c>]
(hci_rx_work+0x35c/0x4e8)
[60258.74] r6:80e5743c r5:bb05d7c8 r4:b7957a80
[60258.338004] [<80875fb0>] (hci_rx_work) from [<8013dc7c>]
(process_one_work+0x1a4/0x4fc)
[60258.346018] r10:0001 r9: r8:baabfef8 r7:ba997500 r6:baaba800
r5:baaa5d00
[60258.353853] r4:bb05d7c8
[60258.356401] [<8013dad8>] (process_one_work) from [<8013e028>]
(worker_thread+0x54/0x5cc)
[60258.364503] r10:baabe038 r9:baaba834 r8:80e05900 r7:0088 r6:baaa5d18
r5:baaba800
[60258.372338] r4:baaa5d00
[60258.374888] [<8013dfd4>] (worker_thread) from [<801448f8>]
(kthread+0x134/0x160)
[60258.382295] r10:ba8310b8 r9:bb07dbfc r8:8013dfd4 r7:baaa5d00 r6:
r5:baaa8ac0
[60258.390130] r4:ba831080
[60258.392682] [<801447c4>] (kthread) from [<801080b4>]
(ret_from_fork+0x14/0x20)
[60258.399915] r10: r9: r8: r7: r6:
r5:801447c4
[60258.407751] r4:baaa8ac0 r3:baabe000
Signed-off-by: Philipp Puschmann
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/bluetooth/af_bluetooth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -159,7 +159,7 @@ void
[PATCH 4.14 115/173] KVM: PPC: Book3S HV: Add of_node_put() in success path
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit 51eaa08f029c7343df846325d7cf047be8b96e81 ]
The call to of_find_compatible_node() is returning a pointer with
incremented refcount so it must be explicitly decremented after the
last use. As here it is only being used for checking of node presence
but the result is not actually used in the success path it can be
dropped immediately.
Signed-off-by: Nicholas Mc Guire
Fixes: commit f725758b899f ("KVM: PPC: Book3S HV: Use OPAL XICS emulation on
POWER9")
Signed-off-by: Paul Mackerras
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kvm/book3s_hv.c |2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4356,6 +4356,8 @@ static int kvmppc_book3s_init_hv(void)
pr_err("KVM-HV: Cannot determine method for accessing
XICS\n");
return -ENODEV;
}
+ /* presence of intc confirmed - node can be dropped again */
+ of_node_put(np);
}
#endif
[PATCH 4.14 114/173] evm: Dont deadlock if a crypto algorithm is unavailable
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Matthew Garrett
[ Upstream commit e2861fa71641c6414831d628a1f4f793b6562580 ]
When EVM attempts to appraise a file signed with a crypto algorithm the
kernel doesn't have support for, it will cause the kernel to trigger a
module load. If the EVM policy includes appraisal of kernel modules this
will in turn call back into EVM - since EVM is holding a lock until the
crypto initialisation is complete, this triggers a deadlock. Add a
CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag
in the EVM case in order to fail gracefully with an error message
instead of deadlocking.
Signed-off-by: Matthew Garrett
Acked-by: Herbert Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
crypto/api.c|2 +-
include/linux/crypto.h |5 +
security/integrity/evm/evm_crypto.c |3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -215,7 +215,7 @@ struct crypto_alg *crypto_larval_lookup(
mask &= ~(CRYPTO_ALG_LARVAL | CRYPTO_ALG_DEAD);
alg = crypto_alg_lookup(name, type, mask);
- if (!alg) {
+ if (!alg && !(mask & CRYPTO_NOLOAD)) {
request_module("crypto-%s", name);
if (!((type ^ CRYPTO_ALG_NEED_FALLBACK) & mask &
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -112,6 +112,11 @@
#define CRYPTO_ALG_OPTIONAL_KEY0x4000
/*
+ * Don't trigger module loading
+ */
+#define CRYPTO_NOLOAD 0x8000
+
+/*
* Transform masks and values (for crt_flags).
*/
#define CRYPTO_TFM_NEED_KEY0x0001
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -94,7 +94,8 @@ static struct shash_desc *init_desc(char
mutex_lock();
if (*tfm)
goto out;
- *tfm = crypto_alloc_shash(algo, 0, CRYPTO_ALG_ASYNC);
+ *tfm = crypto_alloc_shash(algo, 0,
+ CRYPTO_ALG_ASYNC | CRYPTO_NOLOAD);
if (IS_ERR(*tfm)) {
rc = PTR_ERR(*tfm);
pr_err("Can not allocate %s (reason: %ld)\n", algo, rc);
[PATCH 2/2] keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h
The keyctl_dh_params struct in uapi/linux/keyctl.h contains the symbol
"private" which means that the header file will cause compilation failure
if #included in to a C++ program. Further, the patch that added the same
struct to the keyutils package named the symbol "priv", not "private".
The previous attempt to fix this (commit 8a2336e549d3) did so by simply
renaming the kernel's copy of the field to dh_private, but this then breaks
existing userspace and as such has to be reverted (which is done by the
preceding patch).
[And note, to those who think that wrapping the struct in extern "C" {}
will work: it won't; that only changes how symbol names are presented to
the assembler and linker.].
Instead, insert an anonymous union around the "private" member and add a
second member in there with the name "priv" to match the one in the
keyutils package. The "private" member is then wrapped in !__cplusplus
cpp-conditionals to hide it from C++.
Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
Fixes: 8a2336e549d3 ("uapi/linux/keyctl.h: don't use C++ reserved keyword as a
struct member name")
Signed-off-by: David Howells
cc: Randy Dunlap
cc: Lubomir Rintel
cc: James Morris
cc: Mat Martineau
cc: Stephan Mueller
cc: Andrew Morton
cc: Linus Torvalds
cc: sta...@vger.kernel.org
---
include/uapi/linux/keyctl.h |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 7b8c9e19bad1..0f3cb13db8e9 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -65,7 +65,12 @@
/* keyctl structures */
struct keyctl_dh_params {
- __s32 private;
+ union {
+#ifndef __cplusplus
+ __s32 private;
+#endif
+ __s32 priv;
+ };
__s32 prime;
__s32 base;
};
[PATCH 4.14 065/173] platform/x86: toshiba_acpi: Fix defined but not used build warnings
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]
Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.
../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show'
defined but not used [-Wunused-function]
Signed-off-by: Randy Dunlap
Cc: Azael Avalos
Cc: platform-driver-...@vger.kernel.org
Cc: Andy Shevchenko
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/platform/x86/toshiba_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -34,6 +34,7 @@
#define TOSHIBA_ACPI_VERSION "0.24"
#define PROC_INTERFACE_VERSION 1
+#include
#include
#include
#include
@@ -1682,7 +1683,7 @@ static const struct file_operations keys
.write = keys_proc_write,
};
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
{
seq_printf(m, "driver: %s\n", TOSHIBA_ACPI_VERSION);
seq_printf(m, "proc_interface: %d\n", PROC_INTERFACE_VERSION);
[PATCH 4.14 058/173] efi/arm: preserve early mapping of UEFI memory map longer for BGRT
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ard Biesheuvel
[ Upstream commit 3ea86495aef2f6de26b7cb1599ba350dd6a0c521 ]
The BGRT code validates the contents of the table against the UEFI
memory map, and so it expects it to be mapped when the code runs.
On ARM, this is currently not the case, since we tear down the early
mapping after efi_init() completes, and only create the permanent
mapping in arm_enable_runtime_services(), which executes as an early
initcall, but still leaves a window where the UEFI memory map is not
mapped.
So move the call to efi_memmap_unmap() from efi_init() to
arm_enable_runtime_services().
Signed-off-by: Ard Biesheuvel
[will: fold in EFI_MEMMAP attribute check from Ard]
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/firmware/efi/arm-init.c|1 -
drivers/firmware/efi/arm-runtime.c |4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
reserve_regions();
efi_esrt_init();
- efi_memmap_unmap();
memblock_reserve(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -122,11 +122,13 @@ static int __init arm_enable_runtime_ser
{
u64 mapsize;
- if (!efi_enabled(EFI_BOOT)) {
+ if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
pr_info("EFI services will not be available.\n");
return 0;
}
+ efi_memmap_unmap();
+
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
return 0;
[PATCH 4.14 097/173] USB: serial: ti_usb_3410_5052: fix array underflow in completion handler
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
commit 5dfdd24eb3d39d815bc952ae98128e967c9bba49 upstream.
Similarly to a recently reported bug in io_ti, a malicious USB device
could set port_number to a negative value and we would underflow the
port array in the interrupt completion handler.
As these devices only have one or two ports, fix this by making sure we
only consider the seventh bit when determining the port number (and
ignore bits 0xb0 which are typically set to 0x30).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/ti_usb_3410_5052.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -1123,7 +1123,7 @@ static void ti_break(struct tty_struct *
static int ti_get_port_from_code(unsigned char code)
{
- return (code >> 4) - 3;
+ return (code >> 6) & 0x01;
}
static int ti_get_func_from_code(unsigned char code)
[PATCH 4.14 123/173] ARM: hisi: handle of_iomap and fix missing of_node_put
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit d396cb185c0337aae5664b250cdd9a73f6eb1503 ]
Relying on an unchecked of_iomap() which can return NULL is problematic
here, an explicit check seems mandatory. Also the call to
of_find_compatible_node() returns a device node with refcount incremented
therefor an explicit of_node_put() is needed here.
Signed-off-by: Nicholas Mc Guire
Fixes: commit 22bae4290457 ("ARM: hi3xxx: add hotplug support")
Signed-off-by: Wei Xu
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/mach-hisi/hotplug.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -148,13 +148,20 @@ static int hi3xxx_hotplug_init(void)
struct device_node *node;
node = of_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
- if (node) {
- ctrl_base = of_iomap(node, 0);
- id = HI3620_CTRL;
- return 0;
+ if (!node) {
+ id = ERROR_CTRL;
+ return -ENOENT;
}
- id = ERROR_CTRL;
- return -ENOENT;
+
+ ctrl_base = of_iomap(node, 0);
+ of_node_put(node);
+ if (!ctrl_base) {
+ id = ERROR_CTRL;
+ return -ENOMEM;
+ }
+
+ id = HI3620_CTRL;
+ return 0;
}
void hi3xxx_set_cpu(int cpu, bool enable)
[PATCH 4.14 129/173] tty: fix termios input-speed encoding
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Johan Hovold
[ Upstream commit fada18c48d774b9e837928ecdce6a5d5fdd11ee7 ]
Make sure to clear the CIBAUD bits before OR-ing the new mask when
encoding the termios input baud rate.
This could otherwise lead to an incorrect input rate being reported back
and incidentally set on subsequent termios updates.
Fixes: edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework")
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/tty_baudrate.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/tty/tty_baudrate.c
+++ b/drivers/tty/tty_baudrate.c
@@ -172,6 +172,9 @@ void tty_termios_encode_baud_rate(struct
iclose = 0;
#endif
termios->c_cflag &= ~CBAUD;
+#ifdef IBSHIFT
+ termios->c_cflag &= ~(CBAUD << IBSHIFT);
+#endif
/*
* Our goal is to find a close match to the standard baud rate
[PATCH 4.14 125/173] ARM: hisi: check of_iomap and fix missing of_node_put
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit 81646a3d39ef14749301374a3a0b8311384cd412 ]
of_find_compatible_node() returns a device node with refcount incremented
and thus needs an explicit of_node_put(). Further relying on an unchecked
of_iomap() which can return NULL is problematic here, after all ctrl_base
is critical enough for hix5hd2_set_cpu() to call BUG() if not available
so a check seems mandated here.
Signed-off-by: Nicholas Mc Guire
0002 Fixes: commit 06cc5c1d4d73 ("ARM: hisi: enable hix5hd2 SoC")
Signed-off-by: Wei Xu
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/mach-hisi/hotplug.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -180,11 +180,15 @@ static bool hix5hd2_hotplug_init(void)
struct device_node *np;
np = of_find_compatible_node(NULL, NULL, "hisilicon,cpuctrl");
- if (np) {
- ctrl_base = of_iomap(np, 0);
- return true;
- }
- return false;
+ if (!np)
+ return false;
+
+ ctrl_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!ctrl_base)
+ return false;
+
+ return true;
}
void hix5hd2_set_cpu(int cpu, bool enable)
[PATCH 4.14 122/173] efi/esrt: Only call efi_mem_reserve() for boot services memory
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ard Biesheuvel
[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]
The following commit:
7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")
refactored the implementation of efi_mem_desc_lookup() so that the type
check is moved to the callers, one of which is the x86 version of
efi_arch_mem_reserve(), where we added a modified check that only takes
EFI_BOOT_SERVICES_DATA regions into account.
This is reasonable, since it is the only memory type that requires this,
but doing so uncovered some unexpected behavior in the ESRT code, which
permits the ESRT table to reside in other types of memory than what the
UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally
calls efi_mem_reserve() on the region in question. This may result in
errors such as
esrt: Reserving ESRT space from 0x9c810318 to 0x9c810350.
efi: Failed to lookup EFI memory descriptor for 0x9c810318
when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try
to reserve it nonetheless.
So make the call to efi_mem_reserve() conditional on the memory type.
Signed-off-by: Ard Biesheuvel
Cc: Linus Torvalds
Cc: Peter Jones
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/firmware/efi/esrt.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -333,7 +333,8 @@ void __init efi_esrt_init(void)
end = esrt_data + size;
pr_info("Reserving ESRT space from %pa to %pa.\n", _data, );
- efi_mem_reserve(esrt_data, esrt_data_size);
+ if (md.type == EFI_BOOT_SERVICES_DATA)
+ efi_mem_reserve(esrt_data, esrt_data_size);
pr_debug("esrt-init: loaded.\n");
err_memunmap:
[PATCH 4.14 131/173] mmc: tegra: prevent HS200 on Tegra 3
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Stefan Agner
[ Upstream commit 127407e36f4fe3a1d5e8b9998b479956ce83a7dc ]
The stack assumes that SDHC controller which support SD3.0 (SDR104) do
support HS200. This is not the case for Tegra 3, which does support SD
3.0
but only supports eMMC spec 4.41.
Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not
support HS200.
Note that commit 156e14b126ff ("mmc: sdhci: fix caps2 for HS200") added
the tie between SD3.0 (SDR104) and HS200. I don't think that this is
necessarly true. It is fully legitimate to support SD3.0 and not support
HS200. The quirk naming suggests something is broken in the controller,
but this is not the case: The controller simply does not support HS200.
Fixes: 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")
Signed-off-by: Stefan Agner
Tested-by: Marcel Ziswiler
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-tegra.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -334,7 +334,8 @@ static const struct sdhci_pltfm_data sdh
SDHCI_QUIRK_NO_HISPD_BIT |
SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
- .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+ .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
+ SDHCI_QUIRK2_BROKEN_HS200,
.ops = _sdhci_ops,
};
[PATCH 4.14 130/173] mmc: sdhci-of-esdhc: set proper dma mask for ls104x chips
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Laurentiu Tudor
[ Upstream commit 5552d7ad596c3fea953f40fef74170ce0760c04d ]
SDHCI controller in ls1043a and ls1046a generate 40-bit wide addresses
when doing DMA. Make sure that the corresponding dma mask is correctly
configured.
Context: when enabling smmu on these chips the following problem is
encountered: the smmu input address size is 48 bits so the dma mappings
for sdhci end up 48-bit wide. However, on these chips sdhci only use
40-bits of that address size when doing dma.
So you end up with a 48-bit address translation in smmu but the device
generates transactions with clipped 40-bit addresses, thus smmu context
faults are triggered. Setting up the correct dma mask fixes this
situation.
Signed-off-by: Laurentiu Tudor
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-of-esdhc.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -427,6 +428,11 @@ static void esdhc_of_adma_workaround(str
static int esdhc_of_enable_dma(struct sdhci_host *host)
{
u32 value;
+ struct device *dev = mmc_dev(host->mmc);
+
+ if (of_device_is_compatible(dev->of_node, "fsl,ls1043a-esdhc") ||
+ of_device_is_compatible(dev->of_node, "fsl,ls1046a-esdhc"))
+ dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
value = sdhci_readl(host, ESDHC_DMA_SYSCTL);
value |= ESDHC_DMA_SNOOP;
[PATCH 4.14 132/173] mmc: sdhci: do not try to use 3.3V signaling if not supported
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Stefan Agner
[ Upstream commit 1b5190c2e74c47ebe4bcecf7a072358ad9f1feaa ]
For eMMC devices it is valid to only support 1.8V signaling. When
vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V
initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed
Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is
not available. This prevents the stack from even trying to use
3.3V signaling and avoids the above warning.
Signed-off-by: Stefan Agner
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3631,14 +3631,21 @@ int sdhci_setup_host(struct sdhci_host *
mmc_gpio_get_cd(host->mmc) < 0)
mmc->caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_enable(mmc->supply.vqmmc);
+
+ /* If vqmmc provides no 1.8V signalling, then there's no UHS */
if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 170,
195))
host->caps1 &= ~(SDHCI_SUPPORT_SDR104 |
SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50);
+
+ /* In eMMC case vqmmc might be a fixed 1.8V regulator */
+ if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 270,
+ 360))
+ host->flags &= ~SDHCI_SIGNALING_330;
+
if (ret) {
pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
mmc_hostname(mmc), ret);
[PATCH 4.14 135/173] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thierry Reding
[ Upstream commit b59fb482b52269977ee5de205308e5b236a03917 ]
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the memory controller).
Transparently backing DMA memory with an IOMMU prevents Nouveau from
properly handling such memory accesses and causes memory access faults.
As a side-note: buffers other than those allocated in instance memory
don't need to be physically contiguous from the GPU's perspective since
the GPU can map them into contiguous buffers using its own MMU. Mapping
these buffers through the IOMMU is unnecessary and will even lead to
performance degradation because of the additional translation. One
exception to this are compressible buffers which need large pages. In
order to enable these large pages, multiple small pages will have to be
combined into one large (I/O virtually contiguous) mapping via the
IOMMU. However, that is a topic outside the scope of this fix and isn't
currently supported. An implementation will want to explicitly create
these large pages in the Nouveau driver, so detaching from a DMA/IOMMU
mapping would still be required.
Signed-off-by: Thierry Reding
Acked-by: Christoph Hellwig
Reviewed-by: Robin Murphy
Tested-by: Nicolas Chauvet
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 +
1 file changed, 13 insertions(+)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -23,6 +23,10 @@
#ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
#include "priv.h"
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+#include
+#endif
+
static int
nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
{
@@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvk
unsigned long pgsize_bitmap;
int ret;
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+ if (dev->archdata.mapping) {
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+ arm_iommu_detach_device(dev);
+ arm_iommu_release_mapping(mapping);
+ }
+#endif
+
if (!tdev->func->iommu_bit)
return;
[PATCH 4.14 124/173] ARM: hisi: fix error handling and missing of_node_put
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit 9f30b5ae0585ca5234fe979294b8f897299dec99 ]
of_iomap() can return NULL which seems critical here and thus should be
explicitly flagged so that the cause of system halting can be understood.
As of_find_compatible_node() is returning a device node with refcount
incremented it must be explicitly decremented here.
Signed-off-by: Nicholas Mc Guire
Fixes: commit 7fda91e73155 ("ARM: hisi: enable smp for HiP01")
Signed-off-by: Wei Xu
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/mach-hisi/hotplug.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -226,10 +226,10 @@ void hip01_set_cpu(int cpu, bool enable)
if (!ctrl_base) {
np = of_find_compatible_node(NULL, NULL,
"hisilicon,hip01-sysctrl");
- if (np)
- ctrl_base = of_iomap(np, 0);
- else
- BUG();
+ BUG_ON(!np);
+ ctrl_base = of_iomap(np, 0);
+ of_node_put(np);
+ BUG_ON(!ctrl_base);
}
if (enable) {
[PATCH 4.14 103/173] xtensa: ISS: dont allocate memory in platform_setup
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit ef439d49e0bfb26cd5f03c88b4cb7cc9073ed30c upstream.
Memory allocator is not initialized at that point yet, use static array
instead.
Cc: sta...@vger.kernel.org
Signed-off-by: Max Filippov
Signed-off-by: Greg Kroah-Hartman
---
arch/xtensa/platforms/iss/setup.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
--- a/arch/xtensa/platforms/iss/setup.c
+++ b/arch/xtensa/platforms/iss/setup.c
@@ -78,23 +78,28 @@ static struct notifier_block iss_panic_b
void __init platform_setup(char **p_cmdline)
{
+ static void *argv[COMMAND_LINE_SIZE / sizeof(void *)] __initdata;
+ static char cmdline[COMMAND_LINE_SIZE] __initdata;
int argc = simc_argc();
int argv_size = simc_argv_size();
if (argc > 1) {
- void **argv = alloc_bootmem(argv_size);
- char *cmdline = alloc_bootmem(argv_size);
- int i;
+ if (argv_size > sizeof(argv)) {
+ pr_err("%s: command line too long: argv_size = %d\n",
+ __func__, argv_size);
+ } else {
+ int i;
- cmdline[0] = 0;
- simc_argv((void *)argv);
+ cmdline[0] = 0;
+ simc_argv((void *)argv);
- for (i = 1; i < argc; ++i) {
- if (i > 1)
- strcat(cmdline, " ");
- strcat(cmdline, argv[i]);
+ for (i = 1; i < argc; ++i) {
+ if (i > 1)
+ strcat(cmdline, " ");
+ strcat(cmdline, argv[i]);
+ }
+ *p_cmdline = cmdline;
}
- *p_cmdline = cmdline;
}
atomic_notifier_chain_register(_notifier_list, _panic_block);
[PATCH 4.14 134/173] drm/nouveau/debugfs: Wake up GPU before doing any reclocking
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Karol Herbst [ Upstream commit eaeb9010bb4bcdc20e58254fa42f3fe730a7f908 ] Fixes various reclocking related issues on prime systems. Signed-off-by: Karol Herbst Signed-off-by: Martin Peres Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/nouveau/nouveau_debugfs.c |4 1 file changed, 4 insertions(+) --- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c +++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c @@ -160,7 +160,11 @@ nouveau_debugfs_pstate_set(struct file * args.ustate = value; } + ret = pm_runtime_get_sync(drm->dev); + if (IS_ERR_VALUE(ret) && ret != -EACCES) + return ret; ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, , sizeof(args)); + pm_runtime_put_autosuspend(drm->dev); if (ret < 0) return ret;
[PATCH 4.14 136/173] parport: sunbpp: fix error return code
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Julia Lawall
[ Upstream commit faa1a47388b33623e4d504c23569188907b039a0 ]
Return an error code on failure. Change leading spaces to tab on the
first if.
Problem found using Coccinelle.
Signed-off-by: Julia Lawall
Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/parport/parport_sunbpp.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/parport/parport_sunbpp.c
+++ b/drivers/parport/parport_sunbpp.c
@@ -286,12 +286,16 @@ static int bpp_probe(struct platform_dev
ops = kmemdup(_sunbpp_ops, sizeof(struct parport_operations),
GFP_KERNEL);
-if (!ops)
+ if (!ops) {
+ err = -ENOMEM;
goto out_unmap;
+ }
dprintk(("register_port\n"));
- if (!(p = parport_register_port((unsigned long)base, irq, dma, ops)))
+ if (!(p = parport_register_port((unsigned long)base, irq, dma, ops))) {
+ err = -ENOMEM;
goto out_free_ops;
+ }
p->size = size;
p->dev = >dev;
[PATCH 4.14 133/173] drm/nouveau: Fix runtime PM leak in drm_open()
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
[ Upstream commit 922a8c82fafdec99688bbaea6c5889f562a42cdc ]
Noticed this as I was skimming through, if we fail to allocate memory
for cli we'll end up returning without dropping the runtime PM ref we
got. Additionally, we'll even return the wrong return code! (ret most
likely will == 0 here, we want -ENOMEM).
Signed-off-by: Lyude Paul
Reviewed-by: Lukas Wunner
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_drm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -848,8 +848,10 @@ nouveau_drm_open(struct drm_device *dev,
get_task_comm(tmpname, current);
snprintf(name, sizeof(name), "%s[%d]", tmpname, pid_nr(fpriv->pid));
- if (!(cli = kzalloc(sizeof(*cli), GFP_KERNEL)))
- return ret;
+ if (!(cli = kzalloc(sizeof(*cli), GFP_KERNEL))) {
+ ret = -ENOMEM;
+ goto done;
+ }
ret = nouveau_cli_init(drm, name, cli);
if (ret)
[PATCH 4.14 137/173] sched/fair: Fix util_avg of new tasks for asymmetric systems
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Quentin Perret
[ Upstream commit 8fe5c5a937d0f4e84221631833a2718afde52285 ]
When a new task wakes-up for the first time, its initial utilization
is set to half of the spare capacity of its CPU. The current
implementation of post_init_entity_util_avg() uses SCHED_CAPACITY_SCALE
directly as a capacity reference. As a result, on a big.LITTLE system, a
new task waking up on an idle little CPU will be given ~512 of util_avg,
even if the CPU's capacity is significantly less than that.
Fix this by computing the spare capacity with arch_scale_cpu_capacity().
Signed-off-by: Quentin Perret
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Vincent Guittot
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: dietmar.eggem...@arm.com
Cc: morten.rasmus...@arm.com
Cc: patrick.bell...@arm.com
Link: http://lkml.kernel.org/r/20180612112215.25448-1-quentin.per...@arm.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
kernel/sched/fair.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -757,11 +757,12 @@ static void attach_entity_cfs_rq(struct
* To solve this problem, we also cap the util_avg of successive tasks to
* only 1/2 of the left utilization budget:
*
- * util_avg_cap = (1024 - cfs_rq->avg.util_avg) / 2^n
+ * util_avg_cap = (cpu_scale - cfs_rq->avg.util_avg) / 2^n
*
- * where n denotes the nth task.
+ * where n denotes the nth task and cpu_scale the CPU capacity.
*
- * For example, a simplest series from the beginning would be like:
+ * For example, for a CPU with 1024 of capacity, a simplest series from
+ * the beginning would be like:
*
* task util_avg: 512, 256, 128, 64, 32, 16,8, ...
* cfs_rq util_avg: 512, 768, 896, 960, 992, 1008, 1016, ...
@@ -773,7 +774,8 @@ void post_init_entity_util_avg(struct sc
{
struct cfs_rq *cfs_rq = cfs_rq_of(se);
struct sched_avg *sa = >avg;
- long cap = (long)(SCHED_CAPACITY_SCALE - cfs_rq->avg.util_avg) / 2;
+ long cpu_scale = arch_scale_cpu_capacity(NULL, cpu_of(rq_of(cfs_rq)));
+ long cap = (long)(cpu_scale - cfs_rq->avg.util_avg) / 2;
if (cap > 0) {
if (cfs_rq->avg.util_avg != 0) {
[PATCH 4.18 066/235] staging: bcm2835-camera: fix timeout handling in wait_for_completion_timeout
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit b7afce51d95726a619743aaad8870db66dfa1479 ]
wait_for_completion_timeout returns unsigned long not int so a variable of
proper type is introduced. Further the check for <= 0 is ambiguous and should
be == 0 here indicating timeout which is the only error case so no additional
check needed here.
Signed-off-by: Nicholas Mc Guire
Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera
driver.")
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -630,6 +630,7 @@ static int send_synchronous_mmal_msg(str
{
struct mmal_msg_context *msg_context;
int ret;
+ unsigned long timeout;
/* payload size must not cause message to exceed max size */
if (payload_len >
@@ -668,11 +669,11 @@ static int send_synchronous_mmal_msg(str
return ret;
}
- ret = wait_for_completion_timeout(_context->u.sync.cmplt, 3 * HZ);
- if (ret <= 0) {
- pr_err("error %d waiting for sync completion\n", ret);
- if (ret == 0)
- ret = -ETIME;
+ timeout = wait_for_completion_timeout(_context->u.sync.cmplt,
+ 3 * HZ);
+ if (timeout == 0) {
+ pr_err("timed out waiting for sync completion\n");
+ ret = -ETIME;
/* todo: what happens if the message arrives after aborting */
release_msg_context(msg_context);
return ret;
[PATCH 4.18 064/235] powerpc/powernv: opal_put_chars partial write fix
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Piggin
[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]
The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.
This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.
Reviewed-by: Benjamin Herrenschmidt
Signed-off-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/platforms/powernv/opal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -388,7 +388,7 @@ int opal_put_chars(uint32_t vtermno, con
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
- written = total_len;
+ written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
[PATCH 4.18 068/235] ASoC: rt5514: Fix the issue of the delay volume applied
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Oder Chiou
[ Upstream commit d96f8bd28cd0bae3e6702ae90df593628ef6906f ]
The patch fixes the issue of the delay volume applied.
Signed-off-by: Oder Chiou
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/codecs/rt5514.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/sound/soc/codecs/rt5514.c
+++ b/sound/soc/codecs/rt5514.c
@@ -64,8 +64,8 @@ static const struct reg_sequence rt5514_
{RT5514_ANA_CTRL_LDO10, 0x00028604},
{RT5514_ANA_CTRL_ADCFED,0x0800},
{RT5514_ASRC_IN_CTRL1, 0x0003},
- {RT5514_DOWNFILTER0_CTRL3, 0x1362},
- {RT5514_DOWNFILTER1_CTRL3, 0x1362},
+ {RT5514_DOWNFILTER0_CTRL3, 0x1352},
+ {RT5514_DOWNFILTER1_CTRL3, 0x1352},
};
static const struct reg_default rt5514_reg[] = {
@@ -92,10 +92,10 @@ static const struct reg_default rt5514_r
{RT5514_ASRC_IN_CTRL1, 0x0003},
{RT5514_DOWNFILTER0_CTRL1, 0x00020c2f},
{RT5514_DOWNFILTER0_CTRL2, 0x00020c2f},
- {RT5514_DOWNFILTER0_CTRL3, 0x1362},
+ {RT5514_DOWNFILTER0_CTRL3, 0x1352},
{RT5514_DOWNFILTER1_CTRL1, 0x00020c2f},
{RT5514_DOWNFILTER1_CTRL2, 0x00020c2f},
- {RT5514_DOWNFILTER1_CTRL3, 0x1362},
+ {RT5514_DOWNFILTER1_CTRL3, 0x1352},
{RT5514_ANA_CTRL_LDO10, 0x00028604},
{RT5514_ANA_CTRL_LDO18_16, 0x02000345},
{RT5514_ANA_CTRL_ADC12, 0xa2a8},
[PATCH 4.18 067/235] staging: bcm2835-camera: handle wait_for_completion_timeout return properly
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Mc Guire
[ Upstream commit 5b70084f6cbcd53f615433f9d216e01bd71de0bb ]
wait_for_completion_timeout returns unsigned long not int so a variable of
proper type is introduced. Further the check for <= 0 is ambiguous and
should be == 0 here indicating timeout.
Signed-off-by: Nicholas Mc Guire
Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera
driver.")
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -580,6 +580,7 @@ static int start_streaming(struct vb2_qu
static void stop_streaming(struct vb2_queue *vq)
{
int ret;
+ unsigned long timeout;
struct bm2835_mmal_dev *dev = vb2_get_drv_priv(vq);
v4l2_dbg(1, bcm2835_v4l2_debug, >v4l2_dev, "%s: dev:%p\n",
@@ -605,10 +606,10 @@ static void stop_streaming(struct vb2_qu
sizeof(dev->capture.frame_count));
/* wait for last frame to complete */
- ret = wait_for_completion_timeout(>capture.frame_cmplt, HZ);
- if (ret <= 0)
+ timeout = wait_for_completion_timeout(>capture.frame_cmplt, HZ);
+ if (timeout == 0)
v4l2_err(>v4l2_dev,
-"error %d waiting for frame completion\n", ret);
+"timed out waiting for frame completion\n");
v4l2_dbg(1, bcm2835_v4l2_debug, >v4l2_dev,
"disabling connection\n");
[PATCH 4.18 065/235] perf script: Show correct offsets for DWARF-based unwinding
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Sandipan Das
[ Upstream commit 2a9d5050dc84fa2060f08a52f632976923e0fa7e ]
When perf/data is recorded with the dwarf call-graph option, the
callchain shown by 'perf script' still shows the binary offsets of the
userspace symbols instead of their virtual addresses. Since the symbol
offset calculation is based on using virtual address as the ip, we see
incorrect offsets as well.
The use of virtual addresses affects the ability to find out the
line number in the corresponding source file to which an address
maps to as described in commit 67540759151a ("perf unwind: Use
addr_location::addr instead of ip for entries").
This has also been addressed by temporarily converting the virtual
address to the correponding binary offset so that it can be mapped
to the source line number correctly.
This is a follow-up for commit 19610184693c ("perf script: Show
virtual addresses instead of offsets").
This can be verified on a powerpc64le system running Fedora 27 as
shown below:
# perf probe -x /usr/lib64/libc-2.26.so -a inet_pton
# perf record -e probe_libc:inet_pton --call-graph=dwarf ping -6 -c 1 ::1
Before:
# perf report --stdio --no-children -s sym,srcline -g address
# Samples: 1 of event 'probe_libc:inet_pton'
# Event count (approx.): 1
#
# Overhead SymbolSource:Line
# ...
#
100.00% [.] __GI___inet_pton inet_pton.c
|
---gaih_inet getaddrinfo.c:537 (inlined)
__GI_getaddrinfo getaddrinfo.c:2304 (inlined)
main ping.c:519
generic_start_main libc-start.c:308 (inlined)
__libc_start_main libc-start.c:102
...
# perf script -F comm,ip,sym,symoff,srcline,dso
ping
15af28 __GI___inet_pton+0x99160008
(/usr/lib64/libc-2.26.so)
libc-2.26.so[80004ca0af28]
10fa53 gaih_inet+0x99160f43
libc-2.26.so[80004c9bfa53] (inlined)
1105b3 __GI_getaddrinfo+0x99160163
libc-2.26.so[80004c9c05b3] (inlined)
2d6f main+0xfffd9f1003df (/usr/bin/ping)
ping[fffecf882d6f]
2369f generic_start_main+0x9916013f
libc-2.26.so[80004c8d369f] (inlined)
23897 __libc_start_main+0x991600b7
(/usr/lib64/libc-2.26.so)
libc-2.26.so[80004c8d3897]
After:
# perf report --stdio --no-children -s sym,srcline -g address
# Samples: 1 of event 'probe_libc:inet_pton'
# Event count (approx.): 1
#
# Overhead SymbolSource:Line
# ...
#
100.00% [.] __GI___inet_pton inet_pton.c
|
---gaih_inet.constprop.7 getaddrinfo.c:537
getaddrinfo getaddrinfo.c:2304
main ping.c:519
generic_start_main.isra.0 libc-start.c:308
__libc_start_main libc-start.c:102
...
# perf script -F comm,ip,sym,symoff,srcline,dso
ping
7fffb38aaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
inet_pton.c:68
7fffb385fa53 gaih_inet.constprop.7+0xf43 (/usr/lib64/libc-2.26.so)
getaddrinfo.c:537
7fffb38605b3 getaddrinfo+0x163 (/usr/lib64/libc-2.26.so)
getaddrinfo.c:2304
130782d6f main+0x3df (/usr/bin/ping)
ping.c:519
7fffb377369f generic_start_main.isra.0+0x13f
(/usr/lib64/libc-2.26.so)
libc-start.c:308
7fffb3773897 __libc_start_main+0xb7 (/usr/lib64/libc-2.26.so)
libc-start.c:102
Signed-off-by: Sandipan Das
Acked-by: Jiri Olsa
Cc: Milian Wolff
Cc: Namhyung Kim
Cc: Naveen N. Rao
Cc: Ravi Bangoria
Fixes: 67540759151a ("perf unwind: Use addr_location::addr instead of ip for
entries")
Link: http://lkml.kernel.org/r/20180703120555.32971-1-sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/machine.c|9 -
tools/perf/util/unwind-libdw.c |2 +-
tools/perf/util/unwind-libunwind-local.c |2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2272,6 +2272,7 @@ static int unwind_entry(struct unwind_en
{
struct callchain_cursor *cursor = arg;
const char *srcline = NULL;
+ u64 addr;
if (symbol_conf.hide_unresolved && entry->sym == NULL)
return 0;
@@ -2279,7 +2280,13 @@ static int unwind_entry(struct unwind_en
if (append_inlines(cursor, entry->map, entry->sym, entry->ip) == 0)
return 0;
- srcline = callchain_srcline(entry->map, entry->sym, entry->ip);
+ /*
+* Convert entry->ip from a virtual address to an offset in
+* its
[PATCH 4.18 078/235] xen-netfront: fix queue name setting
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Vitaly Kuznetsov
[ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]
Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up with the following in
/proc/interrupts:
60:139 0 xen-dyn-event eth%d-q0-tx
61:265 0 xen-dyn-event eth%d-q0-rx
62:234 0 xen-dyn-event eth%d-q1-tx
63: 1 0 xen-dyn-event eth%d-q1-rx
and this looks ugly. Actually, using early netdev name (even when it's
already set) is also not ideal: nowadays we tend to rename eth devices
and queue name may end up not corresponding to the netdev name.
Use nodename from xenbus device for queue naming: this can't change in VM's
lifetime. Now /proc/interrupts looks like
62:202 0 xen-dyn-event device/vif/0-q0-tx
63:317 0 xen-dyn-event device/vif/0-q0-rx
64:262 0 xen-dyn-event device/vif/0-q1-tx
65: 17 0 xen-dyn-event device/vif/0-q1-rx
Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Ross Lagerwall
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netfront.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1610,7 +1610,7 @@ static int xennet_init_queue(struct netf
timer_setup(>rx_refill_timer, rx_refill_timeout, 0);
snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-queue->info->netdev->name, queue->id);
+queue->info->xbdev->nodename, queue->id);
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
[PATCH 4.18 074/235] reset: imx7: Fix always writing bits as 0
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Leonard Crestez
[ Upstream commit 26fce0557fa639fb7bbc33e31a57cff7df25c3a0 ]
Right now the only user of reset-imx7 is pci-imx6 and the
reset_control_assert and deassert calls on pciephy_reset don't toggle
the PCIEPHY_BTN and PCIEPHY_G_RST bits as expected. Fix this by writing
1 or 0 respectively.
The reference manual is not very clear regarding SRC_PCIEPHY_RCR but for
other registers like MIPIPHY and HSICPHY the bits are explicitly
documented as "1 means assert, 0 means deassert".
The values are still reversed for IMX7_RESET_PCIE_CTRL_APPS_EN.
Signed-off-by: Leonard Crestez
Reviewed-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/reset/reset-imx7.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -80,7 +80,7 @@ static int imx7_reset_set(struct reset_c
{
struct imx7_src *imx7src = to_imx7_src(rcdev);
const struct imx7_src_signal *signal = _src_signals[id];
- unsigned int value = 0;
+ unsigned int value = assert ? signal->bit : 0;
switch (id) {
case IMX7_RESET_PCIEPHY:
[PATCH 4.18 075/235] efi/arm: preserve early mapping of UEFI memory map longer for BGRT
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Ard Biesheuvel
[ Upstream commit 3ea86495aef2f6de26b7cb1599ba350dd6a0c521 ]
The BGRT code validates the contents of the table against the UEFI
memory map, and so it expects it to be mapped when the code runs.
On ARM, this is currently not the case, since we tear down the early
mapping after efi_init() completes, and only create the permanent
mapping in arm_enable_runtime_services(), which executes as an early
initcall, but still leaves a window where the UEFI memory map is not
mapped.
So move the call to efi_memmap_unmap() from efi_init() to
arm_enable_runtime_services().
Signed-off-by: Ard Biesheuvel
[will: fold in EFI_MEMMAP attribute check from Ard]
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/firmware/efi/arm-init.c|1 -
drivers/firmware/efi/arm-runtime.c |4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
reserve_regions();
efi_esrt_init();
- efi_memmap_unmap();
memblock_reserve(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -110,11 +110,13 @@ static int __init arm_enable_runtime_ser
{
u64 mapsize;
- if (!efi_enabled(EFI_BOOT)) {
+ if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
pr_info("EFI services will not be available.\n");
return 0;
}
+ efi_memmap_unmap();
+
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
return 0;
[PATCH 4.18 043/235] mtd/maps: fix solutionengine.c printk format warnings
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]
Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".
Fixes these build warnings:
../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x
Cc: David Woodhouse
Cc: Brian Norris
Cc: Boris Brezillon
Cc: Marek Vasut
Cc: Richard Weinberger
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov
Signed-off-by: Randy Dunlap
Signed-off-by: Boris Brezillon
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/maps/solutionengine.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
- printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at
0x%08lx\n",
- soleng_flash_map.phys & 0x1fff,
- soleng_eprom_map.phys & 0x1fff);
+ printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at
0x%pap\n",
+ _flash_map.phys,
+ _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
eprom_mtd = do_map_probe("map_rom", _eprom_map);
[PATCH 4.18 077/235] nfp: avoid buffer leak when FW communication fails
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jakub Kicinski
[ Upstream commit 07300f774fec9519663a597987a4083225588be4 ]
After device is stopped we reset the rings by moving all free buffers
to positions [0, cnt - 2], and clear the position cnt - 1 in the ring.
We then proceed to clear the read/write pointers. This means that if
we try to reset the ring again the code will assume that the next to
fill buffer is at position 0 and swap it with cnt - 1. Since we
previously cleared position cnt - 1 it will lead to leaking the first
buffer and leaving ring in a bad state.
This scenario can only happen if FW communication fails, in which case
the ring will never be used again, so the fact it's in a bad state will
not be noticed. Buffer leak is the only problem. Don't try to move
buffers in the ring if the read/write pointers indicate the ring was
never used or have already been reset.
nfp_net_clear_config_and_disable() is now fully idempotent.
Found by code inspection, FW communication failures are very rare,
and reconfiguring a live device is not common either, so it's unlikely
anyone has ever noticed the leak.
Signed-off-by: Jakub Kicinski
Reviewed-by: Dirk van der Merwe
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -1093,7 +1093,7 @@ static bool nfp_net_xdp_complete(struct
* @dp:NFP Net data path struct
* @tx_ring: TX ring structure
*
- * Assumes that the device is stopped
+ * Assumes that the device is stopped, must be idempotent.
*/
static void
nfp_net_tx_ring_reset(struct nfp_net_dp *dp, struct nfp_net_tx_ring *tx_ring)
@@ -1295,13 +1295,18 @@ static void nfp_net_rx_give_one(const st
* nfp_net_rx_ring_reset() - Reflect in SW state of freelist after disable
* @rx_ring: RX ring structure
*
- * Warning: Do *not* call if ring buffers were never put on the FW freelist
- * (i.e. device was not enabled)!
+ * Assumes that the device is stopped, must be idempotent.
*/
static void nfp_net_rx_ring_reset(struct nfp_net_rx_ring *rx_ring)
{
unsigned int wr_idx, last_idx;
+ /* wr_p == rd_p means ring was never fed FL bufs. RX rings are always
+* kept at cnt - 1 FL bufs.
+*/
+ if (rx_ring->wr_p == 0 && rx_ring->rd_p == 0)
+ return;
+
/* Move the empty entry to the end of the list */
wr_idx = D_IDX(rx_ring, rx_ring->wr_p);
last_idx = rx_ring->cnt - 1;
@@ -2524,6 +2529,8 @@ static void nfp_net_vec_clear_ring_data(
/**
* nfp_net_clear_config_and_disable() - Clear control BAR and disable NFP
* @nn: NFP Net device to reconfigure
+ *
+ * Warning: must be fully idempotent.
*/
static void nfp_net_clear_config_and_disable(struct nfp_net *nn)
{
[PATCH 4.18 046/235] gfs2: Dont reject a supposedly full bitmap if we have blocks reserved
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Bob Peterson
[ Upstream commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4 ]
Before this patch, you could get into situations like this:
1. Process 1 searches for X free blocks, finds them, makes a reservation
2. Process 2 searches for free blocks in the same rgrp, but now the
bitmap is full because process 1's reservation is skipped over.
So it marks the bitmap as GBF_FULL.
3. Process 1 tries to allocate blocks from its own reservation, but
since the GBF_FULL bit is set, it skips over the rgrp and searches
elsewhere, thus not using its own reservation.
This patch adds an additional check to allow processes to use their
own reservations.
Signed-off-by: Bob Peterson
Signed-off-by: Andreas Gruenbacher
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/gfs2/rgrp.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1686,7 +1686,8 @@ static int gfs2_rbm_find(struct gfs2_rbm
while(1) {
bi = rbm_bi(rbm);
- if (test_bit(GBF_FULL, >bi_flags) &&
+ if ((ip == NULL || !gfs2_rs_active(>i_res)) &&
+ test_bit(GBF_FULL, >bi_flags) &&
(state == GFS2_BLKST_FREE))
goto next_bitmap;
[PATCH 4.18 076/235] ALSA: usb-audio: Generic DSD detection for Thesycon-based implementations
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Yue Wang
[ Upstream commit 1ea0358ecb848058b35b6da13d7f4c08610a73a8 ]
Thesycon provides solutions to XMOS chips, and has its own device
vendor id.
In this patch, we use generic method to detect DSD capability of
Thesycon-based UAC2 implementations in order to support a wide range
of current and future devices.
The patch will enable the SNDRV_PCM_FMTBIT_DSD_U32_BE bit for the DAC
hence enable native DSD playback up to DSD512 format.
Signed-off-by: Yue Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
sound/usb/quirks.c |1 +
1 file changed, 1 insertion(+)
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1444,6 +1444,7 @@ u64 snd_usb_interface_dsd_format_quirks(
*/
switch (USB_ID_VENDOR(chip->usb_id)) {
case 0x20b1: /* XMOS based devices */
+ case 0x152a: /* Thesycon devices */
case 0x25ce: /* Mytek devices */
if (fp->dsd_raw)
return SNDRV_PCM_FMTBIT_DSD_U32_BE;
