~smb/ubuntu/+source/linux/+git/disco:stable-5.0

Last commit made on 2019-07-15
Get this branch:
git clone -b stable-5.0 https://git.launchpad.net/~smb/ubuntu/+source/linux/+git/disco
Only Stefan Bader can upload to this branch. If you are Stefan Bader please log in for upload directions.

Branch merges

Branch information

Name:
stable-5.0
Repository:
lp:~smb/ubuntu/+source/linux/+git/disco

Recent commits

7af85be... by Greg Kroah-Hartman <email address hidden>

Linux 5.0.18

BugLink: https://bugs.launchpad.net/bugs/1836614

Signed-off-by: Stefan Bader <email address hidden>

c3d5d35... by Andreas Dilger <email address hidden>

ext4: don't update s_rev_level if not required

BugLink: https://bugs.launchpad.net/bugs/1836614

commit c9e716eb9b3455a83ed7c5f5a81256a3da779a95 upstream.

Don't update the superblock s_rev_level during mount if it isn't
actually necessary, only if superblock features are being set by
the kernel. This was originally added for ext3 since it always
set the INCOMPAT_RECOVER and HAS_JOURNAL features during mount,
but this is not needed since no journal mode was added to ext4.

That will allow Geert to mount his 20-year-old ext2 rev 0.0 m68k
filesystem, as a testament of the backward compatibility of ext4.

Fixes: 0390131ba84f ("ext4: Allow ext4 to run without a journal")
Signed-off-by: Andreas Dilger <email address hidden>
Signed-off-by: Theodore Ts'o <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

cf263bd... by "zhangyi (F)" <email address hidden>

ext4: fix compile error when using BUFFER_TRACE

BugLink: https://bugs.launchpad.net/bugs/1836614

commit ddccb6dbe780d68133191477571cb7c69e17bb8c upstream.

Fix compile error below when using BUFFER_TRACE.

fs/ext4/inode.c: In function ‘ext4_expand_extra_isize’:
fs/ext4/inode.c:5979:19: error: request for member ‘bh’ in something not a structure or union
  BUFFER_TRACE(iloc.bh, "get_write_access");

Fixes: c03b45b853f58 ("ext4, project: expand inode extra size if possible")
Signed-off-by: zhangyi (F) <email address hidden>
Signed-off-by: Theodore Ts'o <email address hidden>
Reviewed-by: Jan Kara <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

e4cb62a... by Martin Schwidefsky <email address hidden>

s390/mm: convert to the generic get_user_pages_fast code

BugLink: https://bugs.launchpad.net/bugs/1836614

commit 1a42010cdc26bb7e5912984f3c91b8c6d55f089a upstream.

Define the gup_fast_permitted to check against the asce_limit of the
mm attached to the current task, then replace the s390 specific gup
code with the generic implementation in mm/gup.c.

Signed-off-by: Martin Schwidefsky <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

d24b616... by Martin Schwidefsky <email address hidden>

s390/mm: make the pxd_offset functions more robust

BugLink: https://bugs.launchpad.net/bugs/1836614

commit d1874a0c2805fcfa9162c972d6b7541e57adb542 upstream.

Change the way how pgd_offset, p4d_offset, pud_offset and pmd_offset
walk the page tables. pgd_offset now always calculates the index for
the top-level page table and adds it to the pgd, this is either a
segment table offset for a 2-level setup, a region-3 offset for 3-levels,
region-2 offset for 4-levels, or a region-1 offset for a 5-level setup.
The other three functions p4d_offset, pud_offset and pmd_offset will
only add the respective offset if they dereference the passed pointer.

With the new way of walking the page tables a sequence like this from
mm/gup.c now works:

     pgdp = pgd_offset(current->mm, addr);
     pgd = READ_ONCE(*pgdp);
     p4dp = p4d_offset(&pgd, addr);
     p4d = READ_ONCE(*p4dp);
     pudp = pud_offset(&p4d, addr);
     pud = READ_ONCE(*pudp);
     pmdp = pmd_offset(&pud, addr);
     pmd = READ_ONCE(*pmdp);

Signed-off-by: Martin Schwidefsky <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

e829cb5... by Ira Weiny <email address hidden>

mm/gup: Remove the 'write' parameter from gup_fast_permitted()

BugLink: https://bugs.launchpad.net/bugs/1836614

commit ad8cfb9c42ef83ecf4079bc7d77e6557648e952b upstream.

The 'write' parameter is unused in gup_fast_permitted() so remove it.

Signed-off-by: Ira Weiny <email address hidden>
Acked-by: Kirill A. Shutemov <email address hidden>
Reviewed-by: Thomas Gleixner <email address hidden>
Cc: Andrew Morton <email address hidden>
Cc: Borislav Petkov <email address hidden>
Cc: Dan Williams <email address hidden>
Cc: Dave Hansen <email address hidden>
Cc: Linus Torvalds <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: <email address hidden>
Link: http://<email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
Cc: Justin Forbes <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

a765932... by Eric Dumazet <email address hidden>

iov_iter: optimize page_copy_sane()

BugLink: https://bugs.launchpad.net/bugs/1836614

commit 6daef95b8c914866a46247232a048447fff97279 upstream.

Avoid cache line miss dereferencing struct page if we can.

page_copy_sane() mostly deals with order-0 pages.

Extra cache line miss is visible on TCP recvmsg() calls dealing
with GRO packets (typically 45 page frags are attached to one skb).

Bringing the 45 struct pages into cpu cache while copying the data
is not free, since the freeing of the skb (and associated
page frags put_page()) can happen after cache lines have been evicted.

Signed-off-by: Eric Dumazet <email address hidden>
Cc: Al Viro <email address hidden>
Signed-off-by: Al Viro <email address hidden>
Cc: Matthew Wilcox <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

f4ea313... by Dan Williams

libnvdimm/namespace: Fix label tracking error

BugLink: https://bugs.launchpad.net/bugs/1836614

commit c4703ce11c23423d4b46e3d59aef7979814fd608 upstream.

Users have reported intermittent occurrences of DIMM initialization
failures due to duplicate allocations of address capacity detected in
the labels, or errors of the form below, both have the same root cause.

    nd namespace1.4: failed to track label: 0
    WARNING: CPU: 17 PID: 1381 at drivers/nvdimm/label.c:863

    RIP: 0010:__pmem_label_update+0x56c/0x590 [libnvdimm]
    Call Trace:
     ? nd_pmem_namespace_label_update+0xd6/0x160 [libnvdimm]
     nd_pmem_namespace_label_update+0xd6/0x160 [libnvdimm]
     uuid_store+0x17e/0x190 [libnvdimm]
     kernfs_fop_write+0xf0/0x1a0
     vfs_write+0xb7/0x1b0
     ksys_write+0x57/0xd0
     do_syscall_64+0x60/0x210

Unfortunately those reports were typically with a busy parallel
namespace creation / destruction loop making it difficult to see the
components of the bug. However, Jane provided a simple reproducer using
the work-in-progress sub-section implementation.

When ndctl is reconfiguring a namespace it may take an existing defunct
/ disabled namespace and reconfigure it with a new uuid and other
parameters. Critically namespace_update_uuid() takes existing address
resources and renames them for the new namespace to use / reconfigure as
it sees fit. The bug is that this rename only happens in the resource
tracking tree. Existing labels with the old uuid are not reaped leading
to a scenario where multiple active labels reference the same span of
address range.

Teach namespace_update_uuid() to flag any references to the old uuid for
reaping at the next label update attempt.

Cc: <email address hidden>
Fixes: bf9bccc14c05 ("libnvdimm: pmem label sets and namespace instantiation")
Link: https://github.com/pmem/ndctl/issues/91
Reported-by: Jane Chu <email address hidden>
Reported-by: Jeff Moyer <email address hidden>
Reported-by: Erwin Tsaur <email address hidden>
Cc: Johannes Thumshirn <email address hidden>
Signed-off-by: Dan Williams <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

2f774df... by Roger Pau Monne <email address hidden>

xen/pvh: correctly setup the PV EFI interface for dom0

BugLink: https://bugs.launchpad.net/bugs/1836614

commit 72813bfbf0276a97c82af038efb5f02dcdd9e310 upstream.

This involves initializing the boot params EFI related fields and the
efi global variable.

Without this fix a PVH dom0 doesn't detect when booted from EFI, and
thus doesn't support accessing any of the EFI related data.

Reported-by: PGNet Dev <email address hidden>
Signed-off-by: Roger Pau Monné <email address hidden>
Reviewed-by: Boris Ostrovsky <email address hidden>
Signed-off-by: Boris Ostrovsky <email address hidden>
Cc: <email address hidden> # 4.19+
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>

4abcadf... by Roger Pau Monne <email address hidden>

xen/pvh: set xen_domain_type to HVM in xen_pvh_init

BugLink: https://bugs.launchpad.net/bugs/1836614

commit c9f804d64bb93c8dbf957df1d7e9de11380e522d upstream.

Or else xen_domain() returns false despite xen_pvh being set.

Signed-off-by: Roger Pau Monné <email address hidden>
Reviewed-by: Boris Ostrovsky <email address hidden>
Signed-off-by: Boris Ostrovsky <email address hidden>
Cc: <email address hidden> # 4.19+
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>