1. 15 Jun, 2017 1 commit
  2. 13 Jun, 2017 6 commits
    • Ankur Arora's avatar
      xen/vcpu: Handle xen_vcpu_setup() failure at boot · ae039001
      Ankur Arora authored
      On PVH, PVHVM, at failure in the VCPUOP_register_vcpu_info hypercall
      we limit the number of cpus to to MAX_VIRT_CPUS. However, if this
      failure had occurred for a cpu beyond MAX_VIRT_CPUS, we continue
      to function with > MAX_VIRT_CPUS.
      
      This leads to problems at the next save/restore cycle when there
      are > MAX_VIRT_CPUS threads going into stop_machine() but coming
      back up there's valid state for only the first MAX_VIRT_CPUS.
      
      This patch pulls the excess CPUs down via cpu_down().
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarAnkur Arora <ankur.a.arora@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      ae039001
    • Ankur Arora's avatar
      xen/vcpu: Handle xen_vcpu_setup() failure in hotplug · c9b5d98b
      Ankur Arora authored
      The hypercall VCPUOP_register_vcpu_info can fail. This failure is
      handled by making per_cpu(xen_vcpu, cpu) point to its shared_info
      slot and those without one (cpu >= MAX_VIRT_CPUS) be NULL.
      
      For PVH/PVHVM, this is not enough, because we also need to pull
      these VCPUs out of circulation.
      
      Fix for PVH/PVHVM: on registration failure in the cpuhp prepare
      callback (xen_cpu_up_prepare_hvm()), return an error to the cpuhp
      state-machine so it can fail the CPU init.
      
      Fix for PV: the registration happens before smp_init(), so, in the
      failure case we clamp setup_max_cpus and limit the number of VCPUs
      that smp_init() will bring-up to MAX_VIRT_CPUS.
      This is functionally correct but it makes the code a bit simpler
      if we get rid of this explicit clamping: for VCPUs that don't have
      valid xen_vcpu, fail the CPU init in the cpuhp prepare callback
      (xen_cpu_up_prepare_pv()).
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarAnkur Arora <ankur.a.arora@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      c9b5d98b
    • Ankur Arora's avatar
      xen/pv: Fix OOPS on restore for a PV, !SMP domain · 0e4d5837
      Ankur Arora authored
      If CONFIG_SMP is disabled, xen_setup_vcpu_info_placement() is called from
      xen_setup_shared_info(). This is fine as far as boot goes, but it means
      that we also call it in the restore path. This results in an OOPS
      because we assign to pv_mmu_ops.read_cr2 which is __ro_after_init.
      
      Also, though less problematically, this means we call xen_vcpu_setup()
      twice at restore -- once from the vcpu info placement call and the
      second time from xen_vcpu_restore().
      
      Fix by calling xen_setup_vcpu_info_placement() at boot only.
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarAnkur Arora <ankur.a.arora@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      0e4d5837
    • Ankur Arora's avatar
      xen/pvh*: Support > 32 VCPUs at domain restore · 0b64ffb8
      Ankur Arora authored
      When Xen restores a PVHVM or PVH guest, its shared_info only holds
      up to 32 CPUs. The hypercall VCPUOP_register_vcpu_info allows
      us to setup per-page areas for VCPUs. This means we can boot
      PVH* guests with more than 32 VCPUs. During restore the per-cpu
      structure is allocated freshly by the hypervisor (vcpu_info_mfn is
      set to INVALID_MFN) so that the newly restored guest can make a
      VCPUOP_register_vcpu_info hypercall.
      
      However, we end up triggering this condition in Xen:
      /* Run this command on yourself or on other offline VCPUS. */
       if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) )
      
      which means we are unable to setup the per-cpu VCPU structures
      for running VCPUS. The Linux PV code paths makes this work by
      iterating over cpu_possible in xen_vcpu_restore() with:
      
       1) is target CPU up (VCPUOP_is_up hypercall?)
       2) if yes, then VCPUOP_down to pause it
       3) VCPUOP_register_vcpu_info
       4) if it was down, then VCPUOP_up to bring it back up
      
      With Xen commit 192df6f9122d ("xen/x86: allow HVM guests to use
      hypercalls to bring up vCPUs") this is available for non-PV guests.
      As such first check if VCPUOP_is_up is actually possible before
      trying this dance.
      
      As most of this dance code is done already in xen_vcpu_restore()
      let's make it callable on PV, PVH and PVHVM.
      Based-on-patch-by: default avatarKonrad Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarAnkur Arora <ankur.a.arora@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      0b64ffb8
    • Ankur Arora's avatar
      xen/vcpu: Simplify xen_vcpu related code · ad73fd59
      Ankur Arora authored
      Largely mechanical changes to aid unification of xen_vcpu_restore()
      logic for PV, PVH and PVHVM.
      
      xen_vcpu_setup(): the only change in logic is that clamp_max_cpus()
      is now handled inside the "if (!xen_have_vcpu_info_placement)" block.
      
      xen_vcpu_restore(): code movement from enlighten_pv.c to enlighten.c.
      
      xen_vcpu_info_reset(): pulls together all the code where xen_vcpu
      is set to default.
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarAnkur Arora <ankur.a.arora@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      ad73fd59
    • Anoob Soman's avatar
      xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU · c48f64ab
      Anoob Soman authored
      A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn)
      interrupts,in a short period of time. All these evtchn:qemu-dm are bound
      to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU.
      In one configuration, irqbalance runs every 10 seconds, which means
      irqbalance doesn't get to see these burst of interrupts and doesn't
      re-balance interrupts most of the time, making all evtchn:qemu-dm to be
      processed by VCPU0. This cause VCPU0 to spend most of time processing
      hardirq and very little time on softirq. Moreover, if dom0 kernel PREEMPTION
      is disabled, VCPU0 never runs watchdog (process context), triggering a
      softlockup detection code to panic.
      
      Binding evtchn:qemu-dm to next online VCPU, will spread hardirq
      processing evenly across different CPU. Later, irqbalance will try to balance
      evtchn:qemu-dm, if required.
      Signed-off-by: default avatarAnoob Soman <anoob.soman@citrix.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      c48f64ab
  3. 08 Jun, 2017 2 commits
  4. 07 Jun, 2017 1 commit
  5. 05 Jun, 2017 3 commits
  6. 04 Jun, 2017 9 commits
    • Linus Torvalds's avatar
      Linux 4.12-rc4 · 3c2993b8
      Linus Torvalds authored
      3c2993b8
    • Richard Narron's avatar
      fs/ufs: Set UFS default maximum bytes per file · 239e250e
      Richard Narron authored
      This fixes a problem with reading files larger than 2GB from a UFS-2
      file system:
      
          https://bugzilla.kernel.org/show_bug.cgi?id=195721
      
      The incorrect UFS s_maxsize limit became a problem as of commit
      c2a9737f ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
      which started using s_maxbytes to avoid a page index overflow in
      do_generic_file_read().
      
      That caused files to be truncated on UFS-2 file systems because the
      default maximum file size is 2GB (MAX_NON_LFS) and UFS didn't update it.
      
      Here I simply increase the default to a common value used by other file
      systems.
      Signed-off-by: default avatarRichard Narron <comet.berkeley@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Will B <will.brokenbourgh2877@gmail.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: <stable@vger.kernel.org> # v4.9 and backports of c2a9737fSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      239e250e
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-4.12-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · 125f42b0
      Linus Torvalds authored
      Pull NFS client bugfixes from Trond Myklebust:
       "Bugfixes include:
      
         - Fix a typo in commit e0926934 ("NFS append COMMIT after
           synchronous COPY") that breaks copy offload
      
         - Fix the connect error propagation in xs_tcp_setup_socket()
      
         - Fix a lock leak in nfs40_walk_client_list
      
         - Verify that pNFS requests lie within the offset range of the layout
           segment"
      
      * tag 'nfs-for-4.12-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
        nfs: Mark unnecessarily extern functions as static
        SUNRPC: ensure correct error is reported by xs_tcp_setup_socket()
        NFSv4.0: Fix a lock leak in nfs40_walk_client_list
        pnfs: Fix the check for requests in range of layout segment
        xprtrdma: Delete an error message for a failed memory allocation in xprt_rdma_bc_setup()
        pNFS/flexfiles: missing error code in ff_layout_alloc_lseg()
        NFS fix COMMIT after COPY
      125f42b0
    • Linus Torvalds's avatar
      Merge tag 'tty-4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · 3c06e6cb
      Linus Torvalds authored
      Pull tty fix from Greg KH:
       "Here is a single tty core fix for 4.12-rc4. It reverts a patch that a
        lot of people reported as causing lockdep and other warnings.
      
        Right after I reverted this in my tree, it seems like another
        "correct" fix might have shown up, but it's too late in the release
        cycle to be messing with tty core locking, so let's just revert this
        for now to go back how things always have been and try it again for
        4.13.
      
        This has not been in linux-next as I only reverted it a few hours ago"
      
      * tag 'tty-4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        Revert "tty: fix port buffer locking"
      3c06e6cb
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · e00811b4
      Linus Torvalds authored
      Pull input subsystem fixes from Dmitry Torokhov:
      
       - a couple of regression fixes in synaptics and axp20x-pek drivers
      
       - try to ease transition from PS/2 to RMI for Synaptics touchpad users
         by ensuring we do not try to activate RMI mode when RMI SMBus support
         is not enabled, and nag users a bit to enable it
      
       - plus a couple of other changes that seemed worthwhile for this
         release
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: axp20x-pek - switch to acpi_dev_present and check for ACPI0011 too
        Input: axp20x-pek - only check for "INTCFD9" ACPI device on Cherry Trail
        Input: tm2-touchkey - use LEN_ON as boolean value instead of LED_FULL
        Input: synaptics - tell users to report when they should be using rmi-smbus
        Input: synaptics - warn the users when there is a better mode
        Input: synaptics - keep PS/2 around when RMI4_SMB is not enabled
        Input: synaptics - clear device info before filling in
        Input: silead - disable interrupt during suspend
      e00811b4
    • Linus Torvalds's avatar
      Merge tag 'rtc-4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux · 9f03b2c7
      Linus Torvalds authored
      Pull RTC fixlet from Alexandre Belloni:
       "A single patch, not really a fix but I don't think there is any reason
        to delay it.
      
        Change the mailing list address"
      
      * tag 'rtc-4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
        MAINTAINERS: update RTC mailing list
      9f03b2c7
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 1f915b7f
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is nine fixes, seven of which are for the qedi driver (new as of
        4.10) the other two are a use after free in the cxgbi drivers and a
        potential NULL dereference in the rdac device handler"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: libcxgbi: fix skb use after free
        scsi: qedi: Fix endpoint NULL panic during recovery.
        scsi: qedi: set max_fin_rt default value
        scsi: qedi: Set firmware tcp msl timer value.
        scsi: qedi: Fix endpoint NULL panic in qedi_set_path.
        scsi: qedi: Set dma_boundary to 0xfff.
        scsi: qedi: Correctly set firmware max supported BDs.
        scsi: qedi: Fix bad pte call trace when iscsiuio is stopped.
        scsi: scsi_dh_rdac: Use ctlr directly in rdac_failover_get()
      1f915b7f
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma · 55cbdaf6
      Linus Torvalds authored
      Pull rdma fixes from Doug Ledford:
       "For the most part this is just a minor -rc cycle for the rdma
        subsystem. Even given that this is all of the -rc patches since the
        merge window closed, it's still only about 25 patches:
      
         - Multiple i40iw, nes, iw_cxgb4, hfi1, qib, mlx4, mlx5 fixes
      
         - A few upper layer protocol fixes (IPoIB, iSER, SRP)
      
         - A modest number of core fixes"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: (26 commits)
        RDMA/SA: Fix kernel panic in CMA request handler flow
        RDMA/umem: Fix missing mmap_sem in get umem ODP call
        RDMA/core: not to set page dirty bit if it's already set.
        RDMA/uverbs: Declare local function static and add brackets to sizeof
        RDMA/netlink: Reduce exposure of RDMA netlink functions
        RDMA/srp: Fix NULL deref at srp_destroy_qp()
        RDMA/IPoIB: Limit the ipoib_dev_uninit_default scope
        RDMA/IPoIB: Replace netdev_priv with ipoib_priv for ipoib_get_link_ksettings
        RDMA/qedr: add null check before pointer dereference
        RDMA/mlx5: set UMR wqe fence according to HCA cap
        net/mlx5: Define interface bits for fencing UMR wqe
        RDMA/mlx4: Fix MAD tunneling when SRIOV is enabled
        RDMA/qib,hfi1: Fix MR reference count leak on write with immediate
        RDMA/hfi1: Defer setting VL15 credits to link-up interrupt
        RDMA/hfi1: change PCI bar addr assignments to Linux API functions
        RDMA/hfi1: fix array termination by appending NULL to attr array
        RDMA/iw_cxgb4: fix the calculation of ipv6 header size
        RDMA/iw_cxgb4: calculate t4_eq_status_entries properly
        RDMA/iw_cxgb4: Avoid touch after free error in ARP failure handlers
        RDMA/nes: ACK MPA Reply frame
        ...
      55cbdaf6
    • Greg Kroah-Hartman's avatar
      Revert "tty: fix port buffer locking" · fc098af1
      Greg Kroah-Hartman authored
      This reverts commit 925bb1ce.
      
      It causes lots of warnings and problems so for now, let's just revert
      it.
      
      Reported-by: <valdis.kletnieks@vt.edu>
      Reported-by: default avatarRussell King <linux@armlinux.org.uk>
      Reported-by: default avatarSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc098af1
  7. 03 Jun, 2017 8 commits
  8. 02 Jun, 2017 10 commits
    • Linus Torvalds's avatar
      Merge tag 'acpi-4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 104c08ba
      Linus Torvalds authored
      Pull ACPI fixes from Rafael Wysocki:
       "These revert one more problematic commit related to the ACPI-based
        handling of laptop lids and make some unuseful error messages coming
        from ACPICA go away.
      
        Specifics:
      
         - Revert one more commit related to the ACPI-based handling of laptop
           lids that changed the default behavior on laptops that booted with
           closed lids and introduced a regression there (Benjamin Tissoires).
      
         - Add a missing acpi_put_table() to the code implementing the
           /sys/firmware/acpi/tables interface to prevent a counter in the
           ACPICA core from overflowing (Dan Williams).
      
         - Drop error messages printed by ACPICA on acpi_get_table() reference
           counting mismatches as they need not indicate real errors at this
           point (Lv Zheng)"
      
      * tag 'acpi-4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPICA: Tables: Fix regression introduced by a too early mechanism enabling
        Revert "ACPI / button: Change default behavior to lid_init_state=open"
        ACPI / sysfs: fix acpi_get_table() leak / acpi-sysfs denial of service
      104c08ba
    • Linus Torvalds's avatar
      Merge tag 'pm-4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 89af529a
      Linus Torvalds authored
      Pull power management fixes from Rafael Wysocki:
       "These fix two bugs in error code paths in the cpufreq core and in the
        kirkwood-cpufreq driver.
      
        Specifics:
      
         - Make cpufreq_register_driver() return an error if the ->init()
           calls fail for all CPUs to prevent non-functional drivers from
           hanging around for no reason (David Arcari).
      
         - Make kirkwood-cpufreq check the return value of
           clk_prepare_enable() (which may fail) as appropriate (Arvind
           Yadav)"
      
      * tag 'pm-4.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        cpufreq: kirkwood-cpufreq:- Handle return value of clk_prepare_enable()
        cpufreq: cpufreq_register_driver() should return -ENODEV if init fails
      89af529a
    • Linus Torvalds's avatar
      Merge tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random · 5a4829b5
      Linus Torvalds authored
      Pull /dev/random bug fix from Ted Ts'o:
       "Fix a race on architectures with prioritized interrupts (such as m68k)
        which can causes crashes in drivers/char/random.c:get_reg()"
      
      * tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
        fix race in drivers/char/random.c:get_reg()
      5a4829b5
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · f2197649
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "15 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        scripts/gdb: make lx-dmesg command work (reliably)
        mm: consider memblock reservations for deferred memory initialization sizing
        mm/hugetlb: report -EHWPOISON not -EFAULT when FOLL_HWPOISON is specified
        mlock: fix mlock count can not decrease in race condition
        mm/migrate: fix refcount handling when !hugepage_migration_supported()
        dax: fix race between colliding PMD & PTE entries
        mm: avoid spurious 'bad pmd' warning messages
        mm/page_alloc.c: make sure OOM victim can try allocations with no watermarks once
        pcmcia: remove left-over %Z format
        slub/memcg: cure the brainless abuse of sysfs attributes
        initramfs: fix disabling of initramfs (and its compression)
        mm: clarify why we want kmalloc before falling backto vmallock
        frv: declare jiffies to be located in the .data section
        include/linux/gfp.h: fix ___GFP_NOLOCKDEP value
        ksm: prevent crash after write_protect_page fails
      f2197649
    • André Draszik's avatar
      scripts/gdb: make lx-dmesg command work (reliably) · d6c97087
      André Draszik authored
      lx-dmesg needs access to the log_buf symbol from printk.c.
      Unfortunately, the symbol log_buf also exists in BPF's verifier.c and
      hence gdb can pick one or the other.  If it happens to pick BPF's
      log_buf, lx-dmesg doesn't work:
      
        (gdb) lx-dmesg
        Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x0:
        Error occurred in Python command: Cannot access memory at address 0x0
        (gdb) p log_buf
        $15 = 0x0
      
      Luckily, GDB has a way to deal with this, see
        https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html
      
        (gdb) info variables ^log_buf$
        All variables matching regular expression "^log_buf$":
      
        File <linux.git>/kernel/bpf/verifier.c:
        static char *log_buf;
      
        File <linux.git>/kernel/printk/printk.c:
        static char *log_buf;
        (gdb) p 'verifier.c'::log_buf
        $1 = 0x0
        (gdb) p 'printk.c'::log_buf
        $2 = 0x811a6aa0 <__log_buf> ""
        (gdb) p &log_buf
        $3 = (char **) 0x8120fe40 <log_buf>
        (gdb) p &'verifier.c'::log_buf
        $4 = (char **) 0x8120fe40 <log_buf>
        (gdb) p &'printk.c'::log_buf
        $5 = (char **) 0x8048b7d0 <log_buf>
      
      By being explicit about the location of the symbol, we can make lx-dmesg
      work again.  While at it, do the same for the other symbols we need from
      printk.c
      
      Link: http://lkml.kernel.org/r/20170526112222.3414-1-git@andred.netSigned-off-by: default avatarAndré Draszik <git@andred.net>
      Tested-by: default avatarKieran Bingham <kieran@bingham.xyz>
      Acked-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d6c97087
    • Michal Hocko's avatar
      mm: consider memblock reservations for deferred memory initialization sizing · 864b9a39
      Michal Hocko authored
      We have seen an early OOM killer invocation on ppc64 systems with
      crashkernel=4096M:
      
      	kthreadd invoked oom-killer: gfp_mask=0x16040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK), nodemask=7, order=0, oom_score_adj=0
      	kthreadd cpuset=/ mems_allowed=7
      	CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.4.68-1.gd7fe927-default #1
      	Call Trace:
      	  dump_stack+0xb0/0xf0 (unreliable)
      	  dump_header+0xb0/0x258
      	  out_of_memory+0x5f0/0x640
      	  __alloc_pages_nodemask+0xa8c/0xc80
      	  kmem_getpages+0x84/0x1a0
      	  fallback_alloc+0x2a4/0x320
      	  kmem_cache_alloc_node+0xc0/0x2e0
      	  copy_process.isra.25+0x260/0x1b30
      	  _do_fork+0x94/0x470
      	  kernel_thread+0x48/0x60
      	  kthreadd+0x264/0x330
      	  ret_from_kernel_thread+0x5c/0xa4
      
      	Mem-Info:
      	active_anon:0 inactive_anon:0 isolated_anon:0
      	 active_file:0 inactive_file:0 isolated_file:0
      	 unevictable:0 dirty:0 writeback:0 unstable:0
      	 slab_reclaimable:5 slab_unreclaimable:73
      	 mapped:0 shmem:0 pagetables:0 bounce:0
      	 free:0 free_pcp:0 free_cma:0
      	Node 7 DMA free:0kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:52428800kB managed:110016kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:320kB slab_unreclaimable:4672kB kernel_stack:1152kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
      	lowmem_reserve[]: 0 0 0 0
      	Node 7 DMA: 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 0kB
      	0 total pagecache pages
      	0 pages in swap cache
      	Swap cache stats: add 0, delete 0, find 0/0
      	Free swap  = 0kB
      	Total swap = 0kB
      	819200 pages RAM
      	0 pages HighMem/MovableOnly
      	817481 pages reserved
      	0 pages cma reserved
      	0 pages hwpoisoned
      
      the reason is that the managed memory is too low (only 110MB) while the
      rest of the the 50GB is still waiting for the deferred intialization to
      be done.  update_defer_init estimates the initial memoty to initialize
      to 2GB at least but it doesn't consider any memory allocated in that
      range.  In this particular case we've had
      
      	Reserving 4096MB of memory at 128MB for crashkernel (System RAM: 51200MB)
      
      so the low 2GB is mostly depleted.
      
      Fix this by considering memblock allocations in the initial static
      initialization estimation.  Move the max_initialise to
      reset_deferred_meminit and implement a simple memblock_reserved_memory
      helper which iterates all reserved blocks and sums the size of all that
      start below the given address.  The cumulative size is than added on top
      of the initial estimation.  This is still not ideal because
      reset_deferred_meminit doesn't consider holes and so reservation might
      be above the initial estimation whihch we ignore but let's make the
      logic simpler until we really need to handle more complicated cases.
      
      Fixes: 3a80a7fa ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set")
      Link: http://lkml.kernel.org/r/20170531104010.GI27783@dhcp22.suse.czSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Tested-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org>	[4.2+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      864b9a39
    • James Morse's avatar
      mm/hugetlb: report -EHWPOISON not -EFAULT when FOLL_HWPOISON is specified · 9a291a7c
      James Morse authored
      KVM uses get_user_pages() to resolve its stage2 faults.  KVM sets the
      FOLL_HWPOISON flag causing faultin_page() to return -EHWPOISON when it
      finds a VM_FAULT_HWPOISON.  KVM handles these hwpoison pages as a
      special case.  (check_user_page_hwpoison())
      
      When huge pages are involved, this doesn't work so well.
      get_user_pages() calls follow_hugetlb_page(), which stops early if it
      receives VM_FAULT_HWPOISON from hugetlb_fault(), eventually returning
      -EFAULT to the caller.  The step to map this to -EHWPOISON based on the
      FOLL_ flags is missing.  The hwpoison special case is skipped, and
      -EFAULT is returned to user-space, causing Qemu or kvmtool to exit.
      
      Instead, move this VM_FAULT_ to errno mapping code into a header file
      and use it from faultin_page() and follow_hugetlb_page().
      
      With this, KVM works as expected.
      
      This isn't a problem for arm64 today as we haven't enabled
      MEMORY_FAILURE, but I can't see any reason this doesn't happen on x86
      too, so I think this should be a fix.  This doesn't apply earlier than
      stable's v4.11.1 due to all sorts of cleanup.
      
      [james.morse@arm.com: add vm_fault_to_errno() call to faultin_page()]
      suggested.
        Link: http://lkml.kernel.org/r/20170525171035.16359-1-james.morse@arm.com
      [akpm@linux-foundation.org: coding-style fixes]
      Link: http://lkml.kernel.org/r/20170524160900.28786-1-james.morse@arm.comSigned-off-by: default avatarJames Morse <james.morse@arm.com>
      Acked-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>	[4.11.1+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9a291a7c
    • Yisheng Xie's avatar
      mlock: fix mlock count can not decrease in race condition · 70feee0e
      Yisheng Xie authored
      Kefeng reported that when running the follow test, the mlock count in
      meminfo will increase permanently:
      
       [1] testcase
       linux:~ # cat test_mlockal
       grep Mlocked /proc/meminfo
        for j in `seq 0 10`
        do
       	for i in `seq 4 15`
       	do
       		./p_mlockall >> log &
       	done
       	sleep 0.2
       done
       # wait some time to let mlock counter decrease and 5s may not enough
       sleep 5
       grep Mlocked /proc/meminfo
      
       linux:~ # cat p_mlockall.c
       #include <sys/mman.h>
       #include <stdlib.h>
       #include <stdio.h>
      
       #define SPACE_LEN	4096
      
       int main(int argc, char ** argv)
       {
      	 	int ret;
      	 	void *adr = malloc(SPACE_LEN);
      	 	if (!adr)
      	 		return -1;
      
      	 	ret = mlockall(MCL_CURRENT | MCL_FUTURE);
      	 	printf("mlcokall ret = %d\n", ret);
      
      	 	ret = munlockall();
      	 	printf("munlcokall ret = %d\n", ret);
      
      	 	free(adr);
      	 	return 0;
      	 }
      
      In __munlock_pagevec() we should decrement NR_MLOCK for each page where
      we clear the PageMlocked flag.  Commit 1ebb7cc6 ("mm: munlock: batch
      NR_MLOCK zone state updates") has introduced a bug where we don't
      decrement NR_MLOCK for pages where we clear the flag, but fail to
      isolate them from the lru list (e.g.  when the pages are on some other
      cpu's percpu pagevec).  Since PageMlocked stays cleared, the NR_MLOCK
      accounting gets permanently disrupted by this.
      
      Fix it by counting the number of page whose PageMlock flag is cleared.
      
      Fixes: 1ebb7cc6 (" mm: munlock: batch NR_MLOCK zone state updates")
      Link: http://lkml.kernel.org/r/1495678405-54569-1-git-send-email-xieyisheng1@huawei.comSigned-off-by: default avatarYisheng Xie <xieyisheng1@huawei.com>
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Tested-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Joern Engel <joern@logfs.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: zhongjiang <zhongjiang@huawei.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      70feee0e
    • Punit Agrawal's avatar
      mm/migrate: fix refcount handling when !hugepage_migration_supported() · 30809f55
      Punit Agrawal authored
      On failing to migrate a page, soft_offline_huge_page() performs the
      necessary update to the hugepage ref-count.
      
      But when !hugepage_migration_supported() , unmap_and_move_hugepage()
      also decrements the page ref-count for the hugepage.  The combined
      behaviour leaves the ref-count in an inconsistent state.
      
      This leads to soft lockups when running the overcommitted hugepage test
      from mce-tests suite.
      
        Soft offlining pfn 0x83ed600 at process virtual address 0x400000000000
        soft offline: 0x83ed600: migration failed 1, type 1fffc00000008008 (uptodate|head)
        INFO: rcu_preempt detected stalls on CPUs/tasks:
         Tasks blocked on level-0 rcu_node (CPUs 0-7): P2715
          (detected by 7, t=5254 jiffies, g=963, c=962, q=321)
          thugetlb_overco R  running task        0  2715   2685 0x00000008
          Call trace:
            dump_backtrace+0x0/0x268
            show_stack+0x24/0x30
            sched_show_task+0x134/0x180
            rcu_print_detail_task_stall_rnp+0x54/0x7c
            rcu_check_callbacks+0xa74/0xb08
            update_process_times+0x34/0x60
            tick_sched_handle.isra.7+0x38/0x70
            tick_sched_timer+0x4c/0x98
            __hrtimer_run_queues+0xc0/0x300
            hrtimer_interrupt+0xac/0x228
            arch_timer_handler_phys+0x3c/0x50
            handle_percpu_devid_irq+0x8c/0x290
            generic_handle_irq+0x34/0x50
            __handle_domain_irq+0x68/0xc0
            gic_handle_irq+0x5c/0xb0
      
      Address this by changing the putback_active_hugepage() in
      soft_offline_huge_page() to putback_movable_pages().
      
      This only triggers on systems that enable memory failure handling
      (ARCH_SUPPORTS_MEMORY_FAILURE) but not hugepage migration
      (!ARCH_ENABLE_HUGEPAGE_MIGRATION).
      
      I imagine this wasn't triggered as there aren't many systems running
      this configuration.
      
      [akpm@linux-foundation.org: remove dead comment, per Naoya]
      Link: http://lkml.kernel.org/r/20170525135146.32011-1-punit.agrawal@arm.comReported-by: default avatarManoj Iyer <manoj.iyer@canonical.com>
      Tested-by: default avatarManoj Iyer <manoj.iyer@canonical.com>
      Suggested-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Wanpeng Li <wanpeng.li@hotmail.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: <stable@vger.kernel.org>	[3.14+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      30809f55
    • Ross Zwisler's avatar
      dax: fix race between colliding PMD & PTE entries · e2093926
      Ross Zwisler authored
      We currently have two related PMD vs PTE races in the DAX code.  These
      can both be easily triggered by having two threads reading and writing
      simultaneously to the same private mapping, with the key being that
      private mapping reads can be handled with PMDs but private mapping
      writes are always handled with PTEs so that we can COW.
      
      Here is the first race:
      
        CPU 0					CPU 1
      
        (private mapping write)
        __handle_mm_fault()
          create_huge_pmd() - FALLBACK
          handle_pte_fault()
            passes check for pmd_devmap()
      
      					(private mapping read)
      					__handle_mm_fault()
      					  create_huge_pmd()
      					    dax_iomap_pmd_fault() inserts PMD
      
            dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
            			  installed in our page tables at this spot.
      
      Here's the second race:
      
        CPU 0					CPU 1
      
        (private mapping read)
        __handle_mm_fault()
          passes check for pmd_none()
          create_huge_pmd()
            dax_iomap_pmd_fault() inserts PMD
      
        (private mapping write)
        __handle_mm_fault()
          create_huge_pmd() - FALLBACK
      					(private mapping read)
      					__handle_mm_fault()
      					  passes check for pmd_none()
      					  create_huge_pmd()
      
          handle_pte_fault()
            dax_iomap_pte_fault() inserts PTE
      					    dax_iomap_pmd_fault() inserts PMD,
      					       but we already have a PTE at
      					       this spot.
      
      The core of the issue is that while there is isolation between faults to
      the same range in the DAX fault handlers via our DAX entry locking,
      there is no isolation between faults in the code in mm/memory.c.  This
      means for instance that this code in __handle_mm_fault() can run:
      
      	if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
      		ret = create_huge_pmd(&vmf);
      
      But by the time we actually get to run the fault handler called by
      create_huge_pmd(), the PMD is no longer pmd_none() because a racing PTE
      fault has installed a normal PMD here as a parent.  This is the cause of
      the 2nd race.  The first race is similar - there is the following check
      in handle_pte_fault():
      
      	} else {
      		/* See comment in pte_alloc_one_map() */
      		if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
      			return 0;
      
      So if a pmd_devmap() PMD (a DAX PMD) has been installed at vmf->pmd, we
      will bail and retry the fault.  This is correct, but there is nothing
      preventing the PMD from being installed after this check but before we
      actually get to the DAX PTE fault handlers.
      
      In my testing these races result in the following types of errors:
      
        BUG: Bad rss-counter state mm:ffff8800a817d280 idx:1 val:1
        BUG: non-zero nr_ptes on freeing mm: 15
      
      Fix this issue by having the DAX fault handlers verify that it is safe
      to continue their fault after they have taken an entry lock to block
      other racing faults.
      
      [ross.zwisler@linux.intel.com: improve fix for colliding PMD & PTE entries]
        Link: http://lkml.kernel.org/r/20170526195932.32178-1-ross.zwisler@linux.intel.com
      Link: http://lkml.kernel.org/r/20170522215749.23516-2-ross.zwisler@linux.intel.comSigned-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Reported-by: default avatarPawel Lebioda <pawel.lebioda@intel.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Pawel Lebioda <pawel.lebioda@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Xiong Zhou <xzhou@redhat.com>
      Cc: Eryu Guan <eguan@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e2093926