1. 13 Jan, 2017 7 commits
  2. 12 Jan, 2017 1 commit
  3. 24 Dec, 2016 1 commit
  4. 23 Dec, 2016 19 commits
  5. 22 Dec, 2016 9 commits
    • Andy Lutomirski's avatar
      x86/init: Fix cr4_init_shadow() on CR4-less machines · e06ded86
      Andy Lutomirski authored
      [ Upstream commit e1bfc11c ]
      
      cr4_init_shadow() will panic on 486-like machines without CR4.  Fix
      it using __read_cr4_safe().
      
      Reported-by: david@saggiorato.net
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Fixes: 1e02ce4c ("x86: Store a per-cpu shadow copy of CR4")
      Link: http://lkml.kernel.org/r/43a20f81fb504013bf613913dc25574b45336a61.1475091074.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e06ded86
    • Roger Quadros's avatar
      ARM: 8617/1: dma: fix dma_max_pfn() · eec74693
      Roger Quadros authored
      [ Upstream commit d248220f ]
      
      Since commit 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation"),
      dma_to_pfn() already returns the PFN with the physical memory start offset
      so we don't need to add it again.
      
      This fixes USB mass storage lock-up problem on systems that can't do DMA
      over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM
      can only do DMA over the first 2GB. [K2E-EVM].
      
      What happens there is that without this patch SCSI layer sets a wrong
      bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass
      storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit
      is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2
      is 0x87fffffff. This results in non DMA'ble pages being given to the
      USB controller and hence the lock-up.
      
      NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0.
      This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000
      and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be
      0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because
      USB devices are not correctly inheriting the dma_pfn_offset from the
      USB host controller. This will be fixed by a separate patch.
      
      Fixes: 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation")
      Cc: stable@vger.kernel.org
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Reported-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      eec74693
    • zhong jiang's avatar
      mm,ksm: fix endless looping in allocating memory when ksm enable · 58024f82
      zhong jiang authored
      [ Upstream commit 5b398e41 ]
      
      I hit the following hung task when runing a OOM LTP test case with 4.1
      kernel.
      
      Call trace:
      [<ffffffc000086a88>] __switch_to+0x74/0x8c
      [<ffffffc000a1bae0>] __schedule+0x23c/0x7bc
      [<ffffffc000a1c09c>] schedule+0x3c/0x94
      [<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350
      [<ffffffc000a1e32c>] down_write+0x64/0x80
      [<ffffffc00021f794>] __ksm_exit+0x90/0x19c
      [<ffffffc0000be650>] mmput+0x118/0x11c
      [<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74
      [<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4
      [<ffffffc0000d0f34>] get_signal+0x444/0x5e0
      [<ffffffc000089fcc>] do_signal+0x1d8/0x450
      [<ffffffc00008a35c>] do_notify_resume+0x70/0x78
      
      The oom victim cannot terminate because it needs to take mmap_sem for
      write while the lock is held by ksmd for read which loops in the page
      allocator
      
      ksm_do_scan
      	scan_get_next_rmap_item
      		down_read
      		get_next_rmap_item
      			alloc_rmap_item   #ksmd will loop permanently.
      
      There is no way forward because the oom victim cannot release any memory
      in 4.1 based kernel.  Since 4.6 we have the oom reaper which would solve
      this problem because it would release the memory asynchronously.
      Nevertheless we can relax alloc_rmap_item requirements and use
      __GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan
      would just retry later after the lock got dropped.
      
      Such a patch would be also easy to backport to older stable kernels which
      do not have oom_reaper.
      
      While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed
      by the allocation failure.
      
      Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.comSigned-off-by: default avatarzhong jiang <zhongjiang@huawei.com>
      Suggested-by: default avatarHugh Dickins <hughd@google.com>
      Suggested-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarHugh Dickins <hughd@google.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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      58024f82
    • Sergei Miroshnichenko's avatar
      can: dev: fix deadlock reported after bus-off · d427d645
      Sergei Miroshnichenko authored
      [ Upstream commit 9abefcb1 ]
      
      A timer was used to restart after the bus-off state, leading to a
      relatively large can_restart() executed in an interrupt context,
      which in turn sets up pinctrl. When this happens during system boot,
      there is a high probability of grabbing the pinctrl_list_mutex,
      which is locked already by the probe() of other device, making the
      kernel suspect a deadlock condition [1].
      
      To resolve this issue, the restart_timer is replaced by a delayed
      work.
      
      [1] https://github.com/victronenergy/venus/issues/24Signed-off-by: default avatarSergei Miroshnichenko <sergeimir@emcraft.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d427d645
    • Joonwoo Park's avatar
      cpuset: handle race between CPU hotplug and cpuset_hotplug_work · 791a9289
      Joonwoo Park authored
      [ Upstream commit 28b89b9e ]
      
      A discrepancy between cpu_online_mask and cpuset's effective_cpus
      mask is inevitable during hotplug since cpuset defers updating of
      effective_cpus mask using a workqueue, during which time nothing
      prevents the system from more hotplug operations.  For that reason
      guarantee_online_cpus() walks up the cpuset hierarchy until it finds
      an intersection under the assumption that top cpuset's effective_cpus
      mask intersects with cpu_online_mask even with such a race occurring.
      
      However a sequence of CPU hotplugs can open a time window, during which
      none of the effective CPUs in the top cpuset intersect with
      cpu_online_mask.
      
      For example when there are 4 possible CPUs 0-3 and only CPU0 is online:
      
        ========================  ===========================
         cpu_online_mask           top_cpuset.effective_cpus
        ========================  ===========================
         echo 1 > cpu2/online.
         CPU hotplug notifier woke up hotplug work but not yet scheduled.
            [0,2]                     [0]
      
         echo 0 > cpu0/online.
         The workqueue is still runnable.
            [2]                       [0]
        ========================  ===========================
      
        Now there is no intersection between cpu_online_mask and
        top_cpuset.effective_cpus.  Thus invoking sys_sched_setaffinity() at
        this moment can cause following:
      
         Unable to handle kernel NULL pointer dereference at virtual address 000000d0
         ------------[ cut here ]------------
         Kernel BUG at ffffffc0001389b0 [verbose debug info unavailable]
         Internal error: Oops - BUG: 96000005 [#1] PREEMPT SMP
         Modules linked in:
         CPU: 2 PID: 1420 Comm: taskset Tainted: G        W       4.4.8+ #98
         task: ffffffc06a5c4880 ti: ffffffc06e124000 task.ti: ffffffc06e124000
         PC is at guarantee_online_cpus+0x2c/0x58
         LR is at cpuset_cpus_allowed+0x4c/0x6c
         <snip>
         Process taskset (pid: 1420, stack limit = 0xffffffc06e124020)
         Call trace:
         [<ffffffc0001389b0>] guarantee_online_cpus+0x2c/0x58
         [<ffffffc00013b208>] cpuset_cpus_allowed+0x4c/0x6c
         [<ffffffc0000d61f0>] sched_setaffinity+0xc0/0x1ac
         [<ffffffc0000d6374>] SyS_sched_setaffinity+0x98/0xac
         [<ffffffc000085cb0>] el0_svc_naked+0x24/0x28
      
      The top cpuset's effective_cpus are guaranteed to be identical to
      cpu_online_mask eventually.  Hence fall back to cpu_online_mask when
      there is no intersection between top cpuset's effective_cpus and
      cpu_online_mask.
      Signed-off-by: default avatarJoonwoo Park <joonwoop@codeaurora.org>
      Acked-by: default avatarLi Zefan <lizefan@huawei.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: cgroups@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.17+
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      791a9289
    • Karl Beldan's avatar
      mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl · 6b82b060
      Karl Beldan authored
      [ Upstream commit f6d7c1b5 ]
      
      This fixes subpage writes when using 4-bit HW ECC.
      
      There has been numerous reports about ECC errors with devices using this
      driver for a while.  Also the 4-bit ECC has been reported as broken with
      subpages in [1] and with 16 bits NANDs in the driver and in mach* board
      files both in mainline and in the vendor BSPs.
      
      What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
      try reinitializing the ECC engine:
      - R/W on whole pages properly generates/checks RS code
      - try writing the 1st subpage only of a blank page, the subpage is well
        written and the RS code properly generated, re-reading the same page
        the HW detects some ECC error, reading the same page again no ECC
        error is detected
      
      Note that the ECC engine is already reinitialized in the 1-bit case.
      
      Tested on my LCDK with UBI+UBIFS using subpages.
      This could potentially get rid of the issue workarounded in [1].
      
      [1] 28c015a9 ("mtd: davinci-nand: disable subpage write for keystone-nand")
      
      Fixes: 6a4123e5 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKarl Beldan <kbeldan@baylibre.com>
      Acked-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6b82b060
    • Rob Clark's avatar
      drm/msm: fix use of copy_from_user() while holding spinlock · e537a097
      Rob Clark authored
      [ Upstream commit 89f82cbb ]
      
      Use instead __copy_from_user_inatomic() and fallback to slow-path where
      we drop and re-aquire the lock in case of fault.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarVaishali Thakkar <vaishali.thakkar@oracle.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e537a097
    • Pawel Moll's avatar
      bus: arm-ccn: Fix PMU handling of MN · b56eb9cd
      Pawel Moll authored
      [ Upstream commit 4e486cba ]
      
      The "Miscellaneous Node" fell through cracks of node initialisation,
      as its ID is shared with HN-I.
      
      This patch treats MN as a special case (which it is), adding separate
      validation check for it and pre-defining the node ID in relevant events
      descriptions. That way one can simply run:
      
      	# perf stat -a -e ccn/mn_ecbarrier/ <workload>
      
      Additionally, direction in the MN pseudo-events XP watchpoint
      definitions is corrected to be "TX" (1) as they are defined from the
      crosspoint point of view (thus barriers are transmitted from XP to MN).
      
      Cc: stable@vger.kernel.org # 3.17+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b56eb9cd
    • Pawel Moll's avatar
      bus: arm-ccn: Provide required event arguments · 7298a8bf
      Pawel Moll authored
      [ Upstream commit 8f06c51f ]
      
      Since 688d4dfc "perf tools: Support
      parsing parameterized events" the perf userspace tools understands
      "argument=?" syntax in the events file, making sure that required
      arguments are provided by the user and not defaulting to 0, causing
      confusion.
      
      This patch adds the required arguments lists for CCN events.
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7298a8bf
  6. 29 Nov, 2016 1 commit
  7. 26 Nov, 2016 2 commits
    • Sebastian Andrzej Siewior's avatar
      kbuild: add -fno-PIE · 39f99860
      Sebastian Andrzej Siewior authored
      [ Upstream commit 8ae94224 ]
      
      Debian started to build the gcc with -fPIE by default so the kernel
      build ends before it starts properly with:
      |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
      
      Also add to KBUILD_AFLAGS due to:
      
      |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
      |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic
      
      Tagging it stable so it is possible to compile recent stable kernels as
      well.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      39f99860
    • Stefan Richter's avatar
      firewire: net: fix fragmented datagram_size off-by-one · bf5d3d29
      Stefan Richter authored
      [ Upstream commit e9300a4b ]
      
      RFC 2734 defines the datagram_size field in fragment encapsulation
      headers thus:
      
          datagram_size:  The encoded size of the entire IP datagram.  The
          value of datagram_size [...] SHALL be one less than the value of
          Total Length in the datagram's IP header (see STD 5, RFC 791).
      
      Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
      this field with a -/+1 offset:
      
          ether1394_tx() /* transmit */
              ether1394_encapsulate_prep()
                  hdr->ff.dg_size = dg_size - 1;
      
          ether1394_data_handler() /* receive */
              if (hdr->common.lf == ETH1394_HDR_LF_FF)
                  dg_size = hdr->ff.dg_size + 1;
              else
                  dg_size = hdr->sf.dg_size + 1;
      
      Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
      byte sized datagrams in fragments with datagram_size=1499 if link
      fragmentation is required.
      
      Only firewire-net sets and gets datagram_size without this offset.  The
      result is lacking interoperability of firewire-net with OS X, Windows
      XP, and presumably Linux' eth1394.  (I did not test with the latter.)
      For example, FTP data transfers to a Linux firewire-net box with max_rec
      smaller than the 1500 bytes MTU
        - from OS X fail entirely,
        - from Win XP start out with a bunch of fragmented datagrams which
          time out, then continue with unfragmented datagrams because Win XP
          temporarily reduces the MTU to 576 bytes.
      
      So let's fix firewire-net's datagram_size accessors.
      
      Note that firewire-net thereby loses interoperability with unpatched
      firewire-net, but only if link fragmentation is employed.  (This happens
      with large broadcast datagrams, and with large datagrams on several
      FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
      and it can be worked around by setting a small enough MTU.)
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bf5d3d29