mirror_ubuntu-bionic-kernel.git
7 weeks agoUBUNTU: Ubuntu-4.15.0-55.60 master Ubuntu-4.15.0-55.60
Kleber Sacilotto de Souza [Tue, 2 Jul 2019 16:41:49 +0000 (18:41 +0200)]
UBUNTU: Ubuntu-4.15.0-55.60

Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoUBUNTU: link-to-tracker: update tracking bug
Kleber Sacilotto de Souza [Tue, 2 Jul 2019 16:37:12 +0000 (18:37 +0200)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1834954
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoUBUNTU: Start new release
Kleber Sacilotto de Souza [Tue, 2 Jul 2019 16:35:53 +0000 (18:35 +0200)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: avoid iput_final() while holding mutex or in dispatch thread
Yan, Zheng [Sat, 18 May 2019 12:39:55 +0000 (20:39 +0800)]
ceph: avoid iput_final() while holding mutex or in dispatch thread

BugLink: https://bugs.launchpad.net/bugs/1834235
iput_final() may wait for reahahead pages. The wait can cause deadlock.
For example:

  Workqueue: ceph-msgr ceph_con_workfn [libceph]
    Call Trace:
     schedule+0x36/0x80
     io_schedule+0x16/0x40
     __lock_page+0x101/0x140
     truncate_inode_pages_range+0x556/0x9f0
     truncate_inode_pages_final+0x4d/0x60
     evict+0x182/0x1a0
     iput+0x1d2/0x220
     iterate_session_caps+0x82/0x230 [ceph]
     dispatch+0x678/0xa80 [ceph]
     ceph_con_workfn+0x95b/0x1560 [libceph]
     process_one_work+0x14d/0x410
     worker_thread+0x4b/0x460
     kthread+0x105/0x140
     ret_from_fork+0x22/0x40

  Workqueue: ceph-msgr ceph_con_workfn [libceph]
    Call Trace:
     __schedule+0x3d6/0x8b0
     schedule+0x36/0x80
     schedule_preempt_disabled+0xe/0x10
     mutex_lock+0x2f/0x40
     ceph_check_caps+0x505/0xa80 [ceph]
     ceph_put_wrbuffer_cap_refs+0x1e5/0x2c0 [ceph]
     writepages_finish+0x2d3/0x410 [ceph]
     __complete_request+0x26/0x60 [libceph]
     handle_reply+0x6c8/0xa10 [libceph]
     dispatch+0x29a/0xbb0 [libceph]
     ceph_con_workfn+0x95b/0x1560 [libceph]
     process_one_work+0x14d/0x410
     worker_thread+0x4b/0x460
     kthread+0x105/0x140
     ret_from_fork+0x22/0x40

In above example, truncate_inode_pages_range() waits for readahead pages
while holding s_mutex. ceph_check_caps() waits for s_mutex and blocks
OSD dispatch thread. Later OSD replies (for readahead) can't be handled.

ceph_check_caps() also may lock snap_rwsem for read. So similar deadlock
can happen if iput_final() is called while holding snap_rwsem.

In general, it's not good to call iput_final() inside MDS/OSD dispatch
threads or while holding any mutex.

The fix is introducing ceph_async_iput(), which calls iput_final() in
workqueue.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 3e1d0452edceebb903d23db53201013c940bf000)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: quota: add counter for snaprealms with quota
Luis Henriques [Fri, 12 Jan 2018 17:19:29 +0000 (17:19 +0000)]
ceph: quota: add counter for snaprealms with quota

BugLink: https://bugs.launchpad.net/bugs/1834235
By keeping a counter with the number of snaprealms that have quota set
allows to optimize the functions that need to walk throught the realms
hierarchy looking for quotas.  Thus, if this counter is zero it's safe to
assume that there are no realms with quota.

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit d557c48db730eaab6b75d4af332c135309b7a6a4)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: quota: update MDS when max_bytes is approaching
Luis Henriques [Fri, 5 Jan 2018 10:47:22 +0000 (10:47 +0000)]
ceph: quota: update MDS when max_bytes is approaching

BugLink: https://bugs.launchpad.net/bugs/1834235
When we're reaching the ceph.quota.max_bytes limit, i.e., when writing
more than 1/16th of the space left in a quota realm, update the MDS with
the new file size.

This mirrors the fuse-client approach with commit 122c50315ed1 ("client:
Inform mds file size when approaching quota limit"), in the ceph git tree.

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 1ab302a0cb1455631646aa66b7fc02afd617ea4f)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: quota: support for ceph.quota.max_bytes
Luis Henriques [Fri, 5 Jan 2018 10:47:21 +0000 (10:47 +0000)]
ceph: quota: support for ceph.quota.max_bytes

BugLink: https://bugs.launchpad.net/bugs/1834235
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 2b83845f8bd711e66e1c367a9bd56c9df3410236)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: fix root quota realm check
Yan, Zheng [Fri, 12 Jan 2018 08:55:31 +0000 (16:55 +0800)]
ceph: fix root quota realm check

BugLink: https://bugs.launchpad.net/bugs/1834235
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 0eb6bbe4d9cf02f639d661edf7c02defc3453a69)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: quota: don't allow cross-quota renames
Luis Henriques [Fri, 5 Jan 2018 10:47:20 +0000 (10:47 +0000)]
ceph: quota: don't allow cross-quota renames

BugLink: https://bugs.launchpad.net/bugs/1834235
This patch changes ceph_rename so that -EXDEV is returned if an attempt is
made to mv a file between two different dir trees with different quotas
setup.

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit cafe21a4fb3075fb2980caba8fdb533a1bdb52b0)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: quota: support for ceph.quota.max_files
Luis Henriques [Fri, 5 Jan 2018 10:47:19 +0000 (10:47 +0000)]
ceph: quota: support for ceph.quota.max_files

BugLink: https://bugs.launchpad.net/bugs/1834235
This patch adds support for the max_files quota.  It hooks into all the
ceph functions that add new filesystem objects that need to be checked
against the quota limits.  When these limits are hit, -EDQUOT is returned.

Note that we're not checking quotas on ceph_link().  ceph_link doesn't
really create a new inode,  and since the MDS doesn't update the directory
statistics when a new (hard) link is created (only with symlinks), they
are not accounted as a new file.

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit b7a2921765cf796280baf653a52b22b52e0ba266)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: quota: add initial infrastructure to support cephfs quotas
Luis Henriques [Fri, 5 Jan 2018 10:47:18 +0000 (10:47 +0000)]
ceph: quota: add initial infrastructure to support cephfs quotas

BugLink: https://bugs.launchpad.net/bugs/1834235
This patch adds the infrastructure required to support cephfs quotas as it
is currently implemented in the ceph fuse client.  Cephfs quotas can be
set on any directory, and can restrict the number of bytes or the number
of files stored beneath that point in the directory hierarchy.

Quotas are set using the extended attributes 'ceph.quota.max_files' and
'ceph.quota.max_bytes', and can be removed by setting these attributes to
'0'.

Link: http://tracker.ceph.com/issues/22372
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit fb18a57568c2b84cd611e242c0f6fa97b45e4907)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: avoid dereferencing invalid pointer during cached readdir
Yan, Zheng [Mon, 27 Nov 2017 03:23:48 +0000 (11:23 +0800)]
ceph: avoid dereferencing invalid pointer during cached readdir

BugLink: https://bugs.launchpad.net/bugs/1834235
Readdir cache keeps array of dentry pointers in page cache. If any
dentry in readdir cache gets pruned, ceph_d_prune() disables readdir
cache for later readdir syscall. The problem is that ceph_d_prune()
ignores unhashed dentry. Ideally MDS should have already revoked
CEPH_CAP_FILE_SHARED (which also disables readdir cache) when dentry
gets unhashed. But if it is somehow MDS does not properly revoke
CEPH_CAP_FILE_SHARED and the unhashed dentry gets pruned later,
ceph_d_prune() will not disable readdir cache, later readdir may
reference invalid dentry pointer.

The fix is make ceph_d_prune() do extra check for unhashed dentry.
Disable readdir cache if the unhashed dentry is still referenced
by readdir cache.

Another fix in this patch is handle d_splice_alias(). If a dentry
gets spliced into new parent dentry, treat it as if it was pruned
(call ceph_d_prune() for it).

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 5495c2d04f85da09512f5f346ed24dc0261d905d)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: single workqueue for inode related works
Yan, Zheng [Sat, 18 May 2019 03:18:44 +0000 (11:18 +0800)]
ceph: single workqueue for inode related works

BugLink: https://bugs.launchpad.net/bugs/1834235
We have three workqueue for inode works. Later patch will introduce
one more work for inode. It's not good to introcuce more workqueue
and add more 'struct work_struct' to 'struct ceph_inode_info'.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 1cf89a8dee5e6e9d4fcb81b571a54d40068dfbb7)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: send cap releases more aggressively
Yan, Zheng [Mon, 14 Jan 2019 09:21:19 +0000 (17:21 +0800)]
ceph: send cap releases more aggressively

BugLink: https://bugs.launchpad.net/bugs/1834235
When pending cap releases fill up one message, start a work to send
cap release message. (old way is sending cap releases every 5 seconds)

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit e3ec8d6898f71636a067dae683174ef9bf81bc96)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: flush pending works before shutdown super
Yan, Zheng [Fri, 18 May 2018 08:05:51 +0000 (16:05 +0800)]
ceph: flush pending works before shutdown super

BugLink: https://bugs.launchpad.net/bugs/1834235
Pending works hold inode references, which cause "Busy inodes after
unmount" warning.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit a57d9064e4ee4e9882b922d0627be3d426004c69)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: define argument structure for handle_cap_grant
Yan, Zheng [Fri, 27 Apr 2018 02:29:44 +0000 (10:29 +0800)]
ceph: define argument structure for handle_cap_grant

BugLink: https://bugs.launchpad.net/bugs/1834235
The data structure includes the versioned feilds of cap message.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit a1c6b8358171c16db0f858a7fbb28aa574b07c09)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoceph: use atomic_t for ceph_inode_info::i_shared_gen
Yan, Zheng [Mon, 27 Nov 2017 02:47:46 +0000 (10:47 +0800)]
ceph: use atomic_t for ceph_inode_info::i_shared_gen

BugLink: https://bugs.launchpad.net/bugs/1834235
It allows accessing i_shared_gen without holding i_ceph_lock. It is
preparation for later patch.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Acked-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 97aeb6bf988e0830fd80dca724fd89526b3f35e4)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoUBUNTU: SAUCE: USB: Disable USB2 LPM at shutdown
Kai-Heng Feng [Mon, 10 Jun 2019 07:21:00 +0000 (09:21 +0200)]
UBUNTU: SAUCE: USB: Disable USB2 LPM at shutdown

BugLink: https://bugs.launchpad.net/bugs/1757218
The QCA Rome USB Bluetooth controller has several issues once LPM gets
enabled:
- Fails to get enumerated in coldboot. [1]
- Drains more power (~ 0.2W) when the system is in S5. [2]
- Disappears after a warmboot. [2]

The issue happens because the device lingers at LPM L1 in S5, so device
can't get enumerated even after a reboot.

Disable LPM at shutdown to solve the issue.

[1] https://bugs.launchpad.net/bugs/1757218
[2] https://patchwork.kernel.org/patch/10607097/

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.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>
7 weeks agonet: hns: fix unsigned comparison to less than zero
Colin Ian King [Fri, 5 Apr 2019 13:59:16 +0000 (14:59 +0100)]
net: hns: fix unsigned comparison to less than zero

BugLink: https://bugs.launchpad.net/bugs/1833140
Currently mskid is unsigned and hence comparisons with negative
error return values are always false. Fix this by making mskid an
int.

Fixes: f058e46855dc ("net: hns: fix ICMP6 neighbor solicitation messages discard problem")
Addresses-Coverity: ("Operands don't affect result")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ea401685a20b5d631957f024bda86e1f6118eb20)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet: hns: fix ICMP6 neighbor solicitation messages discard problem
Yonglong Liu [Thu, 4 Apr 2019 08:46:45 +0000 (16:46 +0800)]
net: hns: fix ICMP6 neighbor solicitation messages discard problem

BugLink: https://bugs.launchpad.net/bugs/1833140
ICMP6 neighbor solicitation messages will be discard by the Hip06
chips, because of not setting forwarding pool. Enable promisc mode
has the same problem.

This patch fix the wrong forwarding table configs for the multicast
vague matching when enable promisc mode, and add forwarding pool
for the forwarding table.

Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit f058e46855dcbc28edb2ed4736f38a71fd19cadb)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet: hns: Fix probabilistic memory overwrite when HNS driver initialized
Yonglong Liu [Thu, 4 Apr 2019 08:46:44 +0000 (16:46 +0800)]
net: hns: Fix probabilistic memory overwrite when HNS driver initialized

BugLink: https://bugs.launchpad.net/bugs/1833138
When reboot the system again and again, may cause a memory
overwrite.

[   15.638922] systemd[1]: Reached target Swap.
[   15.667561] tun: Universal TUN/TAP device driver, 1.6
[   15.676756] Bridge firewalling registered
[   17.344135] Unable to handle kernel paging request at virtual address 0000000200000040
[   17.352179] Mem abort info:
[   17.355007]   ESR = 0x96000004
[   17.358105]   Exception class = DABT (current EL), IL = 32 bits
[   17.364112]   SET = 0, FnV = 0
[   17.367209]   EA = 0, S1PTW = 0
[   17.370393] Data abort info:
[   17.373315]   ISV = 0, ISS = 0x00000004
[   17.377206]   CM = 0, WnR = 0
[   17.380214] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[   17.386926] [0000000200000040] pgd=0000000000000000
[   17.391878] Internal error: Oops: 96000004 [#1] SMP
[   17.396824] CPU: 23 PID: 95 Comm: kworker/u130:0 Tainted: G            E     4.19.25-1.2.78.aarch64 #1
[   17.414175] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.54 08/16/2018
[   17.425615] Workqueue: events_unbound async_run_entry_fn
[   17.435151] pstate: 00000005 (nzcv daif -PAN -UAO)
[   17.444139] pc : __mutex_lock.isra.1+0x74/0x540
[   17.453002] lr : __mutex_lock.isra.1+0x3c/0x540
[   17.461701] sp : ffff000100d9bb60
[   17.469146] x29: ffff000100d9bb60 x28: 0000000000000000
[   17.478547] x27: 0000000000000000 x26: ffff802fb8945000
[   17.488063] x25: 0000000000000000 x24: ffff802fa32081a8
[   17.497381] x23: 0000000000000002 x22: ffff801fa2b15220
[   17.506701] x21: ffff000009809000 x20: ffff802fa23a0888
[   17.515980] x19: ffff801fa2b15220 x18: 0000000000000000
[   17.525272] x17: 0000000200000000 x16: 0000000200000000
[   17.534511] x15: 0000000000000000 x14: 0000000000000000
[   17.543652] x13: ffff000008d95db8 x12: 000000000000000d
[   17.552780] x11: ffff000008d95d90 x10: 0000000000000b00
[   17.561819] x9 : ffff000100d9bb90 x8 : ffff802fb89d6560
[   17.570829] x7 : 0000000000000004 x6 : 00000004a1801d05
[   17.579839] x5 : 0000000000000000 x4 : 0000000000000000
[   17.588852] x3 : ffff802fb89d5a00 x2 : 0000000000000000
[   17.597734] x1 : 0000000200000000 x0 : 0000000200000000
[   17.606631] Process kworker/u130:0 (pid: 95, stack limit = 0x(____ptrval____))
[   17.617438] Call trace:
[   17.623349]  __mutex_lock.isra.1+0x74/0x540
[   17.630927]  __mutex_lock_slowpath+0x24/0x30
[   17.638602]  mutex_lock+0x50/0x60
[   17.645295]  drain_workqueue+0x34/0x198
[   17.652623]  __sas_drain_work+0x7c/0x168
[   17.659903]  sas_drain_work+0x60/0x68
[   17.666947]  hisi_sas_scan_finished+0x30/0x40 [hisi_sas_main]
[   17.676129]  do_scsi_scan_host+0x70/0xb0
[   17.683534]  do_scan_async+0x20/0x228
[   17.690586]  async_run_entry_fn+0x4c/0x1d0
[   17.697997]  process_one_work+0x1b4/0x3f8
[   17.705296]  worker_thread+0x54/0x470

Every time the call trace is not the same, but the overwrite address
is always the same:
Unable to handle kernel paging request at virtual address 0000000200000040

The root cause is, when write the reg XGMAC_MAC_TX_LF_RF_CONTROL_REG,
didn't use the io_base offset.

Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c0b0984426814f3a9251873b689e67d34d8ccd84)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw()
Liubin Shu [Thu, 4 Apr 2019 08:46:42 +0000 (16:46 +0800)]
net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw()

BugLink: https://bugs.launchpad.net/bugs/1833136
This patch is trying to fix the issue due to:
[27237.844750] BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x708/0xa18[hns_enet_drv]

After hnae_queue_xmit() in hns_nic_net_xmit_hw(), can be
interrupted by interruptions, and than call hns_nic_tx_poll_one()
to handle the new packets, and free the skb. So, when turn back to
hns_nic_net_xmit_hw(), calling skb->len will cause use-after-free.

This patch update tx ring statistics in hns_nic_tx_poll_one() to
fix the bug.

Signed-off-by: Liubin Shu <shuliubin@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 3a39a12ad364a9acd1038ba8da67cd8430f30de4)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet: hns: Restart autoneg need return failed when autoneg off
Yonglong Liu [Sat, 26 Jan 2019 09:18:26 +0000 (17:18 +0800)]
net: hns: Restart autoneg need return failed when autoneg off

BugLink: https://bugs.launchpad.net/bugs/1833147
The hns driver of earlier devices, when autoneg off, restart autoneg
will return -EINVAL, so make the hns driver for the latest devices
do the same.

Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ed29ca8b9592562559c64d027fb5eb126e463e2c)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agopowerpc: sys_pkey_mprotect() system call
Ram Pai [Mon, 3 Jun 2019 12:03:00 +0000 (14:03 +0200)]
powerpc: sys_pkey_mprotect() system call

BugLink: https://bugs.launchpad.net/bugs/1821625
Patch provides the ability for a process to
associate a pkey with a address range.

Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 3350eb2ea127978319ced883523d828046af4045)
Signed-off-by: Dan Streetman <ddstreet@canonical.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>
7 weeks agopowerpc: sys_pkey_alloc() and sys_pkey_free() system calls
Ram Pai [Mon, 3 Jun 2019 12:03:00 +0000 (14:03 +0200)]
powerpc: sys_pkey_alloc() and sys_pkey_free() system calls

BugLink: https://bugs.launchpad.net/bugs/1821625
Finally this patch provides the ability for a process to
allocate and free a protection key.

Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 9499ec1b5e82321829e1c1510bcc37edc20b6f38)
Signed-off-by: Dan Streetman <ddstreet@canonical.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>
7 weeks agopkey: Indicate old mkvp only if old and current mkvp are different
Ingo Franzki [Tue, 18 Jun 2019 07:03:00 +0000 (09:03 +0200)]
pkey: Indicate old mkvp only if old and current mkvp are different

BugLink: https://bugs.launchpad.net/bugs/1832625
When the CCA master key is set twice with the same master key,
then the old and the current master key are the same and thus the
verification patterns are the same, too. The check to report if a
secure key is currently wrapped by the old master key erroneously
reports old mkvp in this case.

Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
(cherry picked from commit ebb7c695d3bc7a4986b92edc8d9ef43491be183e)
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agos390/crypto: fix gcm-aes-s390 selftest failures
Harald Freudenberger [Tue, 18 Jun 2019 15:57:00 +0000 (17:57 +0200)]
s390/crypto: fix gcm-aes-s390 selftest failures

BugLink: https://bugs.launchpad.net/bugs/1832623
The current kernel uses improved crypto selftests. These
tests showed that the current implementation of gcm-aes-s390
is not able to deal with chunks of output buffers which are
not a multiple of 16 bytes. This patch introduces a rework
of the gcm aes s390 scatter walk handling which now is able
to handle any input and output scatter list chunk sizes
correctly.

Code has been verified by the crypto selftests, the tcrypt
kernel module and additional tests ran via the af_alg interface.

Cc: <stable@vger.kernel.org>
Reported-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Patrick Steuer <steuer@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
(cherry picked from commit bef9f0ba300a55d79a69aa172156072182176515)
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agopowerpc/numa: document topology_updates_enabled, disable by default
Nathan Lynch [Mon, 24 Jun 2019 17:03:00 +0000 (19:03 +0200)]
powerpc/numa: document topology_updates_enabled, disable by default

Changing the NUMA associations for CPUs and memory at runtime is
basically unsupported by the core mm, scheduler etc. We see all manner
of crashes, warnings and instability when the pseries code tries to do
this. Disable this behavior by default, and document the switch a bit.

BugLink: https://bugs.launchpad.net/bugs/1833716
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 558f86493df09f68f79fe056d9028d317a3ce8ab)
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agopowerpc/numa: improve control of topology updates
Nathan Lynch [Mon, 24 Jun 2019 17:03:00 +0000 (19:03 +0200)]
powerpc/numa: improve control of topology updates

When booted with "topology_updates=no", or when "off" is written to
/proc/powerpc/topology_updates, NUMA reassignments are inhibited for
PRRN and VPHN events. However, migration and suspend unconditionally
re-enable reassignments via start_topology_update(). This is
incoherent.

Check the topology_updates_enabled flag in
start/stop_topology_update() so that callers of those APIs need not be
aware of whether reassignments are enabled. This allows the
administrative decision on reassignments to remain in force across
migrations and suspensions.

BugLink: https://bugs.launchpad.net/bugs/1833716
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 2d4d9b308f8f8dec68f6dbbff18c68ec7c6bd26f)
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoscripts: override locale from environment when running recordmcount.pl
Daniel Dadap [Fri, 28 Jun 2019 05:58:00 +0000 (07:58 +0200)]
scripts: override locale from environment when running recordmcount.pl

BugLink: https://bugs.launchpad.net/bugs/1828084
recordmcount.pl uses a set of regular expressions to parse the output of
objdump(1). However, if objdump(1) output is localized, it may not match
the regular expressions, thereby preventing recordmcount.pl from parsing
object files correctly.

In order to allow recordmcount.pl to function correctly regardless of the
current locale settings, set LANG=C when running objdump(1). LC_ALL is
already unset in the top-level Makefile, so it is not necessary to also
override that environment variable.

Signed-off-by: Daniel Dadap <ddadap@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
(cherry picked from commit e46b94d228458aefc2553ee7c34ab18c2e3288e3)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agos390/zcrypt: Fix wrong dispatching for control domain CPRBs
Harald Freudenberger [Thu, 27 Jun 2019 20:13:00 +0000 (22:13 +0200)]
s390/zcrypt: Fix wrong dispatching for control domain CPRBs

BugLink: https://bugs.launchpad.net/bugs/1832624
The zcrypt device driver does not handle CPRBs which address
a control domain correctly. This fix introduces a workaround:
The domain field of the request CPRB is checked if there is
a valid domain value in there. If this is true and the value
is a control only domain (a domain which is enabled in the
crypto config ADM mask but disabled in the AQM mask) the
CPRB is forwarded to the default usage domain. If there is
no default domain, the request is rejected with an ENODEV.

This fix is important for maintaining crypto adapters. For
example one LPAR can use a crypto adapter domain ('Control
and Usage') but another LPAR needs to be able to maintain
this adapter domain ('Control'). Scenarios like this did
not work properly and the patch enables this.

OriginalAuthor: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
(backported from commit 7379e652797c0b9b5f6caea1576f2dff9ce6a708)
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock().
Mao Wenan [Tue, 4 Jun 2019 06:47:00 +0000 (08:47 +0200)]
net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock().

CVE-2019-11815
https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-11815.html

When it is to cleanup net namespace, rds_tcp_exit_net() will call
rds_tcp_kill_sock(), if t_sock is NULL, it will not call
rds_conn_destroy(), rds_conn_path_destroy() and rds_tcp_conn_free() to free
connection, and the worker cp_conn_w is not stopped, afterwards the net is freed in
net_drop_ns(); While cp_conn_w rds_connect_worker() will call rds_tcp_conn_path_connect()
and reference 'net' which has already been freed.

In rds_tcp_conn_path_connect(), rds_tcp_set_callbacks() will set t_sock = sock before
sock->ops->connect, but if connect() is failed, it will call
rds_tcp_restore_callbacks() and set t_sock = NULL, if connect is always
failed, rds_connect_worker() will try to reconnect all the time, so
rds_tcp_kill_sock() will never to cancel worker cp_conn_w and free the
connections.

Therefore, the condition !tc->t_sock is not needed if it is going to do
cleanup_net->rds_tcp_exit_net->rds_tcp_kill_sock, because tc->t_sock is always
NULL, and there is on other path to cancel cp_conn_w and free
connection. So this patch is to fix this.

rds_tcp_kill_sock():
...
if (net != c_net || !tc->t_sock)
...
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
==================================================================
BUG: KASAN: use-after-free in inet_create+0xbcc/0xd28
net/ipv4/af_inet.c:340
Read of size 4 at addr ffff8003496a4684 by task kworker/u8:4/3721

CPU: 3 PID: 3721 Comm: kworker/u8:4 Not tainted 5.1.0 #11
Hardware name: linux,dummy-virt (DT)
Workqueue: krdsd rds_connect_worker
Call trace:
 dump_backtrace+0x0/0x3c0 arch/arm64/kernel/time.c:53
 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:152
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x120/0x188 lib/dump_stack.c:113
 print_address_description+0x68/0x278 mm/kasan/report.c:253
 kasan_report_error mm/kasan/report.c:351 [inline]
 kasan_report+0x21c/0x348 mm/kasan/report.c:409
 __asan_report_load4_noabort+0x30/0x40 mm/kasan/report.c:429
 inet_create+0xbcc/0xd28 net/ipv4/af_inet.c:340
 __sock_create+0x4f8/0x770 net/socket.c:1276
 sock_create_kern+0x50/0x68 net/socket.c:1322
 rds_tcp_conn_path_connect+0x2b4/0x690 net/rds/tcp_connect.c:114
 rds_connect_worker+0x108/0x1d0 net/rds/threads.c:175
 process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153
 worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296
 kthread+0x2f0/0x378 kernel/kthread.c:255
 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117

Allocated by task 687:
 save_stack mm/kasan/kasan.c:448 [inline]
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:553
 kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:490
 slab_post_alloc_hook mm/slab.h:444 [inline]
 slab_alloc_node mm/slub.c:2705 [inline]
 slab_alloc mm/slub.c:2713 [inline]
 kmem_cache_alloc+0x14c/0x388 mm/slub.c:2718
 kmem_cache_zalloc include/linux/slab.h:697 [inline]
 net_alloc net/core/net_namespace.c:384 [inline]
 copy_net_ns+0xc4/0x2d0 net/core/net_namespace.c:424
 create_new_namespaces+0x300/0x658 kernel/nsproxy.c:107
 unshare_nsproxy_namespaces+0xa0/0x198 kernel/nsproxy.c:206
 ksys_unshare+0x340/0x628 kernel/fork.c:2577
 __do_sys_unshare kernel/fork.c:2645 [inline]
 __se_sys_unshare kernel/fork.c:2643 [inline]
 __arm64_sys_unshare+0x38/0x58 kernel/fork.c:2643
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall arch/arm64/kernel/syscall.c:47 [inline]
 el0_svc_common+0x168/0x390 arch/arm64/kernel/syscall.c:83
 el0_svc_handler+0x60/0xd0 arch/arm64/kernel/syscall.c:129
 el0_svc+0x8/0xc arch/arm64/kernel/entry.S:960

Freed by task 264:
 save_stack mm/kasan/kasan.c:448 [inline]
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free+0x114/0x220 mm/kasan/kasan.c:521
 kasan_slab_free+0x10/0x18 mm/kasan/kasan.c:528
 slab_free_hook mm/slub.c:1370 [inline]
 slab_free_freelist_hook mm/slub.c:1397 [inline]
 slab_free mm/slub.c:2952 [inline]
 kmem_cache_free+0xb8/0x3a8 mm/slub.c:2968
 net_free net/core/net_namespace.c:400 [inline]
 net_drop_ns.part.6+0x78/0x90 net/core/net_namespace.c:407
 net_drop_ns net/core/net_namespace.c:406 [inline]
 cleanup_net+0x53c/0x6d8 net/core/net_namespace.c:569
 process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153
 worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296
 kthread+0x2f0/0x378 kernel/kthread.c:255
 ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117

The buggy address belongs to the object at ffff8003496a3f80
 which belongs to the cache net_namespace of size 7872
The buggy address is located 1796 bytes inside of
 7872-byte region [ffff8003496a3f80ffff8003496a5e40)
The buggy address belongs to the page:
page:ffff7e000d25a800 count:1 mapcount:0 mapping:ffff80036ce4b000
index:0x0 compound_mapcount: 0
flags: 0xffffe0000008100(slab|head)
raw: 0ffffe0000008100 dead000000000100 dead000000000200 ffff80036ce4b000
raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8003496a4580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8003496a4600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff8003496a4680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                   ^
 ffff8003496a4700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8003496a4780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Fixes: 467fa15356ac("RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cb66ddd156203daefb8d71158036b27b0e2caf63)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agodrm/i915: Skip modeset for cdclk changes if possible
Ville Syrjälä [Mon, 10 Jun 2019 07:14:00 +0000 (09:14 +0200)]
drm/i915: Skip modeset for cdclk changes if possible

BugLink: https://launchpad.net/bugs/1826868
If we have only a single active pipe and the cdclk change only requires
the cd2x divider to be updated bxt+ can do the update with forcing a full
modeset on the pipe. Try to hook that up.

v2:
- Wait for vblank after an optimized CDCLK change.
- Avoid optimization if the pipe needs a modeset (or was disabled).
- Split CDCLK change to a pre/post plane update step.
v3:
- Use correct version of CDCLK state as old state. (Ville)
- Remove unused intel_cdclk_can_skip_modeset()
v4:
- For consistency call intel_set_cdclk_post_plane_update() only during
  modesets (and not fastsets).
v5:
- Remove the logic to update the CD2X divider on-the-fly on ICL, since
  only a divider of 1 is supported there. Clint also noticed that the
  pipe select bits in CDCLK_CTL are oddly defined on ICL, it's not clear
  yet whether that's only an error in the specification.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Tested-by: Abhay Kumar <abhay.kumar@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190327101321.3095-1-imre.deak@intel.com
(backported from commit 59f9e9cab3a1e6762fb707d0d829b982930f1349)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agodrm/i915: Remove redundant store of logical CDCLK state
Imre Deak [Mon, 10 Jun 2019 07:14:00 +0000 (09:14 +0200)]
drm/i915: Remove redundant store of logical CDCLK state

BugLink: https://launchpad.net/bugs/1826868
We copied the original state into the atomic state already earlier in
the function, so no need to do it a second time.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190320135439.12201-3-imre.deak@intel.com
(backported from commit 2b21dfbeee725778daed2c3dd45a3fc808176feb)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agodrm/i915: Save the old CDCLK atomic state
Imre Deak [Mon, 10 Jun 2019 07:14:00 +0000 (09:14 +0200)]
drm/i915: Save the old CDCLK atomic state

BugLink: https://launchpad.net/bugs/1826868
The old state will be needed by an upcoming patch to determine if the
commit increases or decreases CDCLK, so move the old state to the atomic
state (while keeping the new one in dev_priv). cdclk.logical and
cdclk.actual in the atomic state isn't used atm anywhere after the
atomic check phase, so this should be safe.

v2:
- Use swap() instead of opencoding it. (Ville)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190320135439.12201-2-imre.deak@intel.com
(backported from commit 48d9f87ddd2108663fd866b254e05d422243cc56)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agodrm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
Ville Syrjälä [Mon, 10 Jun 2019 07:14:00 +0000 (09:14 +0200)]
drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled

BugLink: https://launchpad.net/bugs/1826868
CDCLK has to be at least twice the BLCK regardless of audio. Audio
driver has to probe using this hook and increase the clock even in
absence of any display.

v2: Use atomic refcount for get_power, put_power so that we can
    call each once(Abhay).
v3: Reset power well 2 to avoid any transaction on iDisp link
    during cdclk change(Abhay).
v4: Remove Power well 2 reset workaround(Ville).
v5: Remove unwanted Power well 2 register defined in v4(Abhay).
v6:
- Use a dedicated flag instead of state->modeset for min CDCLK changes
- Make get/put audio power domain symmetric
- Rebased on top of intel_wakeref tracking changes.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Tested-by: Abhay Kumar <abhay.kumar@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190320135439.12201-1-imre.deak@intel.com
(backported from commit 905801fe72377b4dc53c6e13eea1a91c6a4aa0c4)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agosysctl: handle overflow in proc_get_long
Christian Brauner [Fri, 28 Jun 2019 07:42:00 +0000 (09:42 +0200)]
sysctl: handle overflow in proc_get_long

BugLink: https://bugs.launchpad.net/bugs/1833935
proc_get_long() is a funny function.  It uses simple_strtoul() and for a
good reason.  proc_get_long() wants to always succeed the parse and
return the maybe incorrect value and the trailing characters to check
against a pre-defined list of acceptable trailing values.  However,
simple_strtoul() explicitly ignores overflows which can cause funny
things like the following to happen:

  echo 18446744073709551616 > /proc/sys/fs/file-max
  cat /proc/sys/fs/file-max
  0

(Which will cause your system to silently die behind your back.)

On the other hand kstrtoul() does do overflow detection but does not
return the trailing characters, and also fails the parse when anything
other than '\n' is a trailing character whereas proc_get_long() wants to
be more lenient.

Now, before adding another kstrtoul() function let's simply add a static
parse strtoul_lenient() which:
 - fails on overflow with -ERANGE
 - returns the trailing characters to the caller

The reason why we should fail on ERANGE is that we already do a partial
fail on overflow right now.  Namely, when the TMPBUFLEN is exceeded.  So
we already reject values such as 184467440737095516160 (21 chars) but
accept values such as 18446744073709551616 (20 chars) but both are
overflows.  So we should just always reject 64bit overflows and not
special-case this based on the number of chars.

Link: http://lkml.kernel.org/r/20190107222700.15954-2-christian@brauner.io
Signed-off-by: Christian Brauner <christian@brauner.io>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Waiman Long <longman@redhat.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7f2923c4f73f21cfd714d12a2d48de8c21f11cfe)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonvme-pci: Use host managed power state for suspend
Keith Busch [Thu, 23 May 2019 15:27:35 +0000 (09:27 -0600)]
nvme-pci: Use host managed power state for suspend

BugLink: https://bugs.launchpad.net/bugs/1808957
The nvme pci driver prepares its devices for power loss during suspend
by shutting down the controllers. The power setting is deferred to
pci driver's power management before the platform removes power. The
suspend-to-idle mode, however, does not remove power.

NVMe devices that implement host managed power settings can achieve
lower power and better transition latencies than using generic PCI power
settings. Try to use this feature if the platform is not involved with
the suspend. If successful, restore the previous power state on resume.

Cc: Mario Limonciello <Mario.Limonciello@dell.com>
Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Mario Limonciello <mario.limonciello@dell.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
(backported from commit a0805317252ad9cf09d4a32b0435e165580adf8a git://git.infradead.org/nvme nvme-5.3)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonvme: Export get and set features
Keith Busch [Sun, 26 May 2019 16:29:01 +0000 (01:29 +0900)]
nvme: Export get and set features

BugLink: https://bugs.launchpad.net/bugs/1808957
Future use intends to make use of both, so export these functions. And
since their implementation is identical except for the opcode, provide a
new function that implement both.

[akinobu.mita@gmail.com>: fix line over 80 characters]
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
(backported from commit 82b17aebf68d572d73359a68376024ec1b5294c5 git://git.infradead.org/nvme nvme-5.3)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonvme-pci: Sync queues on reset
Keith Busch [Tue, 14 May 2019 20:46:09 +0000 (14:46 -0600)]
nvme-pci: Sync queues on reset

BugLink: https://bugs.launchpad.net/bugs/1808957
A controller with multiple namespaces may have multiple request_queues with
their own timeout work. If a controller fails with IO outstanding to
diffent namespaces, each request queue may attempt to handle it, so
ensure there is no previously scheduled timeout work executing prior to
starting controller initialization by synchronizing with each queue.

Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <keith.busch@intel.com>
(backported from commit d6135c3a1ec0cddda7b8b8e1b5b4abeeafd98289)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoPCI: PM: Skip devices in D0 for suspend-to-idle
Rafael J. Wysocki [Thu, 13 Jun 2019 21:59:45 +0000 (23:59 +0200)]
PCI: PM: Skip devices in D0 for suspend-to-idle

BugLink: https://bugs.launchpad.net/bugs/1808957
Patchwork: https://patchwork.kernel.org/patch/10993697/

Commit d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
attempted to avoid a problem with devices whose drivers want them to
stay in D0 over suspend-to-idle and resume, but it did not go as far
as it should with that.

Namely, first of all, the power state of a PCI bridge with a
downstream device in D0 must be D0 (based on the PCI PM spec r1.2,
sec 6, table 6-1, if the bridge is not in D0, there can be no PCI
transactions on its secondary bus), but that is not actively enforced
during system-wide PM transitions, so use the skip_bus_pm flag
introduced by commit d491f2b75237 for that.

Second, the configuration of devices left in D0 (whatever the reason)
during suspend-to-idle need not be changed and attempting to put them
into D0 again by force is pointless, so explicitly avoid doing that.

Fixes: d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue")
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from commit 3e26c5feed2add218046ecf91bab3cfa9bf762a6)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoPCI: PM: Avoid possible suspend-to-idle issue
Rafael J. Wysocki [Fri, 17 May 2019 09:08:50 +0000 (11:08 +0200)]
PCI: PM: Avoid possible suspend-to-idle issue

BugLink: https://bugs.launchpad.net/bugs/1808957
If a PCI driver leaves the device handled by it in D0 and calls
pci_save_state() on the device in its ->suspend() or ->suspend_late()
callback, it can expect the device to stay in D0 over the whole
s2idle cycle.  However, that may not be the case if there is a
spurious wakeup while the system is suspended, because in that case
pci_pm_suspend_noirq() will run again after pci_pm_resume_noirq()
which calls pci_restore_state(), via pci_pm_default_resume_early(),
so state_saved is cleared and the second iteration of
pci_pm_suspend_noirq() will invoke pci_prepare_to_sleep() which
may change the power state of the device.

To avoid that, add a new internal flag, skip_bus_pm, that will be set
by pci_pm_suspend_noirq() when it runs for the first time during the
given system suspend-resume cycle if the state of the device has
been saved already and the device is still in D0.  Setting that flag
will cause the next iterations of pci_pm_suspend_noirq() to set
state_saved for pci_pm_resume_noirq(), so that it always restores the
device state from the originally saved data, and avoid calling
pci_prepare_to_sleep() for the device.

Fixes: 33e4f80ee69b ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Keith Busch <keith.busch@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
(cherry picked from commit d491f2b75237ef37d8867830ab7fad8d9659e853)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoRevert "SAUCE: pci: prevent sk hynix nvme from entering D3"
Kai-Heng Feng [Mon, 10 Jun 2019 04:51:34 +0000 (12:51 +0800)]
Revert "SAUCE: pci: prevent sk hynix nvme from entering D3"

BugLink: https://bugs.launchpad.net/bugs/1808957
This reverts commit 623453990672ee8767a51f6e80c8927c42dfc1d5.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoRevert "SAUCE: nvme: add quirk to not call disable function when suspending"
Kai-Heng Feng [Mon, 10 Jun 2019 04:51:29 +0000 (12:51 +0800)]
Revert "SAUCE: nvme: add quirk to not call disable function when suspending"

BugLink: https://bugs.launchpad.net/bugs/1808957
This reverts commit 1a862bc878ee4b3d2d211d7ecb34839c30b9cd28.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoRevert "UBUNTU: SAUCE: pci: prevent Intel NVMe SSDPEKKF from entering D3"
Kai-Heng Feng [Mon, 10 Jun 2019 04:50:42 +0000 (12:50 +0800)]
Revert "UBUNTU: SAUCE: pci: prevent Intel NVMe SSDPEKKF from entering D3"

BugLink: https://bugs.launchpad.net/bugs/1808957
This reverts commit a663c29bb6c09fe84d05e4f5087a82e586a88fe2.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoRevert "UBUNTU: SAUCE: nvme: add quirk to not call disable function when suspending"
Kai-Heng Feng [Mon, 10 Jun 2019 04:50:35 +0000 (12:50 +0800)]
Revert "UBUNTU: SAUCE: nvme: add quirk to not call disable function when suspending"

BugLink: https://bugs.launchpad.net/bugs/1808957
This reverts commit 5277ad40aa618b25c4a0bb6b3826cc2a0d004464.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoRevert "UBUNTU: SAUCE: pci/nvme: prevent WDC PC SN720 NVMe from entering D3 and being...
Kai-Heng Feng [Mon, 10 Jun 2019 04:49:55 +0000 (12:49 +0800)]
Revert "UBUNTU: SAUCE: pci/nvme: prevent WDC PC SN720 NVMe from entering D3 and being disabled"

BugLink: https://bugs.launchpad.net/bugs/1808957
This reverts commit 337d3ee0a670b1a28bb2ebadff134b00319afdc1.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoselinux: use kernel linux/socket.h for genheaders and mdp
Paulo Alcantara [Thu, 6 Jun 2019 13:03:00 +0000 (15:03 +0200)]
selinux: use kernel linux/socket.h for genheaders and mdp

BugLink: https://bugs.launchpad.net/bugs/1823429
When compiling genheaders and mdp from a newer host kernel, the
following error happens:

    In file included from scripts/selinux/genheaders/genheaders.c:18:
    ./security/selinux/include/classmap.h:238:2: error: #error New
    address family defined, please update secclass_map.  #error New
    address family defined, please update secclass_map.  ^~~~~
    make[3]: *** [scripts/Makefile.host:107:
    scripts/selinux/genheaders/genheaders] Error 1 make[2]: ***
    [scripts/Makefile.build:599: scripts/selinux/genheaders] Error 2
    make[1]: *** [scripts/Makefile.build:599: scripts/selinux] Error 2
    make[1]: *** Waiting for unfinished jobs....

Instead of relying on the host definition, include linux/socket.h in
classmap.h to have PF_MAX.

Cc: stable@vger.kernel.org
Signed-off-by: Paulo Alcantara <paulo@paulo.ac>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
[PM: manually merge in mdp.c, subject line tweaks]
Signed-off-by: Paul Moore <paul@paul-moore.com>
(cherry picked from commit dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e)
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
[ kleber: fix BugLink reference. ]
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agox86/mm: Use WRITE_ONCE() when setting PTEs
Nadav Amit [Fri, 14 Jun 2019 08:55:06 +0000 (10:55 +0200)]
x86/mm: Use WRITE_ONCE() when setting PTEs

BugLink: https://bugs.launchpad.net/bugs/1830433
When page-table entries are set, the compiler might optimize their
assignment by using multiple instructions to set the PTE. This might
turn into a security hazard if the user somehow manages to use the
interim PTE. L1TF does not make our lives easier, making even an interim
non-present PTE a security hazard.

Using WRITE_ONCE() to set PTEs and friends should prevent this potential
security hazard.

I skimmed the differences in the binary with and without this patch. The
differences are (obviously) greater when CONFIG_PARAVIRT=n as more
code optimizations are possible. For better and worse, the impact on the
binary with this patch is pretty small. Skimming the code did not cause
anything to jump out as a security hazard, but it seems that at least
move_soft_dirty_pte() caused set_pte_at() to use multiple writes.

Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180902181451.80520-1-namit@vmware.com
(backported from commit 9bc4f28af75a91aea0ae383f50b0a430c4509303)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agox86/mm: provide pmdp_establish() helper
Kirill A. Shutemov [Fri, 14 Jun 2019 08:55:05 +0000 (10:55 +0200)]
x86/mm: provide pmdp_establish() helper

BugLink: https://bugs.launchpad.net/bugs/1830433
We need an atomic way to setup pmd page table entry, avoiding races with
CPU setting dirty/accessed bits.  This is required to implement
pmdp_invalidate() that doesn't lose these bits.

On PAE we can avoid expensive cmpxchg8b for cases when new page table
entry is not present.  If it's present, fallback to cpmxchg loop.

[akpm@linux-foundation.org: add missing `do' to do-while loop]
Link: http://lkml.kernel.org/r/20171213105756.69879-10-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 86fa949b050184ffc53688516a6a83ae5f98d08a)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agox86/init: fix build with CONFIG_SWAP=n
Vlastimil Babka [Fri, 14 Jun 2019 08:55:04 +0000 (10:55 +0200)]
x86/init: fix build with CONFIG_SWAP=n

BugLink: https://bugs.launchpad.net/bugs/1830433
The introduction of generic_max_swapfile_size and arch-specific versions has
broken linking on x86 with CONFIG_SWAP=n due to undefined reference to
'generic_max_swapfile_size'. Fix it by compiling the x86-specific
max_swapfile_size() only with CONFIG_SWAP=y.

Reported-by: Tomas Pruzina <pruzinat@gmail.com>
Fixes: 377eeaa8e11f ("x86/speculation/l1tf: Limit swap file size to MAX_PA/2")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 792adb90fa724ce07c0171cbc96b9215af4b1045)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agox86/mm: Add TLB purge to free pmd/pte page interfaces
Toshi Kani [Fri, 14 Jun 2019 08:55:03 +0000 (10:55 +0200)]
x86/mm: Add TLB purge to free pmd/pte page interfaces

BugLink: https://bugs.launchpad.net/bugs/1830433
ioremap() calls pud_free_pmd_page() / pmd_free_pte_page() when it creates
a pud / pmd map.  The following preconditions are met at their entry.
 - All pte entries for a target pud/pmd address range have been cleared.
 - System-wide TLB purges have been peformed for a target pud/pmd address
   range.

The preconditions assure that there is no stale TLB entry for the range.
Speculation may not cache TLB entries since it requires all levels of page
entries, including ptes, to have P & A-bits set for an associated address.
However, speculation may cache pud/pmd entries (paging-structure caches)
when they have P-bit set.

Add a system-wide TLB purge (INVLPG) to a single page after clearing
pud/pmd entry's P-bit.

SDM 4.10.4.1, Operation that Invalidate TLBs and Paging-Structure Caches,
states that:
  INVLPG invalidates all paging-structure caches associated with the
  current PCID regardless of the liner addresses to which they correspond.

Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: mhocko@suse.com
Cc: akpm@linux-foundation.org
Cc: hpa@zytor.com
Cc: cpandya@codeaurora.org
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Joerg Roedel <joro@8bytes.org>
Cc: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20180627141348.21777-4-toshi.kani@hpe.com
(cherry picked from commit 5e0fb5df2ee871b841f96f9cb6a7f2784e96aa4e)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agoioremap: Update pgtable free interfaces with addr
Chintan Pandya [Fri, 14 Jun 2019 08:55:02 +0000 (10:55 +0200)]
ioremap: Update pgtable free interfaces with addr

BugLink: https://bugs.launchpad.net/bugs/1830433
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.

 1. ioremap with 4K size, a valid pte page table is set.
 2. iounmap it, its pte entry is set to 0.
 3. ioremap the same address with 2M size, update its pmd entry with
    a new value.
 4. CPU may hit an exception because the old pmd entry is still in TLB,
    which leads to a kernel panic.

Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
table") has addressed this panic by falling to pte mappings in the above
case on ARM64.

To support pmd mappings in all cases, TLB purge needs to be performed
in this case on ARM64.

Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
so that TLB purge can be added later in seprate patches.

[toshi.kani@hpe.com: merge changes, rewrite patch description]
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: mhocko@suse.com
Cc: akpm@linux-foundation.org
Cc: hpa@zytor.com
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20180627141348.21777-3-toshi.kani@hpe.com
(cherry picked from commit 785a19f9d1dd8a4ab2d0633be4656653bd3de1fc)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agox86/mm: Disable ioremap free page handling on x86-PAE
Toshi Kani [Fri, 14 Jun 2019 08:55:01 +0000 (10:55 +0200)]
x86/mm: Disable ioremap free page handling on x86-PAE

BugLink: https://bugs.launchpad.net/bugs/1830433
ioremap() supports pmd mappings on x86-PAE.  However, kernel's pmd
tables are not shared among processes on x86-PAE.  Therefore, any
update to sync'd pmd entries need re-syncing.  Freeing a pte page
also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one().

Disable free page handling on x86-PAE.  pud_free_pmd_page() and
pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present.
This assures that ioremap() does not update sync'd pmd entries at the
cost of falling back to pte mappings.

Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Reported-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: mhocko@suse.com
Cc: akpm@linux-foundation.org
Cc: hpa@zytor.com
Cc: cpandya@codeaurora.org
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20180627141348.21777-2-toshi.kani@hpe.com
(cherry picked from commit f967db0b9ed44ec3057a28f3b28efc51df51b835)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agox86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()
Dan Williams [Fri, 14 Jun 2019 08:55:00 +0000 (10:55 +0200)]
x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()

BugLink: https://bugs.launchpad.net/bugs/1830433
Commit:

  f77084d96355 "x86/mm/pat: Disable preemption around __flush_tlb_all()"

addressed a case where __flush_tlb_all() is called without preemption
being disabled. It also left a warning to catch other cases where
preemption is not disabled.

That warning triggers for the memory hotplug path which is also used for
persistent memory enabling:

 WARNING: CPU: 35 PID: 911 at ./arch/x86/include/asm/tlbflush.h:460
 RIP: 0010:__flush_tlb_all+0x1b/0x3a
 [..]
 Call Trace:
  phys_pud_init+0x29c/0x2bb
  kernel_physical_mapping_init+0xfc/0x219
  init_memory_mapping+0x1a5/0x3b0
  arch_add_memory+0x2c/0x50
  devm_memremap_pages+0x3aa/0x610
  pmem_attach_disk+0x585/0x700 [nd_pmem]

Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
and Dave confirmed the expectation for TLB flush is for modifying /
invalidating existing PTE entries, but not initial population [2]. Drop
the usage of __flush_tlb_all() in phys_{p4d,pud,pmd}_init() on the
expectation that this path is only ever populating empty entries for the
linear map. Note, at linear map teardown time there is a call to the
all-cpu flush_tlb_all() to invalidate the removed mappings.

[1]: https://lkml.kernel.org/r/9DFD717D-857D-493D-A606-B635D72BAC21@amacapital.net
[2]: https://lkml.kernel.org/r/749919a4-cdb1-48a3-adb4-adb81a5fa0b5@intel.com

[ mingo: Minor readability edits. ]

Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Reported-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave.hansen@intel.com
Fixes: f77084d96355 ("x86/mm/pat: Disable preemption around __flush_tlb_all()")
Link: http://lkml.kernel.org/r/154395944713.32119.15611079023837132638.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit ba6f508d0ec4adb09f0a939af6d5e19cdfa8667d)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agox86/mm/pat: Disable preemption around __flush_tlb_all()
Sebastian Andrzej Siewior [Fri, 14 Jun 2019 08:54:59 +0000 (10:54 +0200)]
x86/mm/pat: Disable preemption around __flush_tlb_all()

BugLink: https://bugs.launchpad.net/bugs/1830433
The WARN_ON_ONCE(__read_cr3() != build_cr3()) in switch_mm_irqs_off()
triggers every once in a while during a snapshotted system upgrade.

The warning triggers since commit decab0888e6e ("x86/mm: Remove
preempt_disable/enable() from __native_flush_tlb()"). The callchain is:

  get_page_from_freelist() -> post_alloc_hook() -> __kernel_map_pages()

with CONFIG_DEBUG_PAGEALLOC enabled.

Disable preemption during CR3 reset / __flush_tlb_all() and add a comment
why preemption has to be disabled so it won't be removed accidentaly.

Add another preemptible() check in __flush_tlb_all() to catch callers with
enabled preemption when PGE is enabled, because PGE enabled does not
trigger the warning in __native_flush_tlb(). Suggested by Andy Lutomirski.

Fixes: decab0888e6e ("x86/mm: Remove preempt_disable/enable() from __native_flush_tlb()")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181017103432.zgv46nlu3hc7k4rq@linutronix.de
(cherry picked from commit f77084d96355f5fba8e2c1fb3a51a393b1570de7)
Tested-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agohinic: fix a bug in set rx mode
Xue Chaojing [Tue, 18 Jun 2019 00:26:07 +0000 (18:26 -0600)]
hinic: fix a bug in set rx mode

BugLink: https://bugs.launchpad.net/bugs/1832048
in set_rx_mode, __dev_mc_sync and netdev_for_each_mc_addr will
repeatedly set the multicast mac address. so we delete this loop.

Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 66350023d57560b2ead168af098fc507e58d8e6a linux-next)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agodrm/radeon: prefer lower reference dividers
Christian König [Tue, 18 Jun 2019 03:10:21 +0000 (11:10 +0800)]
drm/radeon: prefer lower reference dividers

BugLink: https://bugs.launchpad.net/bugs/1791312
Instead of the closest reference divider prefer the lowest,
this fixes flickering issues on HP Compaq nx9420.

Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108514
Suggested-by: Paul Dufresne <dufresnep@gmail.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 2e26ccb119bde03584be53406bbd22e711b0d6e6)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agodrm/vmwgfx: use monotonic event timestamps
Arnd Bergmann [Fri, 21 Jun 2019 00:26:41 +0000 (20:26 -0400)]
drm/vmwgfx: use monotonic event timestamps

BugLink: https://launchpad.net/bugs/1832138
DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
seconds/microseconds format.

As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps"), other DRM drivers use monotonic times for drm_event_vblank,
but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
the y2038/y2106 overflow as well as time jumps.

For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
which solves those problems and avoids the deprecated do_gettimeofday()
function.

This should be transparent to to user space, as long as it doesn't
compare the time against the result of gettimeofday().

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
(cherry picked from commit 37efe80ce85f76b3b30d7b4ea40550e6a5a5b71a)
Signed-off-by: Eric Desrochers <eric.desrochers@canonical.com>
Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
7 weeks agoblock/bio: Do not zero user pages
Keith Busch [Thu, 27 Jun 2019 18:16:00 +0000 (20:16 +0200)]
block/bio: Do not zero user pages

BugLink: http://bugs.launchpad.net/bugs/1834499
We don't need to zero fill the bio if not using kernel allocated pages.

Fixes: f3587d76da05 ("block: Clear kernel memory before copying to user") # v4.20-rc2
Reported-by: Todd Aiken <taiken@mvtech.ca>
Cc: Laurence Oberman <loberman@redhat.com>
Cc: stable@vger.kernel.org
Cc: Bart Van Assche <bvanassche@acm.org>
Tested-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit f55adad601c6a97c8c9628195453e0fb23b4a0ae)
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoblock: Clear kernel memory before copying to user
Keith Busch [Thu, 27 Jun 2019 18:16:00 +0000 (20:16 +0200)]
block: Clear kernel memory before copying to user

BugLink: http://bugs.launchpad.net/bugs/1834499
If the kernel allocates a bounce buffer for user read data, this memory
needs to be cleared before copying it to the user, otherwise it may leak
kernel memory to user space.

Laurence Oberman <loberman@redhat.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit f3587d76da05f68098ddb1cb3c98cc6a9e8a402c)
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoUBUNTU: [Config] CONFIG_LOG_BUF_SHIFT=18 on all 64bit arches
Dan Streetman [Sun, 2 Jun 2019 14:10:00 +0000 (16:10 +0200)]
UBUNTU: [Config] CONFIG_LOG_BUF_SHIFT=18 on all 64bit arches

BugLink: https://bugs.launchpad.net/bugs/1824864
All other archs have this value set higher, and the low value of 14
results in a log buffer so small it fills up before systemd-journald
can start and read all the boot time kernel log messages.

Increasing this will result in more memory reserved for the log buffer,
but will avoid missed kernel log messages.

This changes all 64 bit archs to use a shift of 18, which is what
amd64 has been using.

Signed-off-by: Dan Streetman <ddstreet@canonical.com>
Cc: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
[ kleber: fixed subject line. ]
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agokernel/sysctl.c: fix out-of-bounds access when setting file-max
Will Deacon [Fri, 28 Jun 2019 08:24:00 +0000 (10:24 +0200)]
kernel/sysctl.c: fix out-of-bounds access when setting file-max

BugLink: https://bugs.launchpad.net/bugs/1834310
Commit 32a5ad9c2285 ("sysctl: handle overflow for file-max") hooked up
min/max values for the file-max sysctl parameter via the .extra1 and
.extra2 fields in the corresponding struct ctl_table entry.

Unfortunately, the minimum value points at the global 'zero' variable,
which is an int.  This results in a KASAN splat when accessed as a long
by proc_doulongvec_minmax on 64-bit architectures:

  | BUG: KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax+0x5d8/0x6a0
  | Read of size 8 at addr ffff2000133d1c20 by task systemd/1
  |
  | CPU: 0 PID: 1 Comm: systemd Not tainted 5.1.0-rc3-00012-g40b114779944 #2
  | Hardware name: linux,dummy-virt (DT)
  | Call trace:
  |  dump_backtrace+0x0/0x228
  |  show_stack+0x14/0x20
  |  dump_stack+0xe8/0x124
  |  print_address_description+0x60/0x258
  |  kasan_report+0x140/0x1a0
  |  __asan_report_load8_noabort+0x18/0x20
  |  __do_proc_doulongvec_minmax+0x5d8/0x6a0
  |  proc_doulongvec_minmax+0x4c/0x78
  |  proc_sys_call_handler.isra.19+0x144/0x1d8
  |  proc_sys_write+0x34/0x58
  |  __vfs_write+0x54/0xe8
  |  vfs_write+0x124/0x3c0
  |  ksys_write+0xbc/0x168
  |  __arm64_sys_write+0x68/0x98
  |  el0_svc_common+0x100/0x258
  |  el0_svc_handler+0x48/0xc0
  |  el0_svc+0x8/0xc
  |
  | The buggy address belongs to the variable:
  |  zero+0x0/0x40
  |
  | Memory state around the buggy address:
  |  ffff2000133d1b00: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa
  |  ffff2000133d1b80: fa fa fa fa 04 fa fa fa fa fa fa fa 04 fa fa fa
  | >ffff2000133d1c00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
  |                                ^
  |  ffff2000133d1c80: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 00 00
  |  ffff2000133d1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Fix the splat by introducing a unsigned long 'zero_ul' and using that
instead.

Link: http://lkml.kernel.org/r/20190403153409.17307-1-will.deacon@arm.com
Fixes: 32a5ad9c2285 ("sysctl: handle overflow for file-max")
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Christian Brauner <christian@brauner.io>
Cc: Kees Cook <keescook@chromium.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Matteo Croce <mcroce@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 9002b21465fa4d829edfc94a5a441005cffaa972)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agosysctl: handle overflow for file-max
Christian Brauner [Fri, 28 Jun 2019 08:24:00 +0000 (10:24 +0200)]
sysctl: handle overflow for file-max

BugLink: https://bugs.launchpad.net/bugs/1834310
Currently, when writing

  echo 18446744073709551616 > /proc/sys/fs/file-max

/proc/sys/fs/file-max will overflow and be set to 0.  That quickly
crashes the system.

This commit sets the max and min value for file-max.  The max value is
set to long int.  Any higher value cannot currently be used as the
percpu counters are long ints and not unsigned integers.

Note that the file-max value is ultimately parsed via
__do_proc_doulongvec_minmax().  This function does not report error when
min or max are exceeded.  Which means if a value largen that long int is
written userspace will not receive an error instead the old value will be
kept.  There is an argument to be made that this should be changed and
__do_proc_doulongvec_minmax() should return an error when a dedicated min
or max value are exceeded.  However this has the potential to break
userspace so let's defer this to an RFC patch.

Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io
Signed-off-by: Christian Brauner <christian@brauner.io>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Waiman Long <longman@redhat.com>
[christian@brauner.io: v4]
Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoALSA: hda/realtek - Corrected fixup for System76 Gazelle (gaze14)
Jeremy Soller [Wed, 5 Jun 2019 17:54:00 +0000 (19:54 +0200)]
ALSA: hda/realtek - Corrected fixup for System76 Gazelle (gaze14)

BugLink: https://bugs.launchpad.net/bugs/1827555
A mistake was made in the identification of the four variants of the
System76 Gazelle (gaze14). This patch corrects the PCI ID of the
17-inch, GTX 1660 Ti variant from 0x8560 to 0x8551. This patch also
adds the correct fixups for the 15-inch and 17-inch GTX 1650 variants
with PCI IDs 0x8560 and 0x8561.

Tests were done on all four variants ensuring full audio capability.

Fixes: 80a5052db751 ("ALSA: hdea/realtek - Headset fixup for System76 Gazelle (gaze14)")
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 891afcf2462d2cc4ef7caf94215358ca61fa32cb)
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoALSA: hda/realtek - Headset fixup for System76 Gazelle (gaze14)
Jeremy Soller [Wed, 5 Jun 2019 17:54:00 +0000 (19:54 +0200)]
ALSA: hda/realtek - Headset fixup for System76 Gazelle (gaze14)

BugLink: https://bugs.launchpad.net/bugs/1827555
On the System76 Gazelle (gaze14), there is a headset microphone input
attached to 0x1a that does not have a jack detect. In order to get it
working, the pin configuration needs to be set correctly, and the
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC fixup needs to be applied. This is
identical to the patch already applied for the System76 Darter Pro
(darp5).

Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 80a5052db75131423b67f38b21958555d7d970e4)
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoiommu/arm-smmu-v3: Don't disable SMMU in kdump kernel
Will Deacon [Mon, 3 Jun 2019 21:16:00 +0000 (23:16 +0200)]
iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel

BugLink: https://bugs.launchpad.net/bugs/1828868
Disabling the SMMU when probing from within a kdump kernel so that all
incoming transactions are terminated can prevent the core of the crashed
kernel from being transferred off the machine if all I/O devices are
behind the SMMU.

Instead, continue to probe the SMMU after it is disabled so that we can
reinitialise it entirely and re-attach the DMA masters as they are reset.
Since the kdump kernel may not have drivers for all of the active DMA
masters, we suppress fault reporting to avoid spamming the console and
swamping the IRQ threads.

Reported-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
Tested-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
(cherry picked from commit 3f54c447df34ff9efac7809a4a80fd3208efc619)
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoiommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel
Will Deacon [Mon, 3 Jun 2019 21:16:00 +0000 (23:16 +0200)]
iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel

BugLink: https://bugs.launchpad.net/bugs/1828868
If we find that the SMMU is enabled during probe, we reset it by
re-initialising its registers and either enabling translation or placing
it into bypass based on the disable_bypass commandline option.

In the case of a kdump kernel, the SMMU won't have been shutdown cleanly
by the previous kernel and there may be concurrent DMA through the SMMU.
Rather than reset the SMMU to bypass, which would likely lead to rampant
data corruption, we can instead configure the SMMU to abort all incoming
transactions when we find that it is enabled from within a kdump kernel.

Reported-by: Sameer Goel <sgoel@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
(backported from commit b63b3439b85609338e4faabd5d2588dbda137e5c)
[ dannf: trivial offset adjustment in #include section ]
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoext4: zero out the unused memory region in the extent tree block
Sriram Rajagopalan [Tue, 4 Jun 2019 06:08:00 +0000 (08:08 +0200)]
ext4: zero out the unused memory region in the extent tree block

CVE-2019-11833

This commit zeroes out the unused memory region in the buffer_head
corresponding to the extent metablock after writing the extent header
and the corresponding extent node entries.

This is done to prevent random uninitialized data from getting into
the filesystem when the extent block is synced.

This fixes CVE-2019-11833.

Signed-off-by: Sriram Rajagopalan <sriramr@arista.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
(cherry picked from commit 592acbf16821288ecdc4192c47e3774a4c48bb64)
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoUBUNTU: SAUCE: (noup) Update zfs to 0.7.5-1ubuntu16.6
Colin Ian King [Thu, 30 May 2019 12:57:00 +0000 (14:57 +0200)]
UBUNTU: SAUCE: (noup) Update zfs to 0.7.5-1ubuntu16.6

BugLink: https://bugs.launchpad.net/bugs/1772412
Sync from zfs 0.7.5-1ubuntu16.6 that contains a backport of upstream zfs
commit 77d8a0f1a4d0b2f59cee63088f7987cb38e66538 ("Fix hung z_zvol tasks
during 'zfs receive'").

Adds a dedicated, per-pool, prefetch taskq to prevent the traverse
code from monopolizing the global (and limited) system_taskq by
inappropriately scheduling long running tasks on it. This fixes
z_zvol hung tasks when performing large I/O operations, for example
when performing huge ZFS send/receives (on slow media).

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoALSA: hda/realtek - Use a common helper for hp pin reference
Takashi Iwai [Thu, 30 May 2019 12:00:00 +0000 (14:00 +0200)]
ALSA: hda/realtek - Use a common helper for hp pin reference

BugLink: https://launchpad.net/bugs/1831065
Replace the open-codes in many places with a new common helper for
performing the same thing: referring to the primary headphone pin.

This eventually fixes the potentially missing headphone pin on some
weird devices, too.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 35a39f98567d8d3f1cea48f0f30de1a7e736b644)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Anthony Wong <anthony.wong@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoALSA: hda/realtek - Fixed hp_pin no value
Kailang Yang [Thu, 30 May 2019 11:59:00 +0000 (13:59 +0200)]
ALSA: hda/realtek - Fixed hp_pin no value

BugLink: https://launchpad.net/bugs/1831065
Fix hp_pin always no value.

[More notes on the changes:

 The hp_pin value that is referred in alc294_hp_init() is always zero
 at the moment the function gets called, hence this is actually
 useless as in the current code.

 And, this kind of init sequence should be called from the codec init
 callback, instead of the parser function.  So, the first fix in this
 patch to move the call call into its own init_hook.

 OTOH, this function is needed to be called only once after the boot,
 and it'd take too long for invoking at each resume (where the init
 callback gets called).  So we add a new flag and invoke this only
 once as an additional fix.

 The one case is still not covered, though: S4 resume.  But this
 change itself won't lead to any regression in that regard, so we
 leave S4 issue as is for now and fix it later.  -- tiwai ]

Fixes: bde1a7459623 ("ALSA: hda/realtek - Fixed headphone issue for ALC700")
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 693abe11aa6b27aed6eb8222162f8fb986325cef)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Anthony Wong <anthony.wong@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
[ kleber: context adjustments ]
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet_sched: fix two more memory leaks in cls_tcindex
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: fix two more memory leaks in cls_tcindex

BugLink: https://bugs.launchpad.net/bugs/1825942
struct tcindex_filter_result contains two parts:
struct tcf_exts and struct tcf_result.

For the local variable 'cr', its exts part is never used but
initialized without being released properly on success path. So
just completely remove the exts part to fix this leak.

For the local variable 'new_filter_result', it is never properly
released if not used by 'r' on success path.

Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1db817e75f5b9387b8db11e37d5f0624eb9223e0)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet_sched: initialize net pointer inside tcf_exts_init()
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: initialize net pointer inside tcf_exts_init()

BugLink: https://bugs.launchpad.net/bugs/1825942
For tcindex filter, it is too late to initialize the
net pointer in tcf_exts_validate(), as tcf_exts_get_net()
requires a non-NULL net pointer. We can just move its
initialization into tcf_exts_init(), which just requires
an additional parameter.

This makes the code in tcindex_alloc_perfect_hash()
prettier.

Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 14215108a1fd7e002c0a1f9faf8fbaf41fdda50d)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet_sched: fix a memory leak in cls_tcindex
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: fix a memory leak in cls_tcindex

BugLink: https://bugs.launchpad.net/bugs/1825942
When tcindex_destroy() destroys all the filter results in
the perfect hash table, it invokes the walker to delete
each of them. However, results with class==0 are skipped
in either tcindex_walk() or tcindex_delete(), which causes
a memory leak reported by kmemleak.

This patch fixes it by skipping the walker and directly
deleting these filter results so we don't miss any filter
result.

As a result of this change, we have to initialize exts->net
properly in tcindex_alloc_perfect_hash(). For net-next, we
need to consider whether we should initialize ->net in
tcf_exts_init() instead, before that just directly test
CONFIG_NET_CLS_ACT=y.

Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit 033b228e7f26b29ae37f8bfa1bc6b209a5365e9f)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet_sched: fix a race condition in tcindex_destroy()
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: fix a race condition in tcindex_destroy()

BugLink: https://bugs.launchpad.net/bugs/1825942
tcindex_destroy() invokes tcindex_destroy_element() via
a walker to delete each filter result in its perfect hash
table, and tcindex_destroy_element() calls tcindex_delete()
which schedules tcf RCU works to do the final deletion work.
Unfortunately this races with the RCU callback
__tcindex_destroy(), which could lead to use-after-free as
reported by Adrian.

Fix this by migrating this RCU callback to tcf RCU work too,
as that workqueue is ordered, we will not have use-after-free.

Note, we don't need to hold netns refcnt because we don't call
tcf_exts_destroy() here.

Fixes: 27ce4f05e2ab ("net_sched: use tcf_queue_work() in tcindex filter")
Reported-by: Adrian <bugs@abtelecom.ro>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8015d93ebd27484418d4952284fd02172fa4b0b2)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet_sched: switch to rcu_work
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: switch to rcu_work

BugLink: https://bugs.launchpad.net/bugs/1825942
Commit 05f0fe6b74db ("RCU, workqueue: Implement rcu_work") introduces
new API's for dispatching work in a RCU callback. Now we can just
switch to the new API's for tc filters. This could get rid of a lot
of code.

Cc: Tejun Heo <tj@kernel.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit aaa908ffbee18a65529b716efb346a626e81559a)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agoRCU, workqueue: Implement rcu_work
Tejun Heo [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
RCU, workqueue: Implement rcu_work

BugLink: https://bugs.launchpad.net/bugs/1825942
There are cases where RCU callback needs to be bounced to a sleepable
context.  This is currently done by the RCU callback queueing a work
item, which can be cumbersome to write and confusing to read.

This patch introduces rcu_work, a workqueue work variant which gets
executed after a RCU grace period, and converts the open coded
bouncing in fs/aio and kernel/cgroup.

v3: Dropped queue_rcu_work_on().  Documented rcu grace period behavior
    after queue_rcu_work().

v2: Use rcu_barrier() instead of synchronize_rcu() to wait for
    completion of previously queued rcu callback as per Paul.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 05f0fe6b74dbd7690a4cbd61810948b7d575576a)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
7 weeks agonet_sched: fix NULL pointer dereference when delete tcindex filter
Hangbin Liu [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: fix NULL pointer dereference when delete tcindex filter

BugLink: https://bugs.launchpad.net/bugs/1825942
Li Shuang reported the following crash:

[   71.267724] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
[   71.276456] PGD 800000085d9bd067 P4D 800000085d9bd067 PUD 859a0b067 PMD 0
[   71.284127] Oops: 0000 [#1] SMP PTI
[   71.288015] CPU: 12 PID: 2386 Comm: tc Not tainted 4.18.0-rc8.latest+ #131
[   71.295686] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.1.5 04/11/2016
[   71.304037] RIP: 0010:tcindex_delete+0x72/0x280 [cls_tcindex]
[   71.310446] Code: 00 31 f6 48 87 75 20 48 85 f6 74 11 48 8b 47 18 48 8b 40 08 48 8b 40 50 e8 fb a6 f8 fc 48 85 db 0f 84 dc 00 00 00 48 8b 73 18 <8b> 56 04 48 8d 7e 04 85 d2 0f 84 7b 01 00
[   71.331517] RSP: 0018:ffffb45207b3f898 EFLAGS: 00010282
[   71.337345] RAX: ffff8ad3d72d6360 RBX: ffff8acc84393680 RCX: 000000000000002e
[   71.345306] RDX: ffff8ad3d72c8570 RSI: 0000000000000000 RDI: ffff8ad847a45800
[   71.353277] RBP: ffff8acc84393688 R08: ffff8ad3d72c8400 R09: 0000000000000000
[   71.361238] R10: ffff8ad3de786e00 R11: 0000000000000000 R12: ffffb45207b3f8c7
[   71.369199] R13: ffff8ad3d93bd2a0 R14: 000000000000002e R15: ffff8ad3d72c9600
[   71.377161] FS:  00007f9d3ec3e740(0000) GS:ffff8ad3df980000(0000) knlGS:0000000000000000
[   71.386188] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   71.392597] CR2: 0000000000000004 CR3: 0000000852f06003 CR4: 00000000001606e0
[   71.400558] Call Trace:
[   71.403299]  tcindex_destroy_element+0x25/0x40 [cls_tcindex]
[   71.409611]  tcindex_walk+0xbb/0x110 [cls_tcindex]
[   71.414953]  tcindex_destroy+0x44/0x90 [cls_tcindex]
[   71.420492]  ? tcindex_delete+0x280/0x280 [cls_tcindex]
[   71.426323]  tcf_proto_destroy+0x16/0x40
[   71.430696]  tcf_chain_flush+0x51/0x70
[   71.434876]  tcf_block_put_ext.part.30+0x8f/0x1b0
[   71.440122]  tcf_block_put+0x4d/0x70
[   71.444108]  cbq_destroy+0x4d/0xd0 [sch_cbq]
[   71.448869]  qdisc_destroy+0x62/0x130
[   71.452951]  dsmark_destroy+0x2a/0x70 [sch_dsmark]
[   71.458300]  qdisc_destroy+0x62/0x130
[   71.462373]  qdisc_graft+0x3ba/0x470
[   71.466359]  tc_get_qdisc+0x2a6/0x2c0
[   71.470443]  ? cred_has_capability+0x7d/0x130
[   71.475307]  rtnetlink_rcv_msg+0x263/0x2d0
[   71.479875]  ? rtnl_calcit.isra.30+0x110/0x110
[   71.484832]  netlink_rcv_skb+0x4d/0x130
[   71.489109]  netlink_unicast+0x1a3/0x250
[   71.493482]  netlink_sendmsg+0x2ae/0x3a0
[   71.497859]  sock_sendmsg+0x36/0x40
[   71.501748]  ___sys_sendmsg+0x26f/0x2d0
[   71.506029]  ? handle_pte_fault+0x586/0xdf0
[   71.510694]  ? __handle_mm_fault+0x389/0x500
[   71.515457]  ? __sys_sendmsg+0x5e/0xa0
[   71.519636]  __sys_sendmsg+0x5e/0xa0
[   71.523626]  do_syscall_64+0x5b/0x180
[   71.527711]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   71.533345] RIP: 0033:0x7f9d3e257f10
[   71.537331] Code: c3 48 8b 05 82 6f 2c 00 f7 db 64 89 18 48 83 cb ff eb dd 0f 1f 80 00 00 00 00 83 3d 8d d0 2c 00 00 75 10 b8 2e 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8
[   71.558401] RSP: 002b:00007fff6f893398 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[   71.566848] RAX: ffffffffffffffda RBX: 000000005b71274d RCX: 00007f9d3e257f10
[   71.574810] RDX: 0000000000000000 RSI: 00007fff6f8933e0 RDI: 0000000000000003
[   71.582770] RBP: 00007fff6f8933e0 R08: 000000000000ffff R09: 0000000000000003
[   71.590729] R10: 00007fff6f892e20 R11: 0000000000000246 R12: 0000000000000000
[   71.598689] R13: 0000000000662ee0 R14: 0000000000000000 R15: 0000000000000000
[   71.606651] Modules linked in: sch_cbq cls_tcindex sch_dsmark xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_coni
[   71.685425]  libahci i2c_algo_bit i2c_core i40e libata dca mdio megaraid_sas dm_mirror dm_region_hash dm_log dm_mod
[   71.697075] CR2: 0000000000000004
[   71.700792] ---[ end trace f604eb1acacd978b ]---

Reproducer:
tc qdisc add dev lo handle 1:0 root dsmark indices 64 set_tc_index
tc filter add dev lo parent 1:0 protocol ip prio 1 tcindex mask 0xfc shift 2
tc qdisc add dev lo parent 1:0 handle 2:0 cbq bandwidth 10Mbit cell 8 avpkt 1000 mpu 64
tc class add dev lo parent 2:0 classid 2:1 cbq bandwidth 10Mbit rate 1500Kbit avpkt 1000 prio 1 bounded isolated allot 1514 weight 1 maxburst 10
tc filter add dev lo parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on
tc qdisc add dev lo parent 2:1 pfifo limit 5
tc qdisc del dev lo root

This is because in tcindex_set_parms, when there is no old_r, we set new
exts to cr.exts. And we didn't set it to filter when r == &new_filter_result.

Then in tcindex_delete() -> tcf_exts_get_net(), we will get NULL pointer
dereference as we didn't init exts.

Fix it by moving tcf_exts_change() after "if (old_r && old_r != r)" check.
Then we don't need "cr" as there is no errout after that.

Fixes: bf63ac73b3e13 ("net_sched: fix an oops in tcindex filter")
Reported-by: Li Shuang <shuali@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2df8bee5654bb2b7312662ca6810d4dc16b0b67f)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agoUSB: usb-storage: Add new ID to ums-realtek
Kai-Heng Feng [Thu, 6 Jun 2019 05:25:07 +0000 (13:25 +0800)]
USB: usb-storage: Add new ID to ums-realtek

BugLink: https://bugs.launchpad.net/bugs/1831840
There is one more Realtek card reader requires ums-realtek to work
correctly.

Add the device ID to support it.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1a6dd3fea131276a4fc44ae77b0f471b0b473577 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Kleber Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agoiommu/amd: Set exclusion range correctly
Joerg Roedel [Fri, 7 Jun 2019 17:47:27 +0000 (13:47 -0400)]
iommu/amd: Set exclusion range correctly

BugLink: https://bugs.launchpad.net/bugs/1823037
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.

So correctly set the exclusion range in the hardware to the
last page which is _in_ the range.

Fixes: b2026aa2dce44 ('x86, AMD IOMMU: add functions for programming IOMMU MMIO space')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 3c677d206210f53a4be972211066c0f1cd47fe12 )
Signed-off-by: Jeffrey Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agoiommu/amd: Reserve exclusion range in iova-domain
Joerg Roedel [Fri, 7 Jun 2019 17:47:26 +0000 (13:47 -0400)]
iommu/amd: Reserve exclusion range in iova-domain

BugLink: https://bugs.launchpad.net/bugs/1823037
If a device has an exclusion range specified in the IVRS
table, this region needs to be reserved in the iova-domain
of that device. This hasn't happened until now and can cause
data corruption on data transfered with these devices.

Treat exclusion ranges as reserved regions in the iommu-core
to fix the problem.

Fixes: be2a022c0dd0 ('x86, AMD IOMMU: add functions to parse IOMMU memory mapping requirements for devices')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Gary R Hook <gary.hook@amd.com>
(cherry picked from commit 8aafaaf2212192012f5bae305bb31cdf7681d777 )
Signed-off-by: Jeffrey Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agoALSA: hda/intel: add CometLake PCI IDs
Pierre-Louis Bossart [Tue, 11 Jun 2019 06:30:47 +0000 (14:30 +0800)]
ALSA: hda/intel: add CometLake PCI IDs

BugLink: https://launchpad.net/bugs/1832299
Add PCI IDs for LP and H skews.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit d4c2ccdb5855ce8786ebc66f7405096065d0c198)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agoALSA: hda: Add Icelake PCI ID
Guneshwor Singh [Tue, 11 Jun 2019 06:30:46 +0000 (14:30 +0800)]
ALSA: hda: Add Icelake PCI ID

BugLink: https://launchpad.net/bugs/1832299
Icelake is a next generation Intel platform. Add PCI ID for
it.

Signed-off-by: Guneshwor Singh <guneshwor.o.singh@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 491f833134ac474434e1c950925c58b2ac13ca72)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agosky2: Disable MSI on Dell Inspiron 1545 and Gateway P-79
Kai-Heng Feng [Thu, 13 Jun 2019 17:31:00 +0000 (01:31 +0800)]
sky2: Disable MSI on Dell Inspiron 1545 and Gateway P-79

Some sky2 chips fire IRQ after S3, before the driver is fully resumed:
[ 686.804877] do_IRQ: 1.37 No irq handler for vector

This is likely a platform bug that device isn't fully quiesced during
S3. Use MSI-X, maskable MSI or INTx can prevent this issue from
happening.

Since MSI-X and maskable MSI are not supported by this device, fallback
to use INTx on affected platforms.

BugLink: https://bugs.launchpad.net/bugs/1807259
BugLink: https://bugs.launchpad.net/bugs/1809843
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b33b7cd6fd86478dd2890a9abeb6f036aa01fdf7)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Khalid Elmously <khalid.elmously@canonical.com>
Acked-by: Kleber Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agomm/page_idle.c: fix oops because end_pfn is larger than max_pfn
Colin Ian King [Wed, 19 Jun 2019 13:30:32 +0000 (14:30 +0100)]
mm/page_idle.c: fix oops because end_pfn is larger than max_pfn

BugLink: https://bugs.launchpad.net/bugs/1833410
Currently the calcuation of end_pfn can round up the pfn number to more
than the actual maximum number of pfns, causing an Oops.  Fix this by
ensuring end_pfn is never more than max_pfn.

This can be easily triggered when on systems where the end_pfn gets
rounded up to more than max_pfn using the idle-page stress-ng stress test:

sudo stress-ng --idle-page 0

[ 3812.222790] BUG: unable to handle kernel paging request at 00000000000020d8
[ 3812.224341] #PF error: [normal kernel read fault]
[ 3812.225144] PGD 0 P4D 0
[ 3812.225626] Oops: 0000 [#1] SMP PTI
[ 3812.226264] CPU: 1 PID: 11039 Comm: stress-ng-idle- Not tainted 5.0.0-5-generic #6-Ubuntu
[ 3812.227643] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 3812.229286] RIP: 0010:page_idle_get_page+0xc8/0x1a0
[ 3812.230173] Code: 0f b1 0a 75 7d 48 8b 03 48 89 c2 48 c1 e8 33 83 e0 07 48 c1 ea 36 48 8d 0c 40 4c 8d 24 88 49 c1 e4 07 4c 03 24 d5 00 89 c3 be <49> 8b 44 24 58 48 8d b8 80 a1 02 00 e8 07 d5 77 00 48 8b 53 08 48
[ 3812.234641] RSP: 0018:ffffafd7c672fde8 EFLAGS: 00010202
[ 3812.235792] RAX: 0000000000000005 RBX: ffffe36341fff700 RCX: 000000000000000f
[ 3812.237739] RDX: 0000000000000284 RSI: 0000000000000275 RDI: 0000000001fff700
[ 3812.239225] RBP: ffffafd7c672fe00 R08: ffffa0bc34056410 R09: 0000000000000276
[ 3812.241027] R10: ffffa0bc754e9b40 R11: ffffa0bc330f6400 R12: 0000000000002080
[ 3812.242555] R13: ffffe36341fff700 R14: 0000000000080000 R15: ffffa0bc330f6400
[ 3812.244073] FS: 00007f0ec1ea5740(0000) GS:ffffa0bc7db00000(0000) knlGS:0000000000000000
[ 3812.245968] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3812.247162] CR2: 00000000000020d8 CR3: 0000000077d68000 CR4: 00000000000006e0
[ 3812.249045] Call Trace:
[ 3812.249625] page_idle_bitmap_write+0x8c/0x140
[ 3812.250567] sysfs_kf_bin_write+0x5c/0x70
[ 3812.251406] kernfs_fop_write+0x12e/0x1b0
[ 3812.252282] __vfs_write+0x1b/0x40
[ 3812.253002] vfs_write+0xab/0x1b0
[ 3812.253941] ksys_write+0x55/0xc0
[ 3812.254660] __x64_sys_write+0x1a/0x20
[ 3812.255446] do_syscall_64+0x5a/0x110
[ 3812.256254] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Link: http://lkml.kernel.org/r/20190618124352.28307-1-colin.king@canonical.com
Fixes: 33c3fc71c8cf ("mm: introduce idle page tracking")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
(cherry picked from commit d96d6145d9796d5f1eac242538d45559e9a23404 linux-next)
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit d96d6145d9796d5f1eac242538d45559e9a23404 linux-next)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agoUBUNTU: SAUCE: HID: multitouch: Add pointstick support for ALPS Touchpad
Kai-Heng Feng [Wed, 19 Jun 2019 07:51:07 +0000 (15:51 +0800)]
UBUNTU: SAUCE: HID: multitouch: Add pointstick support for ALPS Touchpad

BugLink: https://bugs.launchpad.net/bugs/1833387
Patchwork: https://patchwork.kernel.org/patch/10994741/

There's a new ALPS touchpad/pointstick combo device that requires
MT_CLS_WIN_8_DUAL to make its pointsitck work as a mouse.

The device can be found on HP ZBook 17 G5.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agoRevert "HID: multitouch: Support ALPS PTP stick with pid 0x120A"
Kai-Heng Feng [Wed, 19 Jun 2019 07:51:06 +0000 (15:51 +0800)]
Revert "HID: multitouch: Support ALPS PTP stick with pid 0x120A"

BugLink: https://bugs.launchpad.net/bugs/1833387
This reverts commit fcaa4a07d2a4b541e91da7a55d8b3331f96d1865.

As noted by Masaki [1], 0x120A + trackpoint will not be used in mass
production machines, so remove the ID accordingly.

[1] http://www.spinics.net/lists/linux-input/msg53222.html

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry picked from commit 66dcdafe8e251a3edc5d84cf725835567bd3dd35)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agoInput: elantech - enable middle button support on 2 ThinkPads
Aaron Ma [Fri, 21 Jun 2019 01:51:08 +0000 (09:51 +0800)]
Input: elantech - enable middle button support on 2 ThinkPads

BugLink: https://bugs.launchpad.net/bugs/1833637
Adding 2 new touchpad PNPIDs to enable middle button support.

Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit aa440de3058a3ef530851f9ef373fbb5f694dbc3)
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agodrm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on
Changbin Du [Tue, 11 Jun 2019 08:33:00 +0000 (10:33 +0200)]
drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on

When add 'x-no-mmap=on' for vfio-pci option, aperture access in guest
is emulated. But the vgpu_aperture_rw() function take wrong offset when
do memcpy, since vgpu->gm.aperture_va is not the base of entire aperture.
This mistake cause GPU command in guest get lost and so the seqno is not
updated in engine HWSP.

This patch fix this, and it also move the emulation code to kvmgt.
Because only vfio need to emulate it. Put aperture rw to MMIO emulation
path breaks assumptions in xengt.

v2: Remove PAGE_ALIGN for size (zhenyu)

CVE-2019-11085

Fixes: f090a00df9ec ("drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach")
Signed-off-by: Changbin Du <changbin.du@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(backported from commit d480b28a41a628e356dbacfa1c9f6d05b9baf838)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
8 weeks agodrm/i915: make mappable struct resource centric
Matthew Auld [Tue, 11 Jun 2019 08:33:00 +0000 (10:33 +0200)]
drm/i915: make mappable struct resource centric

Now that we are using struct resource to track the stolen region, it is
more convenient if we track the mappable region in a resource as well.

v2: prefer iomap and gmadr naming scheme
    prefer DEFINE_RES_MEM

CVE-2019-11085

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171211151822.20953-8-matthew.auld@intel.com
(backported from commit 73ebd503034c1abe31137df02dd4493eb7a522d4)
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
8 weeks agoBluetooth: hidp: fix buffer overflow
Young Xiao [Fri, 7 Jun 2019 22:16:49 +0000 (15:16 -0700)]
Bluetooth: hidp: fix buffer overflow

CVE-2019-11884

Struct ca is copied from userspace. It is not checked whether the "name"
field is NULL terminated, which allows local users to obtain potentially
sensitive information from kernel stack memory, via a HIDPCONNADD command.

This vulnerability is similar to CVE-2011-1079.

Signed-off-by: Young Xiao <YangX92@hotmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
(cherry picked from commit a1616a5ac99ede5d605047a9012481ce7ff18b16)
Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
8 weeks agocrypto: authenc - fix parsing key with misaligned rta_len
Eric Biggers [Thu, 23 May 2019 05:09:00 +0000 (07:09 +0200)]
crypto: authenc - fix parsing key with misaligned rta_len

BugLink: https://bugs.launchpad.net/bugs/1829725
Keys for "authenc" AEADs are formatted as an rtattr containing a 4-byte
'enckeylen', followed by an authentication key and an encryption key.
crypto_authenc_extractkeys() parses the key to find the inner keys.

However, it fails to consider the case where the rtattr's payload is
longer than 4 bytes but not 4-byte aligned, and where the key ends
before the next 4-byte aligned boundary.  In this case, 'keylen -=
RTA_ALIGN(rta->rta_len);' underflows to a value near UINT_MAX.  This
causes a buffer overread and crash during crypto_ahash_setkey().

Fix it by restricting the rtattr payload to the expected size.

Reproducer using AF_ALG:

#include <linux/if_alg.h>
#include <linux/rtnetlink.h>
#include <sys/socket.h>

int main()
{
int fd;
struct sockaddr_alg addr = {
.salg_type = "aead",
.salg_name = "authenc(hmac(sha256),cbc(aes))",
};
struct {
struct rtattr attr;
__be32 enckeylen;
char keys[1];
} __attribute__((packed)) key = {
.attr.rta_len = sizeof(key),
.attr.rta_type = 1 /* CRYPTO_AUTHENC_KEYA_PARAM */,
};

fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(fd, (void *)&addr, sizeof(addr));
setsockopt(fd, SOL_ALG, ALG_SET_KEY, &key, sizeof(key));
}

It caused:

BUG: unable to handle kernel paging request at ffff88007ffdc000
PGD 2e01067 P4D 2e01067 PUD 2e04067 PMD 2e05067 PTE 0
Oops: 0000 [#1] SMP
CPU: 0 PID: 883 Comm: authenc Not tainted 4.20.0-rc1-00108-g00c9fe37a7f27 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014
RIP: 0010:sha256_ni_transform+0xb3/0x330 arch/x86/crypto/sha256_ni_asm.S:155
[...]
Call Trace:
 sha256_ni_finup+0x10/0x20 arch/x86/crypto/sha256_ssse3_glue.c:321
 crypto_shash_finup+0x1a/0x30 crypto/shash.c:178
 shash_digest_unaligned+0x45/0x60 crypto/shash.c:186
 crypto_shash_digest+0x24/0x40 crypto/shash.c:202
 hmac_setkey+0x135/0x1e0 crypto/hmac.c:66
 crypto_shash_setkey+0x2b/0xb0 crypto/shash.c:66
 shash_async_setkey+0x10/0x20 crypto/shash.c:223
 crypto_ahash_setkey+0x2d/0xa0 crypto/ahash.c:202
 crypto_authenc_setkey+0x68/0x100 crypto/authenc.c:96
 crypto_aead_setkey+0x2a/0xc0 crypto/aead.c:62
 aead_setkey+0xc/0x10 crypto/algif_aead.c:526
 alg_setkey crypto/af_alg.c:223 [inline]
 alg_setsockopt+0xfe/0x130 crypto/af_alg.c:256
 __sys_setsockopt+0x6d/0xd0 net/socket.c:1902
 __do_sys_setsockopt net/socket.c:1913 [inline]
 __se_sys_setsockopt net/socket.c:1910 [inline]
 __x64_sys_setsockopt+0x1f/0x30 net/socket.c:1910
 do_syscall_64+0x4a/0x180 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: e236d4a89a2f ("[CRYPTO] authenc: Move enckeylen into key itself")
Cc: <stable@vger.kernel.org> # v2.6.25+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 8f9c469348487844328e162db57112f7d347c49f)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Khalid Elmously <khalid.elmously@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agox86/speculation/mds: Fix documentation typo
Josh Poimboeuf [Wed, 29 May 2019 02:28:00 +0000 (04:28 +0200)]
x86/speculation/mds: Fix documentation typo

Fix a minor typo in the MDS documentation: "eanbled" -> "enabled".

Reported-by: Jeff Bastian <jbastian@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130
CVE-2019-11091

(cherry picked from commit 95310e348a321b45fb746c176961d4da72344282)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agoDocumentation: Correct the possible MDS sysfs values
Tyler Hicks [Wed, 29 May 2019 02:28:00 +0000 (04:28 +0200)]
Documentation: Correct the possible MDS sysfs values

Adjust the last two rows in the table that display possible values when
MDS mitigation is enabled. They both were slightly innacurate.

In addition, convert the table of possible values and their descriptions
to a list-table. The simple table format uses the top border of equals
signs to determine cell width which resulted in the first column being
far too wide in comparison to the second column that contained the
majority of the text.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130
CVE-2019-11091

(cherry picked from commit ea01668f9f43021b28b3f4d5ffad50106a1e1301)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agox86/mds: Add MDSUM variant to the MDS documentation
speck for Pawan Gupta [Wed, 29 May 2019 02:28:00 +0000 (04:28 +0200)]
x86/mds: Add MDSUM variant to the MDS documentation

Updated the documentation for a new CVE-2019-11091 Microarchitectural Data
Sampling Uncacheable Memory (MDSUM) which is a variant of
Microarchitectural Data Sampling (MDS). MDS is a family of side channel
attacks on internal buffers in Intel CPUs.

MDSUM is a special case of MSBDS, MFBDS and MLPDS. An uncacheable load from
memory that takes a fault or assist can leave data in a microarchitectural
structure that may later be observed using one of the same methods used by
MSBDS, MFBDS or MLPDS. There are no new code changes expected for MDSUM.
The existing mitigation for MDS applies to MDSUM as well.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Jon Masters <jcm@redhat.com>
CVE-2019-11091

(cherry picked from commit e672f8bf71c66253197e503f75c771dd28ada4a0)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agoUBUNTU: SAUCE: Synchronize MDS mitigations with upstream
Tyler Hicks [Wed, 29 May 2019 02:28:00 +0000 (04:28 +0200)]
UBUNTU: SAUCE: Synchronize MDS mitigations with upstream

Bring the Ubuntu MDS mitigations in sync with the upstream mitigations.
The initial Ubuntu backport was based on the next to last revision of
the base patch series from upstream.

There is no functional change except for adjusting L1TF warning messages
to use the new URL for the L1TF admin guide.

The Atom Silvermont and Airmont changes in the cpu_vuln_whitelist[]
cause no functional changes because Silvermont and Airmont do not
support Intel Hyper-Threading. Therefore, even without this change, the
CPU buffers would be properly flushed as the CPU thread goes into sleep
state and MDS would be reported as being mitigated.

This commit contains changes from the following upstream commits:

 5999bbe7a6ea ("Documentation: Add MDS vulnerability documentation")
 65fd4cb65b2d ("Documentation: Move L1TF to separate directory")
 bc1241700acd ("x86/speculation/mds: Add mitigation control for MDS")
 22dd8365088b ("x86/speculation/mds: Add mitigation mode VMWERV")
 e261f209c366 ("x86/speculation/mds: Add BUG_MSBDS_ONLY")

CVE-2018-12126
CVE-2018-12127
CVE-2018-12130
CVE-2019-11091

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agodrm/i915/gvt: Fix mmap range check
Zhenyu Wang [Wed, 29 May 2019 13:52:00 +0000 (15:52 +0200)]
drm/i915/gvt: Fix mmap range check

This is to fix missed mmap range check on vGPU bar2 region
and only allow to map vGPU allocated GMADDR range, which means
user space should support sparse mmap to get proper offset for
mmap vGPU aperture. And this takes care of actual pgoff in mmap
request as original code always does from beginning of vGPU
aperture.

Fixes: 659643f7d814 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
Cc: "Monroy, Rodrigo Axel" <rodrigo.axel.monroy@intel.com>
Cc: "Orrala Contreras, Alfredo" <alfredo.orrala.contreras@intel.com>
Cc: stable@vger.kernel.org # v4.10+
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
CVE-2019-11085

(cherry picked from commit 51b00d8509dc69c98740da2ad07308b630d3eb7d)
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agoselftests/powerpc: Remove Power9 copy_unaligned test
Michael Ellerman [Tue, 14 May 2019 09:01:00 +0000 (11:01 +0200)]
selftests/powerpc: Remove Power9 copy_unaligned test

BugLink: https://bugs.launchpad.net/bugs/1813118
This is a test of the ISA 3.0 "copy" instruction. That instruction has
an L field, which if set to 1 specifies that "the instruction
identifies the beginning of a move group" (pp 858). That's also
referred to as "copy first" vs "copy".

In ISA 3.0B the copy instruction does not have an L field, and the
corresponding bit in the instruction must be set to 1.

This test is generating a "copy" instruction, not a "copy first", and
so on Power9 (which implements 3.0B), this results in an illegal
instruction.

So just drop the test entirely. We still have copy_first_unaligned to
test the "copy first" behaviour.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 83039f22ba2f6aff935a2acbb6bf671374e8317d)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
8 weeks agoselftests/seccomp: Enhance per-arch ptrace syscall skip tests
Kees Cook [Thu, 16 May 2019 10:20:00 +0000 (12:20 +0200)]
selftests/seccomp: Enhance per-arch ptrace syscall skip tests

BugLink: https://bugs.launchpad.net/bugs/1812796
Passing EPERM during syscall skipping was confusing since the test wasn't
actually exercising the errno evaluation -- it was just passing a literal
"1" (EPERM). Instead, expand the tests to check both direct value returns
(positive, 45000 in this case), and errno values (negative, -ESRCH in this
case) to check both fake success and fake failure during syscall skipping.

Reported-by: Colin Ian King <colin.king@canonical.com>
Fixes: a33b2d0359a0 ("selftests/seccomp: Add tests for basic ptrace actions")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <shuah@kernel.org>
(cherry picked from commit ed5f13261cb65b02c611ae9971677f33581d4286)
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.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>