]> git.proxmox.com Git - mirror_ubuntu-eoan-kernel.git/log
mirror_ubuntu-eoan-kernel.git
4 years agoALSA: hda/hdmi - Don't report spurious jack state changes
Takashi Iwai [Wed, 17 Jul 2019 12:30:23 +0000 (14:30 +0200)]
ALSA: hda/hdmi - Don't report spurious jack state changes

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 551626ec0ad28dc43cae3094c35be7088cc625ab ]

The HDMI jack handling reports the state change always via
snd_jack_report() whenever hdmi_present_sense() is called, even if the
state itself doesn't change from the previous time.  This is mostly
harmless but still a bit confusing to user-space.

This patch reduces such spurious jack state changes and reports only
when the state really changed.  Also, as a minor optimization, avoid
overwriting the pin ELD data when the state is identical.

Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agocpufreq: ap806: Add NULL check after kcalloc
Hariprasad Kelam [Sun, 21 Jul 2019 18:08:15 +0000 (23:38 +0530)]
cpufreq: ap806: Add NULL check after kcalloc

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 3355c91b79394593ebbb197c8e930a91826f4ff3 ]

Add NULL check  after kcalloc.

Fix below issue reported by coccicheck
./drivers/cpufreq/armada-8k-cpufreq.c:138:1-12: alloc with no test,
possible model on line 151

Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoASoC: SOF: Intel: hda: Make hdac_device device-managed
Ranjani Sridharan [Wed, 26 Jun 2019 07:04:50 +0000 (00:04 -0700)]
ASoC: SOF: Intel: hda: Make hdac_device device-managed

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit ef9bec27485fefb6b93168fea73fda0dc9638046 ]

snd_hdac_ext_bus_device_exit() has been recently modified
to no longer free the hdac device. SOF allocates memory for
hdac_device and hda_hda_priv with kzalloc. Make them
device-managed instead so that they will be freed when the
SOF driver is unloaded.

Because of the above change, hda_codec is device-managed and
it will be freed when the ASoC device is removed. Freeing
the codec in snd_hda_codec_dev_release() leads to kernel
panic while unloading and reloading the ASoC driver. So,
avoid freeing the hda_codec for ASoC driver. This is done in
the same patch to avoid bisect failure.

Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190626070450.7229-1-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoALSA: hda: Flush interrupts on disabling
Chris Wilson [Sat, 20 Jul 2019 11:33:37 +0000 (12:33 +0100)]
ALSA: hda: Flush interrupts on disabling

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit caa8422d01e983782548648e125fd617cadcec3f ]

I was looking at

<4> [241.835158] general protection fault: 0000 [#1] PREEMPT SMP PTI
<4> [241.835181] CPU: 1 PID: 214 Comm: kworker/1:3 Tainted: G     U            5.2.0-CI-CI_DRM_6509+ #1
<4> [241.835199] Hardware name: Dell Inc.                 OptiPlex 745                 /0GW726, BIOS 2.3.1  05/21/2007
<4> [241.835234] Workqueue: events snd_hdac_bus_process_unsol_events [snd_hda_core]
<4> [241.835256] RIP: 0010:input_handle_event+0x16d/0x5e0
<4> [241.835270] Code: 48 8b 93 58 01 00 00 8b 52 08 89 50 04 8b 83 f8 06 00 00 48 8b 93 00 07 00 00 8d 70 01 48 8d 04 c2 83 e1 08 89 b3 f8 06 00 00 <66> 89 28 66 44 89 60 02 44 89 68 04 8b 93 f8 06 00 00 0f 84 fd fe
<4> [241.835304] RSP: 0018:ffffc9000019fda0 EFLAGS: 00010046
<4> [241.835317] RAX: 6b6b6b6ec6c6c6c3 RBX: ffff8880290fefc8 RCX: 0000000000000000
<4> [241.835332] RDX: 000000006b6b6b6b RSI: 000000006b6b6b6c RDI: 0000000000000046
<4> [241.835347] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000001
<4> [241.835362] R10: ffffc9000019faa0 R11: 0000000000000000 R12: 0000000000000004
<4> [241.835377] R13: 0000000000000000 R14: ffff8880290ff1d0 R15: 0000000000000293
<4> [241.835392] FS:  0000000000000000(0000) GS:ffff88803de80000(0000) knlGS:0000000000000000
<4> [241.835409] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [241.835422] CR2: 00007ffe9a99e9b7 CR3: 000000002f588000 CR4: 00000000000006e0
<4> [241.835436] Call Trace:
<4> [241.835449]  input_event+0x45/0x70
<4> [241.835464]  snd_jack_report+0xdc/0x100
<4> [241.835490]  snd_hda_jack_report_sync+0x83/0xc0 [snd_hda_codec]
<4> [241.835512]  snd_hdac_bus_process_unsol_events+0x5a/0x70 [snd_hda_core]
<4> [241.835530]  process_one_work+0x245/0x610

which has the hallmarks of a worker queued from interrupt after it was
supposedly cancelled (note the POISON_FREE), and I could not see where
the interrupt would be flushed on shutdown so added the likely suspects.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111174
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet/mlx5: Add device ID of upcoming BlueField-2
Bodong Wang [Mon, 26 Aug 2019 21:34:12 +0000 (16:34 -0500)]
net/mlx5: Add device ID of upcoming BlueField-2

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit d19a79ee38c8fda6d297e4227e80db8bf51c71a6 ]

Add the device ID of upcoming BlueField-2 integrated ConnectX-6 Dx
network controller. Its VFs will be using the generic VF device ID:
0x101e "ConnectX Family mlx5Gen Virtual Function".

Fixes: 2e9d3e83ab82 ("net/mlx5: Update the list of the PCI supported devices")
Signed-off-by: Bodong Wang <bodong@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agotcp: better handle TCP_USER_TIMEOUT in SYN_SENT state
Eric Dumazet [Thu, 26 Sep 2019 22:42:51 +0000 (15:42 -0700)]
tcp: better handle TCP_USER_TIMEOUT in SYN_SENT state

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit a66b10c05ee2d744189e9a2130394b070883d289 ]

Yuchung Cheng and Marek Majkowski independently reported a weird
behavior of TCP_USER_TIMEOUT option when used at connect() time.

When the TCP_USER_TIMEOUT is reached, tcp_write_timeout()
believes the flow should live, and the following condition
in tcp_clamp_rto_to_user_timeout() programs one jiffie timers :

    remaining = icsk->icsk_user_timeout - elapsed;
    if (remaining <= 0)
        return 1; /* user timeout has passed; fire ASAP */

This silly situation ends when the max syn rtx count is reached.

This patch makes sure we honor both TCP_SYNCNT and TCP_USER_TIMEOUT,
avoiding these spurious SYN packets.

Fixes: b701a99e431d ("tcp: Add tcp_clamp_rto_to_user_timeout() helper to improve accuracy")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Yuchung Cheng <ycheng@google.com>
Reported-by: Marek Majkowski <marek@cloudflare.com>
Cc: Jon Maxwell <jmaxwell37@gmail.com>
Link: https://marc.info/?l=linux-netdev&m=156940118307949&w=2
Acked-by: Jon Maxwell <jmaxwell37@gmail.com>
Tested-by: Marek Majkowski <marek@cloudflare.com>
Signed-off-by: Marek Majkowski <marek@cloudflare.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet: sched: fix possible crash in tcf_action_destroy()
Eric Dumazet [Wed, 18 Sep 2019 19:57:04 +0000 (12:57 -0700)]
net: sched: fix possible crash in tcf_action_destroy()

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 3d66b89c30f9220a72e92847768fc8ba4d027d88 ]

If the allocation done in tcf_exts_init() failed,
we end up with a NULL pointer in exts->actions.

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8198 Comm: syz-executor.3 Not tainted 5.3.0-rc8+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:tcf_action_destroy+0x71/0x160 net/sched/act_api.c:705
Code: c3 08 44 89 ee e8 4f cb bb fb 41 83 fd 20 0f 84 c9 00 00 00 e8 c0 c9 bb fb 48 89 d8 48 b9 00 00 00 00 00 fc ff df 48 c1 e8 03 <80> 3c 08 00 0f 85 c0 00 00 00 4c 8b 33 4d 85 f6 0f 84 9d 00 00 00
RSP: 0018:ffff888096e16ff0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000040000 RSI: ffffffff85b6ab30 RDI: 0000000000000000
RBP: ffff888096e17020 R08: ffff8880993f6140 R09: fffffbfff11cae67
R10: fffffbfff11cae66 R11: ffffffff88e57333 R12: 0000000000000000
R13: 0000000000000000 R14: ffff888096e177a0 R15: 0000000000000001
FS:  00007f62bc84a700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000758040 CR3: 0000000088b64000 CR4: 00000000001426e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 tcf_exts_destroy+0x38/0xb0 net/sched/cls_api.c:3030
 tcindex_set_parms+0xf7f/0x1e50 net/sched/cls_tcindex.c:488
 tcindex_change+0x230/0x318 net/sched/cls_tcindex.c:519
 tc_new_tfilter+0xa4b/0x1c70 net/sched/cls_api.c:2152
 rtnetlink_rcv_msg+0x838/0xb00 net/core/rtnetlink.c:5214
 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241
 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
 netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
 netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
 sock_sendmsg_nosec net/socket.c:637 [inline]
 sock_sendmsg+0xd7/0x130 net/socket.c:657
 ___sys_sendmsg+0x3e2/0x920 net/socket.c:2311
 __sys_sendmmsg+0x1bf/0x4d0 net/socket.c:2413
 __do_sys_sendmmsg net/socket.c:2442 [inline]

Fixes: 90b73b77d08e ("net: sched: change action API to use array of pointers to actions")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Vlad Buslov <vladbu@mellanox.com>
Cc: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet/mlx5e: Fix traffic duplication in ethtool steering
Saeed Mahameed [Wed, 11 Sep 2019 14:50:13 +0000 (07:50 -0700)]
net/mlx5e: Fix traffic duplication in ethtool steering

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit d22fcc806b84b9818de08b32e494f3c05dd236c7 ]

Before this patch, when adding multiple ethtool steering rules with
identical classification, the driver used to append the new destination
to the already existing hw rule, which caused the hw to forward the
traffic to all destinations (rx queues).

Here we avoid this by setting the "no append" mlx5 fs core flag when
adding a new ethtool rule.

Fixes: 6dc6071cfcde ("net/mlx5e: Add ethtool flow steering support")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agovrf: Do not attempt to create IPv6 mcast rule if IPv6 is disabled
David Ahern [Wed, 25 Sep 2019 14:53:19 +0000 (07:53 -0700)]
vrf: Do not attempt to create IPv6 mcast rule if IPv6 is disabled

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit dac91170f8e9c73784af5fad6225e954b795601c ]

A user reported that vrf create fails when IPv6 is disabled at boot using
'ipv6.disable=1':
   https://bugzilla.kernel.org/show_bug.cgi?id=204903

The failure is adding fib rules at create time. Add RTNL_FAMILY_IP6MR to
the check in vrf_fib_rule if ipv6_mod_enabled is disabled.

Fixes: e4a38c0c4b27 ("ipv6: add vrf table handling code for ipv6 mcast")
Signed-off-by: David Ahern <dsahern@gmail.com>
Cc: Patrick Ruddy <pruddy@vyatta.att-mail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet_sched: add policy validation for action attributes
Cong Wang [Thu, 19 Sep 2019 01:44:43 +0000 (18:44 -0700)]
net_sched: add policy validation for action attributes

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 199ce850ce112315cfc68d42b694bcaa27b097b7 ]

Similar to commit 8b4c3cdd9dd8
("net: sched: Add policy validation for tc attributes"), we need
to add proper policy validation for TC action attributes too.

Cc: David Ahern <dsahern@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoipv4: Revert removal of rt_uses_gateway
David Ahern [Tue, 17 Sep 2019 17:39:49 +0000 (10:39 -0700)]
ipv4: Revert removal of rt_uses_gateway

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 77d5bc7e6a6cf8bbeca31aab7f0c5449a5eee762 ]

Julian noted that rt_uses_gateway has a more subtle use than 'is gateway
set':
    https://lore.kernel.org/netdev/alpine.LFD.2.21.1909151104060.2546@ja.home.ssi.bg/

Revert that part of the commit referenced in the Fixes tag.

Currently, there are no u8 holes in 'struct rtable'. There is a 4-byte hole
in the second cacheline which contains the gateway declaration. So move
rt_gw_family down to the gateway declarations since they are always used
together, and then re-use that u8 for rt_uses_gateway. End result is that
rtable size is unchanged.

Fixes: 1550c171935d ("ipv4: Prepare rtable for IPv6 gateway")
Reported-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David Ahern <dsahern@gmail.com>
Reviewed-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet/sched: cbs: Fix not adding cbs instance to list
Vinicius Costa Gomes [Tue, 24 Sep 2019 05:04:58 +0000 (22:04 -0700)]
net/sched: cbs: Fix not adding cbs instance to list

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 3e8b9bfa110896f95d602d8c98d5f9d67e41d78c ]

When removing a cbs instance when offloading is enabled, the crash
below can be observed.

The problem happens because that when offloading is enabled, the cbs
instance is not added to the list.

Also, the current code doesn't handle correctly the case when offload
is disabled without removing the qdisc: if the link speed changes the
credit calculations will be wrong. When we create the cbs instance
with offloading enabled, it's not added to the notification list, when
later we disable offloading, it's not in the list, so link speed
changes will not affect it.

The solution for both issues is the same, add the cbs instance being
created unconditionally to the global list, even if the link state
notification isn't useful "right now".

Crash log:

[518758.189866] BUG: kernel NULL pointer dereference, address: 0000000000000000
[518758.189870] #PF: supervisor read access in kernel mode
[518758.189871] #PF: error_code(0x0000) - not-present page
[518758.189872] PGD 0 P4D 0
[518758.189874] Oops: 0000 [#1] SMP PTI
[518758.189876] CPU: 3 PID: 4825 Comm: tc Not tainted 5.2.9 #1
[518758.189877] Hardware name: Gigabyte Technology Co., Ltd. Z390 AORUS ULTRA/Z390 AORUS ULTRA-CF, BIOS F7 03/14/2019
[518758.189881] RIP: 0010:__list_del_entry_valid+0x29/0xa0
[518758.189883] Code: 90 48 b8 00 01 00 00 00 00 ad de 55 48 8b 17 4c 8b 47 08 48 89 e5 48 39 c2 74 27 48 b8 00 02 00 00 00 00 ad de 49 39 c0 74 2d <49> 8b 30 48 39 fe 75 3d 48 8b 52 08 48 39 f2 75 4c b8 01 00 00 00
[518758.189885] RSP: 0018:ffffa27e43903990 EFLAGS: 00010207
[518758.189887] RAX: dead000000000200 RBX: ffff8bce69f0f000 RCX: 0000000000000000
[518758.189888] RDX: 0000000000000000 RSI: ffff8bce69f0f064 RDI: ffff8bce69f0f1e0
[518758.189890] RBP: ffffa27e43903990 R08: 0000000000000000 R09: ffff8bce69e788c0
[518758.189891] R10: ffff8bce62acd400 R11: 00000000000003cb R12: ffff8bce69e78000
[518758.189892] R13: ffff8bce69f0f140 R14: 0000000000000000 R15: 0000000000000000
[518758.189894] FS:  00007fa1572c8f80(0000) GS:ffff8bce6e0c0000(0000) knlGS:0000000000000000
[518758.189895] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[518758.189896] CR2: 0000000000000000 CR3: 000000040a398006 CR4: 00000000003606e0
[518758.189898] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[518758.189899] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[518758.189900] Call Trace:
[518758.189904]  cbs_destroy+0x32/0xa0 [sch_cbs]
[518758.189906]  qdisc_destroy+0x45/0x120
[518758.189907]  qdisc_put+0x25/0x30
[518758.189908]  qdisc_graft+0x2c1/0x450
[518758.189910]  tc_get_qdisc+0x1c8/0x310
[518758.189912]  ? get_page_from_freelist+0x91a/0xcb0
[518758.189914]  rtnetlink_rcv_msg+0x293/0x360
[518758.189916]  ? kmem_cache_alloc_node_trace+0x178/0x260
[518758.189918]  ? __kmalloc_node_track_caller+0x38/0x50
[518758.189920]  ? rtnl_calcit.isra.0+0xf0/0xf0
[518758.189922]  netlink_rcv_skb+0x48/0x110
[518758.189923]  rtnetlink_rcv+0x10/0x20
[518758.189925]  netlink_unicast+0x15b/0x1d0
[518758.189926]  netlink_sendmsg+0x1ea/0x380
[518758.189929]  sock_sendmsg+0x2f/0x40
[518758.189930]  ___sys_sendmsg+0x295/0x2f0
[518758.189932]  ? ___sys_recvmsg+0x151/0x1e0
[518758.189933]  ? do_wp_page+0x7e/0x450
[518758.189935]  __sys_sendmsg+0x48/0x80
[518758.189937]  __x64_sys_sendmsg+0x1a/0x20
[518758.189939]  do_syscall_64+0x53/0x1f0
[518758.189941]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[518758.189942] RIP: 0033:0x7fa15755169a
[518758.189944] Code: 48 c7 c0 ff ff ff ff eb be 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 18 b8 2e 00 00 00 c5 fc 77 0f 05 <48> 3d 00 f0 ff ff 77 5e c3 0f 1f 44 00 00 48 83 ec 28 89 54 24 1c
[518758.189946] RSP: 002b:00007ffda58b60b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[518758.189948] RAX: ffffffffffffffda RBX: 000055e4b836d9a0 RCX: 00007fa15755169a
[518758.189949] RDX: 0000000000000000 RSI: 00007ffda58b6128 RDI: 0000000000000003
[518758.189951] RBP: 00007ffda58b6190 R08: 0000000000000001 R09: 000055e4b9d848a0
[518758.189952] R10: 0000000000000000 R11: 0000000000000246 R12: 000000005d654b49
[518758.189953] R13: 0000000000000000 R14: 00007ffda58b6230 R15: 00007ffda58b6210
[518758.189955] Modules linked in: sch_cbs sch_etf sch_mqprio netlink_diag unix_diag e1000e igb intel_pch_thermal thermal video backlight pcc_cpufreq
[518758.189960] CR2: 0000000000000000
[518758.189961] ---[ end trace 6a13f7aaf5376019 ]---
[518758.189963] RIP: 0010:__list_del_entry_valid+0x29/0xa0
[518758.189964] Code: 90 48 b8 00 01 00 00 00 00 ad de 55 48 8b 17 4c 8b 47 08 48 89 e5 48 39 c2 74 27 48 b8 00 02 00 00 00 00 ad de 49 39 c0 74 2d <49> 8b 30 48 39 fe 75 3d 48 8b 52 08 48 39 f2 75 4c b8 01 00 00 00
[518758.189967] RSP: 0018:ffffa27e43903990 EFLAGS: 00010207
[518758.189968] RAX: dead000000000200 RBX: ffff8bce69f0f000 RCX: 0000000000000000
[518758.189969] RDX: 0000000000000000 RSI: ffff8bce69f0f064 RDI: ffff8bce69f0f1e0
[518758.189971] RBP: ffffa27e43903990 R08: 0000000000000000 R09: ffff8bce69e788c0
[518758.189972] R10: ffff8bce62acd400 R11: 00000000000003cb R12: ffff8bce69e78000
[518758.189973] R13: ffff8bce69f0f140 R14: 0000000000000000 R15: 0000000000000000
[518758.189975] FS:  00007fa1572c8f80(0000) GS:ffff8bce6e0c0000(0000) knlGS:0000000000000000
[518758.189976] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[518758.189977] CR2: 0000000000000000 CR3: 000000040a398006 CR4: 00000000003606e0
[518758.189979] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[518758.189980] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Fixes: e0a7683d30e9 ("net/sched: cbs: fix port_rate miscalculation")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet: phy: micrel: add Asym Pause workaround for KSZ9021
Hans Andersson [Thu, 26 Sep 2019 07:54:37 +0000 (09:54 +0200)]
net: phy: micrel: add Asym Pause workaround for KSZ9021

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 407d8098cb1ab338199f4753162799a488d87d23 ]

The Micrel KSZ9031 PHY may fail to establish a link when the Asymmetric
Pause capability is set. This issue is described in a Silicon Errata
(DS80000691D or DS80000692D), which advises to always disable the
capability.

Micrel KSZ9021 has no errata, but has the same issue with Asymmetric Pause.
This patch apply the same workaround as the one for KSZ9031.

Fixes: 3aed3e2a143c ("net: phy: micrel: add Asym Pause workaround")
Signed-off-by: Hans Andersson <hans.andersson@cellavision.se>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoselftests: Update fib_nexthop_multiprefix to handle missing ping6
David Ahern [Tue, 17 Sep 2019 17:30:35 +0000 (10:30 -0700)]
selftests: Update fib_nexthop_multiprefix to handle missing ping6

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit e84622ce24482f6e9c1bf29d3bdd556eb587ff41 ]

Some distributions (e.g., debian buster) do not install ping6. Re-use
the hook in pmtu.sh to detect this and fallback to ping.

Fixes: 735ab2f65dce ("selftests: Add test with multiple prefixes using single nexthop")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoipv6: fix a typo in fib6_rule_lookup()
Eric Dumazet [Thu, 19 Sep 2019 17:12:36 +0000 (10:12 -0700)]
ipv6: fix a typo in fib6_rule_lookup()

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 7b09c2d052db4b4ad0b27b97918b46a7746966fa ]

Yi Ren reported an issue discovered by syzkaller, and bisected
to the cited commit.

Many thanks to Yi, this trivial patch does not reflect the patient
work that has been done.

Fixes: d64a1f574a29 ("ipv6: honor RT6_LOOKUP_F_DST_NOREF in rule lookup logic")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Wei Wang <weiwan@google.com>
Bisected-and-reported-by: Yi Ren <c4tren@gmail.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet/mlx5e: Fix matching on tunnel addresses type
Dmytro Linkin [Fri, 13 Sep 2019 10:42:21 +0000 (10:42 +0000)]
net/mlx5e: Fix matching on tunnel addresses type

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit fe1587a7de94912ed75ba5ddbfabf0741f9f8239 ]

In mlx5 parse_tunnel_attr() function dispatch on encap IP address type
is performed by directly checking flow_rule_match_key() on
FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS, and then on
FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS. However, since those are stored in
union, first check is always true if any type of encap address is set,
which leads to IPv6 tunnel encap address being parsed as IPv4 by mlx5.
Determine correct IP address type by checking control key first and if
it set, take address type from match.key->addr_type.

Fixes: d1bda7eecd88 ("net/mlx5e: Allow matching only enc_key_id/enc_dst_port for decapsulation action")
Signed-off-by: Dmytro Linkin <dmitrolin@mellanox.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Reviewed-by: Eli Britstein <elibr@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet/rds: Check laddr_check before calling it
Ka-Cheong Poon [Tue, 24 Sep 2019 15:51:16 +0000 (08:51 -0700)]
net/rds: Check laddr_check before calling it

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 05733434ee9ae6548723a808647248583e347cca ]

In rds_bind(), laddr_check is called without checking if it is NULL or
not.  And rs_transport should be reset if rds_add_bound() fails.

Fixes: c5c1a030a7db ("net/rds: An rds_sock is added too early to the hash table")
Reported-by: syzbot+fae39afd2101a17ec624@syzkaller.appspotmail.com
Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agousbnet: sanity checking of packet sizes and device mtu
Oliver Neukum [Thu, 19 Sep 2019 08:23:08 +0000 (10:23 +0200)]
usbnet: sanity checking of packet sizes and device mtu

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 280ceaed79f18db930c0cc8bb21f6493490bf29c ]

After a reset packet sizes and device mtu can change and need
to be reevaluated to calculate queue sizes.
Malicious devices can set this to zero and we divide by it.
Introduce sanity checking.

Reported-and-tested-by: syzbot+6102c120be558c885f04@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agousbnet: ignore endpoints with invalid wMaxPacketSize
Bjørn Mork [Wed, 18 Sep 2019 12:17:38 +0000 (14:17 +0200)]
usbnet: ignore endpoints with invalid wMaxPacketSize

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 8d3d7c2029c1b360f1a6b0a2fca470b57eb575c0 ]

Endpoints with zero wMaxPacketSize are not usable for transferring
data. Ignore such endpoints when looking for valid in, out and
status pipes, to make the drivers more robust against invalid and
meaningless descriptors.

The wMaxPacketSize of these endpoints are used for memory allocations
and as divisors in many usbnet minidrivers. Avoiding zero is therefore
critical.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agotcp_bbr: fix quantization code to not raise cwnd if not probing bandwidth
Kevin(Yudong) Yang [Thu, 26 Sep 2019 14:30:05 +0000 (10:30 -0400)]
tcp_bbr: fix quantization code to not raise cwnd if not probing bandwidth

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 6b3656a60f2067738d1a423328199720806f0c44 ]

There was a bug in the previous logic that attempted to ensure gain cycling
gets inflight above BDP even for small BDPs. This code correctly raised and
lowered target inflight values during the gain cycle. And this code
correctly ensured that cwnd was raised when probing bandwidth. However, it
did not correspondingly ensure that cwnd was *not* raised in this way when
*not* probing for bandwidth. The result was that small-BDP flows that were
always cwnd-bound could go for many cycles with a fixed cwnd, and not probe
or yield bandwidth at all. This meant that multiple small-BDP flows could
fail to converge in their bandwidth allocations.

Fixes: 3c346b233c68 ("tcp_bbr: fix bw probing to raise in-flight data for very small BDPs")
Signed-off-by: Kevin(Yudong) Yang <yyd@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Priyaranjan Jha <priyarjha@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoskge: fix checksum byte order
Stephen Hemminger [Fri, 20 Sep 2019 16:18:26 +0000 (18:18 +0200)]
skge: fix checksum byte order

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 5aafeb74b5bb65b34cc87c7623f9fa163a34fa3b ]

Running old skge driver on PowerPC causes checksum errors
because hardware reported 1's complement checksum is in little-endian
byte order.

Reported-by: Benoit <benoit.sansoni@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoselftests: Update fib_tests to handle missing ping6
David Ahern [Tue, 17 Sep 2019 17:30:21 +0000 (10:30 -0700)]
selftests: Update fib_tests to handle missing ping6

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 0360894a05ed52be268e3c4d40b2df9d94975fa6 ]

Some distributions (e.g., debian buster) do not install ping6. Re-use
the hook in pmtu.sh to detect this and fallback to ping.

Fixes: a0e11da78f48 ("fib_tests: Add tests for metrics on routes")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agosch_netem: fix a divide by zero in tabledist()
Eric Dumazet [Wed, 18 Sep 2019 15:05:39 +0000 (08:05 -0700)]
sch_netem: fix a divide by zero in tabledist()

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit b41d936b5ecfdb3a4abc525ce6402a6c49cffddc ]

syzbot managed to crash the kernel in tabledist() loading
an empty distribution table.

t = dist->table[rnd % dist->size];

Simply return an error when such load is attempted.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoppp: Fix memory leak in ppp_write
Takeshi Misawa [Sun, 22 Sep 2019 07:45:31 +0000 (16:45 +0900)]
ppp: Fix memory leak in ppp_write

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 4c247de564f1ff614d11b3bb5313fb70d7b9598b ]

When ppp is closing, __ppp_xmit_process() failed to enqueue skb
and skb allocated in ppp_write() is leaked.

syzbot reported :
BUG: memory leak
unreferenced object 0xffff88812a17bc00 (size 224):
  comm "syz-executor673", pid 6952, jiffies 4294942888 (age 13.040s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<00000000d110fff9>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
    [<00000000d110fff9>] slab_post_alloc_hook mm/slab.h:522 [inline]
    [<00000000d110fff9>] slab_alloc_node mm/slab.c:3262 [inline]
    [<00000000d110fff9>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
    [<000000002d616113>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
    [<000000000167fc45>] alloc_skb include/linux/skbuff.h:1055 [inline]
    [<000000000167fc45>] ppp_write+0x48/0x120 drivers/net/ppp/ppp_generic.c:502
    [<000000009ab42c0b>] __vfs_write+0x43/0xa0 fs/read_write.c:494
    [<00000000086b2e22>] vfs_write fs/read_write.c:558 [inline]
    [<00000000086b2e22>] vfs_write+0xee/0x210 fs/read_write.c:542
    [<00000000a2b70ef9>] ksys_write+0x7c/0x130 fs/read_write.c:611
    [<00000000ce5e0fdd>] __do_sys_write fs/read_write.c:623 [inline]
    [<00000000ce5e0fdd>] __se_sys_write fs/read_write.c:620 [inline]
    [<00000000ce5e0fdd>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620
    [<00000000d9d7b370>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
    [<0000000006e6d506>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fix this by freeing skb, if ppp is closing.

Fixes: 6d066734e9f0 ("ppp: avoid loop in xmit recursion detection code")
Reported-and-tested-by: syzbot+d9c8bf24e56416d7ce2c@syzkaller.appspotmail.com
Signed-off-by: Takeshi Misawa <jeliantsurux@gmail.com>
Reviewed-by: Guillaume Nault <gnault@redhat.com>
Tested-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoopenvswitch: change type of UPCALL_PID attribute to NLA_UNSPEC
Li RongQing [Tue, 24 Sep 2019 11:11:52 +0000 (19:11 +0800)]
openvswitch: change type of UPCALL_PID attribute to NLA_UNSPEC

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit ea8564c865299815095bebeb4b25bef474218e4c ]

userspace openvswitch patch "(dpif-linux: Implement the API
functions to allow multiple handler threads read upcall)"
changes its type from U32 to UNSPEC, but leave the kernel
unchanged

and after kernel 6e237d099fac "(netlink: Relax attr validation
for fixed length types)", this bug is exposed by the below
warning

[   57.215841] netlink: 'ovs-vswitchd': attribute type 5 has an invalid length.

Fixes: 5cd667b0a456 ("openvswitch: Allow each vport to have an array of 'port_id's")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonfp: flower: prevent memory leak in nfp_flower_spawn_phy_reprs
Navid Emamdoost [Wed, 25 Sep 2019 18:24:02 +0000 (13:24 -0500)]
nfp: flower: prevent memory leak in nfp_flower_spawn_phy_reprs

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 8572cea1461a006bce1d06c0c4b0575869125fa4 ]

In nfp_flower_spawn_phy_reprs, in the for loop over eth_tbl if any of
intermediate allocations or initializations fail memory is leaked.
requiered releases are added.

Fixes: b94524529741 ("nfp: flower: add per repr private data for LAG offload")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonfp: flower: fix memory leak in nfp_flower_spawn_vnic_reprs
Navid Emamdoost [Wed, 25 Sep 2019 19:05:09 +0000 (14:05 -0500)]
nfp: flower: fix memory leak in nfp_flower_spawn_vnic_reprs

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 8ce39eb5a67aee25d9f05b40b673c95b23502e3e ]

In nfp_flower_spawn_vnic_reprs in the loop if initialization or the
allocations fail memory is leaked. Appropriate releases are added.

Fixes: b94524529741 ("nfp: flower: add per repr private data for LAG offload")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet: stmmac: Fix page pool size
Thierry Reding [Mon, 23 Sep 2019 09:59:15 +0000 (11:59 +0200)]
net: stmmac: Fix page pool size

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 4f28bd956e081fc018fe9b41ffa31573f17bfb61 ]

The size of individual pages in the page pool in given by an order. The
order is the binary logarithm of the number of pages that make up one of
the pages in the pool. However, the driver currently passes the number
of pages rather than the order, so it ends up wasting quite a bit of
memory.

Fix this by taking the binary logarithm and passing that in the order
field.

Fixes: 2af6106ae949 ("net: stmmac: Introducing support for Page Pool")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet_sched: add max len check for TCA_KIND
Cong Wang [Wed, 18 Sep 2019 23:24:12 +0000 (16:24 -0700)]
net_sched: add max len check for TCA_KIND

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 62794fc4fbf52f2209dc094ea255eaef760e7d01 ]

The TCA_KIND attribute is of NLA_STRING which does not check
the NUL char. KMSAN reported an uninit-value of TCA_KIND which
is likely caused by the lack of NUL.

Change it to NLA_NUL_STRING and add a max len too.

Fixes: 8b4c3cdd9dd8 ("net: sched: Add policy validation for tc attributes")
Reported-and-tested-by: syzbot+618aacd49e8c8b8486bd@syzkaller.appspotmail.com
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet/sched: act_sample: don't push mac header on ip6gre ingress
Davide Caratti [Tue, 17 Sep 2019 09:30:55 +0000 (11:30 +0200)]
net/sched: act_sample: don't push mac header on ip6gre ingress

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 92974a1d006ad8b30d53047c70974c9e065eb7df ]

current 'sample' action doesn't push the mac header of ingress packets if
they are received by a layer 3 tunnel (like gre or sit); but it forgot to
check for gre over ipv6, so the following script:

 # tc q a dev $d clsact
 # tc f a dev $d ingress protocol ip flower ip_proto icmp action sample \
 > group 100 rate 1
 # psample -v -g 100

dumps everything, including outer header and mac, when $d is a gre tunnel
over ipv6. Fix this adding a missing label for ARPHRD_IP6GRE devices.

Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Reviewed-by: Yotam Gigi <yotam.gi@gmail.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet: qrtr: Stop rx_worker before freeing node
Bjorn Andersson [Wed, 18 Sep 2019 17:21:17 +0000 (10:21 -0700)]
net: qrtr: Stop rx_worker before freeing node

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 73f0c11d11329a0d6d205d4312b6e5d2512af7c5 ]

As the endpoint is unregistered there might still be work pending to
handle incoming messages, which will result in a use after free
scenario. The plan is to remove the rx_worker, but until then (and for
stable@) ensure that the work is stopped before the node is freed.

Fixes: bdabad3e363d ("net: Add Qualcomm IPC router")
Cc: stable@vger.kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonet/phy: fix DP83865 10 Mbps HDX loopback disable function
Peter Mamonov [Wed, 18 Sep 2019 16:27:55 +0000 (19:27 +0300)]
net/phy: fix DP83865 10 Mbps HDX loopback disable function

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit e47488b2df7f9cb405789c7f5d4c27909fc597ae ]

According to the DP83865 datasheet "the 10 Mbps HDX loopback can be
disabled in the expanded memory register 0x1C0.1". The driver erroneously
used bit 0 instead of bit 1.

Fixes: 4621bf129856 ("phy: Add file missed in previous commit.")
Signed-off-by: Peter Mamonov <pmamonov@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agomacsec: drop skb sk before calling gro_cells_receive
Xin Long [Mon, 23 Sep 2019 09:02:46 +0000 (17:02 +0800)]
macsec: drop skb sk before calling gro_cells_receive

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit ba56d8ce38c8252fff5b745db3899cf092578ede ]

Fei Liu reported a crash when doing netperf on a topo of macsec
dev over veth:

  [  448.919128] refcount_t: underflow; use-after-free.
  [  449.090460] Call trace:
  [  449.092895]  refcount_sub_and_test+0xb4/0xc0
  [  449.097155]  tcp_wfree+0x2c/0x150
  [  449.100460]  ip_rcv+0x1d4/0x3a8
  [  449.103591]  __netif_receive_skb_core+0x554/0xae0
  [  449.108282]  __netif_receive_skb+0x28/0x78
  [  449.112366]  netif_receive_skb_internal+0x54/0x100
  [  449.117144]  napi_gro_complete+0x70/0xc0
  [  449.121054]  napi_gro_flush+0x6c/0x90
  [  449.124703]  napi_complete_done+0x50/0x130
  [  449.128788]  gro_cell_poll+0x8c/0xa8
  [  449.132351]  net_rx_action+0x16c/0x3f8
  [  449.136088]  __do_softirq+0x128/0x320

The issue was caused by skb's true_size changed without its sk's
sk_wmem_alloc increased in tcp/skb_gro_receive(). Later when the
skb is being freed and the skb's truesize is subtracted from its
sk's sk_wmem_alloc in tcp_wfree(), underflow occurs.

macsec is calling gro_cells_receive() to receive a packet, which
actually requires skb->sk to be NULL. However when macsec dev is
over veth, it's possible the skb->sk is still set if the skb was
not unshared or expanded from the peer veth.

ip_rcv() is calling skb_orphan() to drop the skb's sk for tproxy,
but it is too late for macsec's calling gro_cells_receive(). So
fix it by dropping the skb's sk earlier on rx path of macsec.

Fixes: 5491e7c6b1a9 ("macsec: enable GRO and RPS on macsec devices")
Reported-by: Xiumei Mu <xmu@redhat.com>
Reported-by: Fei Liu <feliu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agocdc_ncm: fix divide-by-zero caused by invalid wMaxPacketSize
Bjørn Mork [Wed, 18 Sep 2019 12:01:46 +0000 (14:01 +0200)]
cdc_ncm: fix divide-by-zero caused by invalid wMaxPacketSize

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 3fe4b3351301660653a2bc73f2226da0ebd2b95e ]

Endpoints with zero wMaxPacketSize are not usable for transferring
data. Ignore such endpoints when looking for valid in, out and
status pipes, to make the driver more robust against invalid and
meaningless descriptors.

The wMaxPacketSize of the out pipe is used as divisor. So this change
fixes a divide-by-zero bug.

Reported-by: syzbot+ce366e2b8296e25d84f5@syzkaller.appspotmail.com
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoarcnet: provide a buffer big enough to actually receive packets
Uwe Kleine-König [Fri, 20 Sep 2019 14:08:21 +0000 (16:08 +0200)]
arcnet: provide a buffer big enough to actually receive packets

BugLink: https://bugs.launchpad.net/bugs/1848046
[ Upstream commit 108639aac35eb57f1d0e8333f5fc8c7ff68df938 ]

struct archdr is only big enough to hold the header of various types of
arcnet packets. So to provide enough space to hold the data read from
hardware provide a buffer large enough to hold a packet with maximal
size.

The problem was noticed by the stack protector which makes the kernel
oops.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoLinux 5.3.3
Greg Kroah-Hartman [Sat, 5 Oct 2019 12:48:42 +0000 (14:48 +0200)]
Linux 5.3.3

BugLink: https://bugs.launchpad.net/bugs/1848045
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoRevert "Linux 5.3.2"
Greg Kroah-Hartman [Sat, 5 Oct 2019 12:47:21 +0000 (14:47 +0200)]
Revert "Linux 5.3.2"

BugLink: https://bugs.launchpad.net/bugs/1848045
This reverts commit 9c30694424ee15cc30a23f92a913d5322b9e5bd2

That wasn't a 5.3.2 release, it was a 5.3.3 release, as the Makefile
changed, but the text in the commit message didn't.

So revert it, so we can do an "empty" 5.3.3 release, just to keep things
working properly.

Sorry for the noise :(

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoLinux 5.3.2
Greg Kroah-Hartman [Tue, 1 Oct 2019 06:25:44 +0000 (08:25 +0200)]
Linux 5.3.2

BugLink: https://bugs.launchpad.net/bugs/1848045
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoLinux 5.3.2
Greg Kroah-Hartman [Tue, 1 Oct 2019 06:24:50 +0000 (08:24 +0200)]
Linux 5.3.2

BugLink: https://bugs.launchpad.net/bugs/1848042
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoobjtool: Clobber user CFLAGS variable
Josh Poimboeuf [Thu, 29 Aug 2019 23:28:49 +0000 (18:28 -0500)]
objtool: Clobber user CFLAGS variable

BugLink: https://bugs.launchpad.net/bugs/1848042
commit f73b3cc39c84220e6dccd463b5c8279b03514646 upstream.

If the build user has the CFLAGS variable set in their environment,
objtool blindly appends to it, which can cause unexpected behavior.

Clobber CFLAGS to ensure consistent objtool compilation behavior.

Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/83a276df209962e6058fcb6c615eef9d401c21bc.1567121311.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
CC: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoplatform/x86: i2c-multi-instantiate: Derive the device name from parent
Heikki Krogerus [Fri, 20 Sep 2019 10:02:33 +0000 (13:02 +0300)]
platform/x86: i2c-multi-instantiate: Derive the device name from parent

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 24a8d78a9affb63e5ced313ccde6888fe96edc6e upstream.

When naming the new devices, instead of using the ACPI ID in
the name as base, using the parent device's name. That makes
it possible to support multiple multi-instance i2c devices
of the same type in the same system.

This fixes an issue seen on some Intel Kaby Lake based
boards:

sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-INT3515-tps6598x.0'

Fixes: 2336dfadfb1e ("platform/x86: i2c-multi-instantiate: Allow to have same slaves")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoALSA: hda - Apply AMD controller workaround for Raven platform
Takashi Iwai [Fri, 20 Sep 2019 07:30:40 +0000 (09:30 +0200)]
ALSA: hda - Apply AMD controller workaround for Raven platform

BugLink: https://bugs.launchpad.net/bugs/1848042
commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2 upstream.

It's reported that the garbled sound on HP Envy x360 13z-ag000 (Ryzen
Laptop) is fixed by the same workaround applied to other AMD chips.
Update the driver_data entry for Raven (1022:15e3) to use the newly
introduced preset, AZX_DCAPS_PRESET_AMD_SB.  Since it already contains
AZX_DCAPS_PM_RUNTIME, we can drop that bit, too.

Reported-and-tested-by: Dennis Padiernos <depadiernos@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190920073040.31764-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoALSA: hda - Add laptop imic fixup for ASUS M9V laptop
Shih-Yuan Lee (FourDollars) [Fri, 20 Sep 2019 13:40:53 +0000 (21:40 +0800)]
ALSA: hda - Add laptop imic fixup for ASUS M9V laptop

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 7b485d175631be676424aedb8cd2f66d0c93da78 upstream.

The same fixup to enable laptop imic is needed for ASUS M9V with AD1986A
codec like another HP machine.

Signed-off-by: Shih-Yuan Lee (FourDollars) <fourdollars@debian.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190920134052.GA8035@localhost
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoALSA: dice: fix wrong packet parameter for Alesis iO26
Takashi Sakamoto [Mon, 16 Sep 2019 10:18:51 +0000 (19:18 +0900)]
ALSA: dice: fix wrong packet parameter for Alesis iO26

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 3a9236e97207f2469254b4098995159b80174d95 upstream.

At higher sampling rate (e.g. 192.0 kHz), Alesis iO26 transfers 4 data
channels per data block in CIP.

Both iO14 and iO26 have the same contents in their configuration ROM.
For this reason, ALSA Dice driver attempts to distinguish them according
to the value of TX0_AUDIO register at probe callback. Although the way is
valid at lower and middle sampling rate, it's lastly invalid at higher
sampling rate because because the two models returns the same value for
read transaction to the register.

In the most cases, users just plug-in the device and ALSA dice driver
detects it. In the case, the device runs at lower sampling rate and
the driver detects expectedly. For this reason, this commit leaves the
way to detect as is.

Fixes: 28b208f600a3 ("ALSA: dice: add parameters of stream formats for models produced by Alesis")
Cc: <stable@vger.kernel.org> # v4.18+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20190916101851.30409-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoALSA: usb-audio: Add DSD support for EVGA NU Audio
Jussi Laako [Tue, 24 Sep 2019 07:11:43 +0000 (10:11 +0300)]
ALSA: usb-audio: Add DSD support for EVGA NU Audio

BugLink: https://bugs.launchpad.net/bugs/1848042
commit f41f900568d9ffd896cc941db7021eb14bd55910 upstream.

EVGA NU Audio is actually a USB audio device on a PCIexpress card,
with it's own USB controller. It supports both PCM and DSD.

Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190924071143.30911-1-jussi@sonarnerd.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoALSA: usb-audio: Add Hiby device family to quirks for native DSD support
Ilya Pshonkin [Tue, 17 Sep 2019 07:49:34 +0000 (10:49 +0300)]
ALSA: usb-audio: Add Hiby device family to quirks for native DSD support

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 029d2c0fd61eac74700fb4ffff36fc63bfff7e5e upstream.

This patch adds quirk VID ID for Hiby portable players family with
native DSD playback support.

Signed-off-by: Ilya Pshonkin <sudokamikaze@protonmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190917074937.157802-1-ilya.pshonkin@netforce.ua
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoRevert "mm/z3fold.c: fix race between migration and destruction"
Vitaly Wool [Mon, 23 Sep 2019 22:32:56 +0000 (15:32 -0700)]
Revert "mm/z3fold.c: fix race between migration and destruction"

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 6e73fd25e2c7510b7dfadbaf701f31d4bff9c75b upstream.

With the original commit applied, z3fold_zpool_destroy() may get blocked
on wait_event() for indefinite time.  Revert this commit for the time
being to get rid of this problem since the issue the original commit
addresses is less severe.

Link: http://lkml.kernel.org/r/20190910123142.7a9c8d2de4d0acbc0977c602@gmail.com
Fixes: d776aaa9895eb6eb77 ("mm/z3fold.c: fix race between migration and destruction")
Reported-by: Agustín Dall'Alba <agustin@dallalba.com.ar>
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Jonathan Adams <jwadams@google.com>
Cc: Henry Burns <henrywolfeburns@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoclk: imx: imx8mm: fix audio pll setting
Peng Fan [Mon, 15 Jul 2019 02:55:43 +0000 (02:55 +0000)]
clk: imx: imx8mm: fix audio pll setting

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 053a4ffe298836bb973d2cba59f82fff60c7db5b upstream.

The AUDIO PLL max support 650M, so the original clk settings violate
spec. This patch makes the output 786432000 -> 393216000,
and 722534400 -> 361267200 to aligned with NXP vendor kernel without any
impact on audio functionality and go within 650MHz PLL limit.

Cc: <stable@vger.kernel.org>
Fixes: ba5625c3e272 ("clk: imx: Add clock driver support for imx8mm")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agocrypto: talitos - fix missing break in switch statement
Gustavo A. R. Silva [Mon, 9 Sep 2019 05:29:52 +0000 (00:29 -0500)]
crypto: talitos - fix missing break in switch statement

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 5fc194ea6d34dfad9833d3043ce41d6c52aff39a upstream.

Add missing break statement in order to prevent the code from falling
through to case CRYPTO_ALG_TYPE_AHASH.

Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface")
Cc: stable@vger.kernel.org
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agomtd: cfi_cmdset_0002: Use chip_good() to retry in do_write_oneword()
Tokunori Ikegami [Mon, 5 Aug 2019 19:03:18 +0000 (04:03 +0900)]
mtd: cfi_cmdset_0002: Use chip_good() to retry in do_write_oneword()

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 37c673ade35c707d50583b5b25091ff8ebdeafd7 upstream.

As reported by the OpenWRT team, write requests sometimes fail on some
platforms.
Currently to check the state chip_ready() is used correctly as described by
the flash memory S29GL256P11TFI01 datasheet.
Also chip_good() is used to check if the write is succeeded and it was
implemented by the commit fb4a90bfcd6d8 ("[MTD] CFI-0002 - Improve error
checking").
But actually the write failure is caused on some platforms and also it can
be fixed by using chip_good() to check the state and retry instead.
Also it seems that it is caused after repeated about 1,000 times to retry
the write one word with the reset command.
By using chip_good() to check the state to be done it can be reduced the
retry with reset.
It is depended on the actual flash chip behavior so the root cause is
unknown.

Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Cc: linux-mtd@lists.infradead.org
Cc: stable@vger.kernel.org
Reported-by: Fabio Bettoni <fbettoni@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
[vigneshr@ti.com: Fix a checkpatch warning]
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoHID: Add quirk for HP X500 PIXART OEM mouse
Sebastian Parschauer [Mon, 2 Sep 2019 10:39:30 +0000 (12:39 +0200)]
HID: Add quirk for HP X500 PIXART OEM mouse

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 2acf40f0454d41b8d51c95d317283c20c931164d upstream.

The PixArt OEM mice are known for disconnecting every minute in
runlevel 1 or 3 if they are not always polled. So add quirk
ALWAYS_POLL for this one as well.

Ville Viinikka (viinikv) reported and tested the quirk.
Link: https://github.com/sriemer/fix-linux-mouse
Signed-off-by: Sebastian Parschauer <s.parschauer@gmx.de>
CC: stable@vger.kernel.org # v4.16+
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoHID: hidraw: Fix invalid read in hidraw_ioctl
Alan Stern [Wed, 21 Aug 2019 17:27:12 +0000 (13:27 -0400)]
HID: hidraw: Fix invalid read in hidraw_ioctl

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 416dacb819f59180e4d86a5550052033ebb6d72c upstream.

The syzbot fuzzer has reported a pair of problems in the
hidraw_ioctl() function: slab-out-of-bounds read and use-after-free
read.  An example of the first:

BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833

CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0xca/0x13e lib/dump_stack.c:113
  print_address_description+0x6a/0x32c mm/kasan/report.c:351
  __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
  kasan_report+0xe/0x12 mm/kasan/common.c:612
  strlen+0x79/0x90 lib/string.c:525
  strlen include/linux/string.h:281 [inline]
  hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
  vfs_ioctl fs/ioctl.c:46 [inline]
  file_ioctl fs/ioctl.c:509 [inline]
  do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
  ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
  __do_sys_ioctl fs/ioctl.c:720 [inline]
  __se_sys_ioctl fs/ioctl.c:718 [inline]
  __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
  do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4
R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff

The two problems have the same cause: hidraw_ioctl() fails to test
whether the device has been removed.  This patch adds the missing test.

Reported-and-tested-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoHID: logitech-dj: Fix crash when initial logi_dj_recv_query_paired_devices fails
Hans de Goede [Sun, 25 Aug 2019 15:35:42 +0000 (17:35 +0200)]
HID: logitech-dj: Fix crash when initial logi_dj_recv_query_paired_devices fails

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 8ccff2843fb4e6d9d26e5ae9ffe9840b38b92638 upstream.

Before this commit dj_probe would exit with an error if the initial
logi_dj_recv_query_paired_devices fails. The initial call may fail
when the receiver is connected through a kvm and the focus is away.

When the call fails this causes 2 problems:

1) dj_probe calls logi_dj_recv_query_paired_devices after calling
hid_device_io_start() so a HID report may have been received in between
and our delayedwork_callback may be running. It seems that the initial
logi_dj_recv_query_paired_devices failure happening with some KVMs triggers
this exact scenario, causing the work-queue to run on free-ed memory,
leading to:

 BUG: unable to handle page fault for address: 0000000000001e88
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] SMP PTI
 CPU: 3 PID: 257 Comm: kworker/3:3 Tainted: G           OE     5.3.0-rc5+ #100
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B150M Pro4S/D3, BIOS P7.10 12/06/2016
 Workqueue: events 0xffffffffc02ba200
 RIP: 0010:0xffffffffc02ba1bd
 Code: e8 e8 13 00 d8 48 89 c5 48 85 c0 74 4c 48 8b 7b 10 48 89 ea b9 07 00 00 00 41 b9 09 00 00 00 41 b8 01 00 00 00 be 10 00 00 00 <48> 8b 87 88 1e 00 00 48 8b 40 40 e8 b3 6b b4 d8 48 89 ef 41 89 c4
 RSP: 0018:ffffb760c046bdb8 EFLAGS: 00010286
 RAX: ffff935038ea4550 RBX: ffff935046778000 RCX: 0000000000000007
 RDX: ffff935038ea4550 RSI: 0000000000000010 RDI: 0000000000000000
 RBP: ffff935038ea4550 R08: 0000000000000001 R09: 0000000000000009
 R10: 000000000000e011 R11: 0000000000000001 R12: ffff9350467780e8
 R13: ffff935046778000 R14: 0000000000000000 R15: ffff935046778070
 FS:  0000000000000000(0000) GS:ffff935054e00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000001e88 CR3: 000000075a612002 CR4: 00000000003606e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  0xffffffffc02ba2f7
  ? process_one_work+0x1b1/0x560
  process_one_work+0x234/0x560
  worker_thread+0x50/0x3b0
  kthread+0x10a/0x140
  ? process_one_work+0x560/0x560
  ? kthread_park+0x80/0x80
  ret_from_fork+0x3a/0x50
 Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep vfat fat btusb btrtl btbcm btintel bluetooth intel_rapl_msr ecdh_generic rfkill ecc snd_usb_audio snd_usbmidi_lib intel_rapl_common snd_rawmidi mc x86_pkg_temp_thermal intel_powerclamp coretemp iTCO_wdt iTCO_vendor_support mei_wdt mei_hdcp ppdev kvm_intel kvm irqbypass crct10dif_pclmul crc32_generic crc32_pclmul snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ghash_clmulni_intel intel_cstate snd_hda_intel snd_hda_codec intel_uncore snd_hda_core snd_hwdep intel_rapl_perf snd_seq snd_seq_device snd_pcm snd_timer intel_wmi_thunderbolt snd e1000e soundcore mxm_wmi i2c_i801 bfq mei_me mei intel_pch_thermal parport_pc parport acpi_pad binfmt_misc hid_lg_g15(E) hid_logitech_dj(E) i915 crc32c_intel i2c_algo_bit drm_kms_helper nvme nvme_core drm wmi video uas usb_storage i2c_dev
 CR2: 0000000000001e88
 ---[ end trace 1d3f8afdcfcbd842 ]---

2) Even if we were to fix 1. by making sure the work is stopped before
failing probe, failing probe is the wrong thing to do, we have
logi_dj_recv_queue_unknown_work to deal with the initial
logi_dj_recv_query_paired_devices failure.

Rather then error-ing out of the probe, causing the receiver to not work at
all we should rely on this, so that the attached devices will get properly
enumerated once the KVM focus is switched back.

Cc: stable@vger.kernel.org
Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoHID: logitech: Fix general protection fault caused by Logitech driver
Alan Stern [Tue, 20 Aug 2019 20:00:21 +0000 (16:00 -0400)]
HID: logitech: Fix general protection fault caused by Logitech driver

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 5f9242775bb61f390f0885f23fc16397262c7538 upstream.

The syzbot fuzzer found a general protection fault in the HID subsystem:

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 3715 Comm: syz-executor.3 Not tainted 5.2.0-rc6+ #15
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__pm_runtime_resume+0x49/0x180 drivers/base/power/runtime.c:1069
Code: ed 74 d5 fe 45 85 ed 0f 85 9a 00 00 00 e8 6f 73 d5 fe 48 8d bd c1 02
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48
89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 fe 00 00 00
RSP: 0018:ffff8881d99d78e0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000020 RCX: ffffc90003f3f000
RDX: 0000000416d8686d RSI: ffffffff82676841 RDI: 00000020b6c3436a
RBP: 00000020b6c340a9 R08: ffff8881c6d64800 R09: fffffbfff0e84c25
R10: ffff8881d99d7940 R11: ffffffff87426127 R12: 0000000000000004
R13: 0000000000000000 R14: ffff8881d9b94000 R15: ffffffff897f9048
FS:  00007f047f542700(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30f21000 CR3: 00000001ca032000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  pm_runtime_get_sync include/linux/pm_runtime.h:226 [inline]
  usb_autopm_get_interface+0x1b/0x50 drivers/usb/core/driver.c:1707
  usbhid_power+0x7c/0xe0 drivers/hid/usbhid/hid-core.c:1234
  hid_hw_power include/linux/hid.h:1038 [inline]
  hidraw_open+0x20d/0x740 drivers/hid/hidraw.c:282
  chrdev_open+0x219/0x5c0 fs/char_dev.c:413
  do_dentry_open+0x497/0x1040 fs/open.c:778
  do_last fs/namei.c:3416 [inline]
  path_openat+0x1430/0x3ff0 fs/namei.c:3533
  do_filp_open+0x1a1/0x280 fs/namei.c:3563
  do_sys_open+0x3c0/0x580 fs/open.c:1070
  do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

It turns out the fault was caused by a bug in the HID Logitech driver,
which violates the requirement that every pathway calling
hid_hw_start() must also call hid_hw_stop().  This patch fixes the bug
by making sure the requirement is met.

Reported-and-tested-by: syzbot+3cbe5cd105d2ad56a1df@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoHID: sony: Fix memory corruption issue on cleanup.
Roderick Colenbrander [Wed, 4 Sep 2019 21:22:11 +0000 (14:22 -0700)]
HID: sony: Fix memory corruption issue on cleanup.

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 2bcdacb70327013ca2066bfcf2af1009eff01f1d upstream.

The sony driver is not properly cleaning up from potential failures in
sony_input_configured. Currently it calls hid_hw_stop, while hid_connect
is still running. This is not a good idea, instead hid_hw_stop should
be moved to sony_probe. Similar changes were recently made to Logitech
drivers, which were also doing improper cleanup.

Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoHID: prodikeys: Fix general protection fault during probe
Alan Stern [Wed, 4 Sep 2019 15:54:20 +0000 (11:54 -0400)]
HID: prodikeys: Fix general protection fault during probe

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 98375b86c79137416e9fd354177b85e768c16e56 upstream.

The syzbot fuzzer provoked a general protection fault in the
hid-prodikeys driver:

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc5+ #28
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:pcmidi_submit_output_report drivers/hid/hid-prodikeys.c:300  [inline]
RIP: 0010:pcmidi_set_operational drivers/hid/hid-prodikeys.c:558 [inline]
RIP: 0010:pcmidi_snd_initialise drivers/hid/hid-prodikeys.c:686 [inline]
RIP: 0010:pk_probe+0xb51/0xfd0 drivers/hid/hid-prodikeys.c:836
Code: 0f 85 50 04 00 00 48 8b 04 24 4c 89 7d 10 48 8b 58 08 e8 b2 53 e4 fc
48 8b 54 24 20 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
85 13 04 00 00 48 ba 00 00 00 00 00 fc ff df 49 8b

The problem is caused by the fact that pcmidi_get_output_report() will
return an error if the HID device doesn't provide the right sort of
output report, but pcmidi_set_operational() doesn't bother to check
the return code and assumes the function call always succeeds.

This patch adds the missing check and aborts the probe operation if
necessary.

Reported-and-tested-by: syzbot+1088533649dafa1c9004@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agopowerpc/xive: Fix bogus error code returned by OPAL
Greg Kurz [Wed, 11 Sep 2019 15:52:18 +0000 (17:52 +0200)]
powerpc/xive: Fix bogus error code returned by OPAL

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8 upstream.

There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
to return the 32-bit value 0xffffffff when OPAL has run out of IRQs.
Unfortunatelty, OPAL return values are signed 64-bit entities and
errors are supposed to be negative. If that happens, the linux code
confusingly treats 0xffffffff as a valid IRQ number and panics at some
point.

A fix was recently merged in skiboot:

e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()")

but we need a workaround anyway to support older skiboots already
in the field.

Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error
returned upon resource exhaustion.

Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/156821713818.1985334.14123187368108582810.stgit@bahia.lan
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agodrm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined...
Nick Desaulniers [Mon, 22 Jul 2019 22:31:05 +0000 (15:31 -0700)]
drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 0f0727d971f6fdf8f1077180d495ddb9928f0c8b upstream.

arch/x86/Makefile disables SSE and SSE2 for the whole kernel.  The
AMDGPU drivers modified in this patch re-enable SSE but not SSE2.  Turn
on SSE2 to support emitting double precision floating point instructions
rather than calls to non-existent (usually available from gcc_s or
compiler_rt) floating point helper routines for Clang.

This was originally landed in:
commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")
but reverted in:
commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"")
due to bugreports from GCC builds. Add guards to only do so for Clang.

Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487
Link: https://github.com/ClangBuiltLinux/linux/issues/327
Suggested-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agodrm/amd/display: Don't replace the dc_state for fast updates
Nicholas Kazlauskas [Wed, 31 Jul 2019 14:33:54 +0000 (10:33 -0400)]
drm/amd/display: Don't replace the dc_state for fast updates

BugLink: https://bugs.launchpad.net/bugs/1848042
commit bd200d190f45b62c006d1ad0a63eeffd87db7a47 upstream.

[Why]
DRM private objects have no hw_done/flip_done fencing mechanism on their
own and cannot be used to sequence commits accordingly.

When issuing commits that don't touch the same set of hardware resources
like page-flips on different CRTCs we can run into the issue below
because of this:

1. Client requests non-blocking Commit #1, has a new dc_state #1,
state is swapped, commit tail is deferred to work queue

2. Client requests non-blocking Commit #2, has a new dc_state #2,
state is swapped, commit tail is deferred to work queue

3. Commit #2 work starts, commit tail finishes,
atomic state is cleared, dc_state #1 is freed

4. Commit #1 work starts,
commit tail encounters null pointer deref on dc_state #1

In order to change the DC state as in the private object we need to
ensure that we wait for all outstanding commits to finish and that
any other pending commits must wait for the current one to finish as
well.

We do this for MEDIUM and FULL updates. But not for FAST updates, nor
would we want to since it would cause stuttering from the delays.

FAST updates that go through dm_determine_update_type_for_commit always
create a new dc_state and lock the DRM private object if there are
any changed planes.

We need the old state to validate, but we don't actually need the new
state here.

[How]
If the commit isn't a full update then the use after free can be
resolved by simply discarding the new state entirely and retaining
the existing one instead.

With this change the sequence above can be reexamined. Commit #2 will
still free Commit #1's reference, but before this happens we actually
added an additional reference as part of Commit #2.

If an update comes in during this that needs to change the dc_state
it will need to wait on Commit #1 and Commit #2 to finish. Then it'll
swap the state, finish the work in commit tail and drop the last
reference on Commit #2's dc_state.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204181
Fixes: 004b3938e637 ("drm/amd/display: Check scaling info when determing update type")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: David Francis <david.francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agodrm/amd/display: Skip determining update type for async updates
Nicholas Kazlauskas [Wed, 31 Jul 2019 13:45:16 +0000 (09:45 -0400)]
drm/amd/display: Skip determining update type for async updates

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 43d10d30df156f7834fa91aecb69614fefc8bb0a upstream.

[Why]
By passing through the dm_determine_update_type_for_commit for atomic
commits that can be done asynchronously we are incurring a
performance penalty by locking access to the global private object
and holding that access until the end of the programming sequence.

This is also allocating a new large dc_state on every access in addition
to retaining all the references on each stream and plane until the end
of the programming sequence.

[How]
Shift the determination for async update before validation. Return early
if it's going to be an async update.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: David Francis <david.francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agodrm/amd/display: Allow cursor async updates for framebuffer swaps
Nicholas Kazlauskas [Mon, 10 Jun 2019 12:47:57 +0000 (08:47 -0400)]
drm/amd/display: Allow cursor async updates for framebuffer swaps

BugLink: https://bugs.launchpad.net/bugs/1848042
commit e16e37efb4c9eb7bcb9dab756c975040c5257e98 upstream.

[Why]
We previously allowed framebuffer swaps as async updates for cursor
planes but had to disable them due to a bug in DRM with async update
handling and incorrect ref counting. The check to block framebuffer
swaps has been added to DRM for a while now, so this check is redundant.

The real fix that allows this to properly in DRM has also finally been
merged and is getting backported into stable branches, so dropping
this now seems to be the right time to do so.

[How]
Drop the redundant check for old_fb != new_fb.

With the proper fix in DRM, this should also fix some cursor stuttering
issues with xf86-video-amdgpu since it double buffers the cursor.

IGT tests that swap framebuffers (-varying-size for example) should
also pass again.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: David Francis <david.francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoclocksource/drivers: Do not warn on probe defer
Jon Hunter [Wed, 21 Aug 2019 15:02:41 +0000 (16:02 +0100)]
clocksource/drivers: Do not warn on probe defer

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 14e019df1e64c8b19ce8e0b3da25b6f40c8716be upstream.

Deferred probe is an expected return value on many platforms and so
there's no need to output a warning that may potentially confuse users.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoclocksource/drivers/timer-of: Do not warn on deferred probe
Jon Hunter [Wed, 21 Aug 2019 15:02:40 +0000 (16:02 +0100)]
clocksource/drivers/timer-of: Do not warn on deferred probe

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 763719771e84b8c8c2f53af668cdc905faa608de upstream.

Deferred probe is an expected return value for clk_get() on many
platforms. The driver deals with it properly, so there's no need
to output a warning that may potentially confuse users.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agonetfilter: add missing IS_ENABLED(CONFIG_NF_TABLES) check to header-file.
Jeremy Sowden [Wed, 7 Aug 2019 14:17:01 +0000 (15:17 +0100)]
netfilter: add missing IS_ENABLED(CONFIG_NF_TABLES) check to header-file.

BugLink: https://bugs.launchpad.net/bugs/1848042
commit 47e640af2e492cc28778dd6f894d50313f7fba75 upstream.

nf_tables.h defines an API comprising several inline functions and
macros that depend on the nft member of struct net.  However, this is
only defined is CONFIG_NF_TABLES is enabled.  Added preprocessor checks
to ensure that nf_tables.h will compile if CONFIG_NF_TABLES is disabled.

Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Link: https://lore.kernel.org/netfilter-devel/20190920094925.aw7actk4tdnk3rke@salvia/T/
Fixes: 3c171f496ef5 ("netfilter: bridge: add connection tracking system")
Reported-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agos390/cpumsf: Check for CPU Measurement sampling
Thomas Richter [Tue, 15 Oct 2019 19:06:00 +0000 (21:06 +0200)]
s390/cpumsf: Check for CPU Measurement sampling

BugLink: https://bugs.launchpad.net/bugs/1847590
s390 IBM z15 introduces a check if the CPU Mesurement Facility
sampling is temporarily unavailable. If this is the case return -EBUSY
and abort the setup of CPU Measuement facility sampling.

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 932bfc5aae08f3cb20c1c9f051542f5933710151)
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Acked-by: Sultan Alsawaf <sultan.alsawaf@canonical.com>
Acked-by: Khalid Elmously <khalid.elmously@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoRevert "Revert "ext4: make __ext4_get_inode_loc plug""
Linus Torvalds [Thu, 3 Oct 2019 13:10:00 +0000 (15:10 +0200)]
Revert "Revert "ext4: make __ext4_get_inode_loc plug""

BugLink: https://bugs.launchpad.net/bugs/1846486
This reverts commit 72dbcf72156641fde4d8ea401e977341bfd35a05.

Instead of waiting forever for entropy that may just not happen, we now
try to actively generate entropy when required, and are thus hopefully
avoiding the problem that caused the nice ext4 IO pattern fix to be
reverted.

So revert the revert.

Cc: Ahmed S. Darwish <darwish.07@gmail.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 02f03c4206c1b2a7451d3b3546f86c9c783eac13)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agorandom: try to actively add entropy rather than passively wait for it
Linus Torvalds [Thu, 3 Oct 2019 13:10:00 +0000 (15:10 +0200)]
random: try to actively add entropy rather than passively wait for it

BugLink: https://bugs.launchpad.net/bugs/1846486
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
caused a bootup regression due to lack of entropy at bootup together
with arguably broken user space that was asking for secure random
numbers when it really didn't need to.

See commit 72dbcf721566 (Revert "ext4: make __ext4_get_inode_loc plug").

This aims to solve the issue by actively generating entropy noise using
the CPU cycle counter when waiting for the random number generator to
initialize.  This only works when you have a high-frequency time stamp
counter available, but that's the case on all modern x86 CPU's, and on
most other modern CPU's too.

What we do is to generate jitter entropy from the CPU cycle counter
under a somewhat complex load: calling the scheduler while also
guaranteeing a certain amount of timing noise by also triggering a
timer.

I'm sure we can tweak this, and that people will want to look at other
alternatives, but there's been a number of papers written on jitter
entropy, and this should really be fairly conservative by crediting one
bit of entropy for every timer-induced jump in the cycle counter.  Not
because the timer itself would be all that unpredictable, but because
the interaction between the timer and the loop is going to be.

Even if (and perhaps particularly if) the timer actually happens on
another CPU, the cacheline interaction between the loop that reads the
cycle counter and the timer itself firing is going to add perturbations
to the cycle counter values that get mixed into the entropy pool.

As Thomas pointed out, with a modern out-of-order CPU, even quite simple
loops show a fair amount of hard-to-predict timing variability even in
the absense of external interrupts.  But this tries to take that further
by actually having a fairly complex interaction.

This is not going to solve the entropy issue for architectures that have
no CPU cycle counter, but it's not clear how (and if) that is solvable,
and the hardware in question is largely starting to be irrelevant.  And
by doing this we can at least avoid some of the even more contentious
approaches (like making the entropy waiting time out in order to avoid
the possibly unbounded waiting).

Cc: Ahmed Darwish <darwish.07@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Nicholas Mc Guire <hofrat@opentech.at>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 50ee7529ec4500c88f8664560770a7a1b65db72b)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agor8152: Set macpassthru in reset_resume callback
Kai-Heng Feng [Mon, 7 Oct 2019 10:45:00 +0000 (12:45 +0200)]
r8152: Set macpassthru in reset_resume callback

BugLink: https://bugs.launchpad.net/bugs/1847063
r8152 may fail to establish network connection after resume from system
suspend.

If the USB port connects to r8152 lost its power during system suspend,
the MAC address was written before is lost. The reason is that The MAC
address doesn't get written again in its reset_resume callback.

So let's set MAC address again in reset_resume callback. Also remove
unnecessary lock as no other locking attempt will happen during
reset_resume.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a54cdeeb04fc719e4c7f19d6e28dba7ea86cee5b)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: You-Sheng Yang <vicamo.yang@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoUBUNTU: SAUCE: overlayfs: allow with shiftfs as underlay
Christian Brauner [Wed, 2 Oct 2019 07:58:00 +0000 (09:58 +0200)]
UBUNTU: SAUCE: overlayfs: allow with shiftfs as underlay

BugLink: https://bugs.launchpad.net/bugs/1846272
In commit [1] we enabled overlayfs on top of shiftfs. This approach was
buggy since it let to a regression for some standard overlayfs workloads
(cf. [2]).
In our original approach in [1] Seth and I concluded that running
overlayfs on top of shiftfs was not possible because of the way
overlayfs is currently opening files. The fact that it did not pass down
the dentry of shiftfs but rather it's own caused shiftfs to be confused
since it stashes away necessary information in d_fsdata.
Our solution was to modify open_with_fake_path() to also take a dentry
as an argument, then change overlayfs to pass in the shiftfs dentry
which then would override the dentry in the passed in struct path in
open_with_fake_path().
However, this led to a regression for some standard overlayfs workloads
(cf. [2]).
After various discussions involving Seth and myself in Paris we
concluded the reason for the regression was that we effectively created
a struct path that was comprised of the vfsmount of the overlayfs dentry
and the dentry of shiftfs. This is obviously broken.
The fix is to a) not modify open_with_fake_path() and b) change
overlayfs to do what shiftfs is doing, namely correctly setup the struct
path such that vfsmount and dentry match and are both from shiftfs.
Note, that overlayfs already does this for the .open method for
directories. It just did not do it for the .open method for regular
files leading to this issue. The reason why this hasn't been a problem
for overlayfs so far is that it didn't allow running on top of
filesystems that make use of d_fsdata _implicitly_ by disallowing any
filesystem that is itself an overlay, or has revalidate methods for it's
dentries as those usually have d_fsdata set up. Any other filesystem
falling in this category would have suffered from the same problem.

Seth managed to trigger the regression with the following script:
 #!/bin/bash

 utils=(bash cat)

 mkdir -p lower/proc upper work root
 for util in ${utils[@]}; do
  path="$(which $util)"
  dir="$(dirname $path)"
  mkdir -p "lower/$dir"
  cp -v "$path" "lower/$path"
  libs="$(ldd $path | egrep -o '(/usr)?/lib.*\.[0-9]')"
  for lib in $libs; do
  dir="$(dirname $lib)"
  mkdir -p "lower/$dir"
  cp -v "$lib" "lower/$lib"
  done
 done

 mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work nodev root
 mount -t proc nodev root/proc
 chroot root bash -c "cat /proc/self/maps"
 umount root/proc
 umount root

With the patch here applied the regression is not reproducible.

/* References */
[1]: 37430e430a14 ("UBUNTU: SAUCE: shiftfs: enable overlayfs on shiftfs")
[2]: https://bugs.launchpad.net/bugs/1838677

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoUBUNTU: SAUCE: apparmor: fix nnp subset test for unconfined
John Johansen [Thu, 3 Oct 2019 19:14:00 +0000 (21:14 +0200)]
UBUNTU: SAUCE: apparmor: fix nnp subset test for unconfined

The subset test is not taking into account the unconfined exception
which will cause profile transitions in the stacked confinement
case to fail when no_new_privs is applied.

This fixes a regression introduced in the 4.17 kernel caused by the
reworking of domain transitions.

Fixes: 9fcf78cca1986 ("apparmor: update domain transitions that are subsets of confinement at nnp")
BugLink: https://bugs.launchpad.net/bugs/1844186
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoPM / hibernate: memory_bm_find_bit(): Tighten node optimisation
Andy Whitcroft [Wed, 25 Sep 2019 14:39:12 +0000 (15:39 +0100)]
PM / hibernate: memory_bm_find_bit(): Tighten node optimisation

BugLink: https://bugs.launchpad.net/bugs/1847118
When looking for a bit by number we make use of the cached result from the
preceding lookup to speed up operation.  Firstly we check if the requested
pfn is within the cached zone and if not lookup the new zone.  We then
check if the offset for that pfn falls within the existing cached node.
This happens regardless of whether the node is within the zone we are
now scanning.  With certain memory layouts it is possible for this to
false trigger creating a temporary alias for the pfn to a different bit.
This leads the hibernation code to free memory which it was never allocated
with the expected fallout.

Ensure the zone we are scanning matches the cached zone before considering
the cached node.

Deep thanks go to Andrea for many, many, many hours of hacking and testing
that went into cornering this bug.

Reported-by: Andrea Righi <andrea.righi@canonical.com>
Tested-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 39800d8fc4083cfe5c8f69333336bf03f9571070 linux-next)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoUBUNTU: [Debian] Add debian.master/reconstruct
Seth Forshee [Fri, 11 Oct 2019 21:33:56 +0000 (16:33 -0500)]
UBUNTU: [Debian] Add debian.master/reconstruct

This file got removed from git somewhere along the way. Add it
back.

Ignore: yes
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: Ubuntu-5.3.0-19.20 Ubuntu-5.3.0-19.20
Khalid Elmously [Fri, 18 Oct 2019 08:17:50 +0000 (04:17 -0400)]
UBUNTU: Ubuntu-5.3.0-19.20

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoUBUNTU: link-to-tracker: update tracking bug
Khalid Elmously [Fri, 18 Oct 2019 08:16:54 +0000 (04:16 -0400)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1848648
Properties: no-test-build
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoUBUNTU: Start new release
Khalid Elmously [Fri, 18 Oct 2019 08:16:19 +0000 (04:16 -0400)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule
Jason A. Donenfeld [Wed, 9 Oct 2019 17:59:00 +0000 (19:59 +0200)]
ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule

BugLink: https://launchpad.net/bugs/1847478
Commit 7d9e5f422150 removed references from certain dsts, but accounting
for this never translated down into the fib6 suppression code. This bug
was triggered by WireGuard users who use wg-quick(8), which uses the
"suppress-prefix" directive to ip-rule(8) for routing all of their
internet traffic without routing loops. The test case added here
causes the reference underflow by causing packets to evaluate a suppress
rule.

Fixes: 7d9e5f422150 ("ipv6: convert major tx path to use RT6_LOOKUP_F_DST_NOREF")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Wei Wang <weiwan@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ca7a03c4175366a92cee0ccc4fec0038c3266e26)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Sultan Alsawaf <sultan.alsawaf@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 years agoUBUNTU: Ubuntu-5.3.0-18.19 Ubuntu-5.3.0-18.19
Seth Forshee [Tue, 8 Oct 2019 16:21:55 +0000 (11:21 -0500)]
UBUNTU: Ubuntu-5.3.0-18.19

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: link-to-tracker: update tracking bug
Seth Forshee [Tue, 8 Oct 2019 16:20:29 +0000 (11:20 -0500)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1847298
Properties: no-test-build
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_RTC_DRV_PM8XXX=y
Paolo Pisati [Fri, 4 Oct 2019 12:22:03 +0000 (12:22 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_RTC_DRV_PM8XXX=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_KEYBOARD_GPIO=y
Paolo Pisati [Fri, 4 Oct 2019 12:19:01 +0000 (12:19 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_KEYBOARD_GPIO=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_INPUT_PM8941_PWRKEY=y
Paolo Pisati [Fri, 4 Oct 2019 12:16:15 +0000 (12:16 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_INPUT_PM8941_PWRKEY=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_POWER_RESET_QCOM_PON=y
Paolo Pisati [Fri, 4 Oct 2019 12:14:00 +0000 (12:14 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_POWER_RESET_QCOM_PON=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_CRYPTO_DEV_QCOM_RNG=y
Paolo Pisati [Fri, 4 Oct 2019 12:07:37 +0000 (12:07 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_CRYPTO_DEV_QCOM_RNG=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_USBNET=y
Paolo Pisati [Fri, 4 Oct 2019 12:03:59 +0000 (12:03 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_USBNET=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_NLS_ISO8859_1=y
Paolo Pisati [Fri, 4 Oct 2019 09:29:12 +0000 (09:29 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_NLS_ISO8859_1=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_QCOM_CLK_APCS_MSM8916=y
Paolo Pisati [Fri, 4 Oct 2019 09:28:37 +0000 (09:28 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_QCOM_CLK_APCS_MSM8916=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_QCOM_A53PLL=y
Paolo Pisati [Fri, 4 Oct 2019 09:28:01 +0000 (09:28 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_QCOM_A53PLL=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
Paolo Pisati [Fri, 4 Oct 2019 09:27:27 +0000 (09:27 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_LEDS_TRIGGER_HEARTBEAT=y
Paolo Pisati [Fri, 4 Oct 2019 09:26:53 +0000 (09:26 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_LEDS_TRIGGER_HEARTBEAT=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_LEDS_PWM=y
Paolo Pisati [Fri, 4 Oct 2019 09:26:07 +0000 (09:26 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_LEDS_PWM=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3_QCOM=y
Paolo Pisati [Fri, 4 Oct 2019 09:25:32 +0000 (09:25 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3_QCOM=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3_OF_SIMPLE=y
Paolo Pisati [Fri, 4 Oct 2019 09:24:57 +0000 (09:24 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3_OF_SIMPLE=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3_PCI=y
Paolo Pisati [Fri, 4 Oct 2019 09:24:22 +0000 (09:24 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3_PCI=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3=y
Paolo Pisati [Fri, 4 Oct 2019 09:23:46 +0000 (09:23 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_DWC3=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_MUSB_HDRC=y
Paolo Pisati [Fri, 4 Oct 2019 09:23:11 +0000 (09:23 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_MUSB_HDRC=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_OHCI_HCD_PLATFORM=y
Paolo Pisati [Fri, 4 Oct 2019 09:22:36 +0000 (09:22 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_OHCI_HCD_PLATFORM=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_XHCI_PLATFORM=y
Paolo Pisati [Fri, 4 Oct 2019 09:22:01 +0000 (09:22 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_XHCI_PLATFORM=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_OTG=y
Paolo Pisati [Fri, 4 Oct 2019 09:19:02 +0000 (09:19 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_OTG=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_NET_DRIVERS=y
Paolo Pisati [Fri, 4 Oct 2019 09:18:26 +0000 (09:18 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_NET_DRIVERS=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
4 years agoUBUNTU: [Config] arm64: snapdragon: CONFIG_USB_HSIC_USB3503=y
Paolo Pisati [Thu, 3 Oct 2019 14:09:35 +0000 (14:09 +0000)]
UBUNTU: [Config] arm64: snapdragon: CONFIG_USB_HSIC_USB3503=y

BugLink: https://bugs.launchpad.net/bugs/1846704
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>