1. 17 Jul, 2018 24 commits
  2. 11 Jul, 2018 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.140 · d6bc7e61
      Greg Kroah-Hartman authored
      d6bc7e61
    • Dan Carpenter's avatar
      staging: comedi: quatech_daqp_cs: fix no-op loop daqp_ao_insn_write() · fecf1ae3
      Dan Carpenter authored
      commit 1376b0a2 upstream.
      
      There is a '>' vs '<' typo so this loop is a no-op.
      
      Fixes: d35dcc89 ("staging: comedi: quatech_daqp_cs: fix daqp_ao_insn_write()")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      fecf1ae3
    • Jann Horn's avatar
      netfilter: nf_log: don't hold nf_log_mutex during user access · 8cff10da
      Jann Horn authored
      commit ce00bf07 upstream.
      
      The old code would indefinitely block other users of nf_log_mutex if
      a userspace access in proc_dostring() blocked e.g. due to a userfaultfd
      region. Fix it by moving proc_dostring() out of the locked region.
      
      This is a followup to commit 266d07cb ("netfilter: nf_log: fix
      sleeping function called from invalid context"), which changed this code
      from using rcu_read_lock() to taking nf_log_mutex.
      
      Fixes: 266d07cb ("netfilter: nf_log: fix sleeping function calle[...]")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8cff10da
    • Tokunori Ikegami's avatar
      mtd: cfi_cmdset_0002: Change erase functions to check chip good only · 242dbd2b
      Tokunori Ikegami authored
      commit 79ca484b upstream.
      
      Currently the functions use to check both chip ready and good.
      But the chip ready is not enough to check the operation status.
      So change this to check the chip good instead of this.
      About the retry functions to make sure the error handling remain it.
      Signed-off-by: default avatarTokunori Ikegami <ikegami@allied-telesis.co.jp>
      Reviewed-by: default avatarJoakim Tjernlund <Joakim.Tjernlund@infinera.com>
      Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
      Cc: Marek Vasut <marek.vasut@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
      Cc: linux-mtd@lists.infradead.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      242dbd2b
    • Tokunori Ikegami's avatar
      mtd: cfi_cmdset_0002: Change erase functions to retry for error · 2e0a09dc
      Tokunori Ikegami authored
      commit 45f75b8a upstream.
      
      For the word write functions it is retried for error.
      But it is not implemented to retry for the erase functions.
      To make sure for the erase functions change to retry as same.
      
      This is needed to prevent the flash erase error caused only once.
      It was caused by the error case of chip_good() in the do_erase_oneblock().
      Also it was confirmed on the MACRONIX flash device MX29GL512FHT2I-11G.
      But the error issue behavior is not able to reproduce at this moment.
      The flash controller is parallel Flash interface integrated on BCM53003.
      Signed-off-by: default avatarTokunori Ikegami <ikegami@allied-telesis.co.jp>
      Reviewed-by: default avatarJoakim Tjernlund <Joakim.Tjernlund@infinera.com>
      Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
      Cc: Marek Vasut <marek.vasut@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
      Cc: linux-mtd@lists.infradead.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e0a09dc
    • Tokunori Ikegami's avatar
      mtd: cfi_cmdset_0002: Change definition naming to retry write operation · 100b8c94
      Tokunori Ikegami authored
      commit 85a82e28 upstream.
      
      The definition can be used for other program and erase operations also.
      So change the naming to MAX_RETRIES from MAX_WORD_RETRIES.
      Signed-off-by: default avatarTokunori Ikegami <ikegami@allied-telesis.co.jp>
      Reviewed-by: default avatarJoakim Tjernlund <Joakim.Tjernlund@infinera.com>
      Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
      Cc: Marek Vasut <marek.vasut@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
      Cc: linux-mtd@lists.infradead.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      100b8c94
    • Mikulas Patocka's avatar
      dm bufio: don't take the lock in dm_bufio_shrink_count · 5be6e45d
      Mikulas Patocka authored
      commit d12067f4 upstream.
      
      dm_bufio_shrink_count() is called from do_shrink_slab to find out how many
      freeable objects are there. The reported value doesn't have to be precise,
      so we don't need to take the dm-bufio lock.
      Suggested-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5be6e45d
    • Martin Kaiser's avatar
      mtd: rawnand: mxc: set spare area size register explicitly · bf4e6336
      Martin Kaiser authored
      commit 3f77f244 upstream.
      
      The v21 version of the NAND flash controller contains a Spare Area Size
      Register (SPAS) at offset 0x10. Its setting defaults to the maximum
      spare area size of 218 bytes. The size that is set in this register is
      used by the controller when it calculates the ECC bytes internally in
      hardware.
      
      Usually, this register is updated from settings in the IIM fuses when
      the system is booting from NAND flash. For other boot media, however,
      the SPAS register remains at the default setting, which may not work for
      the particular flash chip on the board. The same goes for flash chips
      whose configuration cannot be set in the IIM fuses (e.g. chips with 2k
      sector size and 128 bytes spare area size can't be configured in the IIM
      fuses on imx25 systems).
      
      Set the SPAS register explicitly during the preset operation. Derive the
      register value from mtd->oobsize that was detected during probe by
      decoding the flash chip's ID bytes.
      
      While at it, rename the define for the spare area register's offset to
      NFC_V21_RSLTSPARE_AREA. The register at offset 0x10 on v1 controllers is
      different from the register on v21 controllers.
      
      Fixes: d4840180 ("mtd: mxc_nand: set NFC registers after reset")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMartin Kaiser <martin@kaiser.cx>
      Reviewed-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Reviewed-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      bf4e6336
    • Mikulas Patocka's avatar
      dm bufio: drop the lock when doing GFP_NOIO allocation · 3ce44cad
      Mikulas Patocka authored
      commit 41c73a49 upstream.
      
      If the first allocation attempt using GFP_NOWAIT fails, drop the lock
      and retry using GFP_NOIO allocation (lock is dropped because the
      allocation can take some time).
      
      Note that we won't do GFP_NOIO allocation when we loop for the second
      time, because the lock shouldn't be dropped between __wait_for_free_buffer
      and __get_unclaimed_buffer.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ce44cad
    • Douglas Anderson's avatar
      dm bufio: avoid sleeping while holding the dm_bufio lock · 7396cb30
      Douglas Anderson authored
      commit 9ea61cac upstream.
      
      We've seen in-field reports showing _lots_ (18 in one case, 41 in
      another) of tasks all sitting there blocked on:
      
        mutex_lock+0x4c/0x68
        dm_bufio_shrink_count+0x38/0x78
        shrink_slab.part.54.constprop.65+0x100/0x464
        shrink_zone+0xa8/0x198
      
      In the two cases analyzed, we see one task that looks like this:
      
        Workqueue: kverityd verity_prefetch_io
      
        __switch_to+0x9c/0xa8
        __schedule+0x440/0x6d8
        schedule+0x94/0xb4
        schedule_timeout+0x204/0x27c
        schedule_timeout_uninterruptible+0x44/0x50
        wait_iff_congested+0x9c/0x1f0
        shrink_inactive_list+0x3a0/0x4cc
        shrink_lruvec+0x418/0x5cc
        shrink_zone+0x88/0x198
        try_to_free_pages+0x51c/0x588
        __alloc_pages_nodemask+0x648/0xa88
        __get_free_pages+0x34/0x7c
        alloc_buffer+0xa4/0x144
        __bufio_new+0x84/0x278
        dm_bufio_prefetch+0x9c/0x154
        verity_prefetch_io+0xe8/0x10c
        process_one_work+0x240/0x424
        worker_thread+0x2fc/0x424
        kthread+0x10c/0x114
      
      ...and that looks to be the one holding the mutex.
      
      The problem has been reproduced on fairly easily:
      0. Be running Chrome OS w/ verity enabled on the root filesystem
      1. Pick test patch: http://crosreview.com/412360
      2. Install launchBalloons.sh and balloon.arm from
           http://crbug.com/468342
         ...that's just a memory stress test app.
      3. On a 4GB rk3399 machine, run
           nice ./launchBalloons.sh 4 900 100000
         ...that tries to eat 4 * 900 MB of memory and keep accessing.
      4. Login to the Chrome web browser and restore many tabs
      
      With that, I've seen printouts like:
        DOUG: long bufio 90758 ms
      ...and stack trace always show's we're in dm_bufio_prefetch().
      
      The problem is that we try to allocate memory with GFP_NOIO while
      we're holding the dm_bufio lock.  Instead we should be using
      GFP_NOWAIT.  Using GFP_NOIO can cause us to sleep while holding the
      lock and that causes the above problems.
      
      The current behavior explained by David Rientjes:
      
        It will still try reclaim initially because __GFP_WAIT (or
        __GFP_KSWAPD_RECLAIM) is set by GFP_NOIO.  This is the cause of
        contention on dm_bufio_lock() that the thread holds.  You want to
        pass GFP_NOWAIT instead of GFP_NOIO to alloc_buffer() when holding a
        mutex that can be contended by a concurrent slab shrinker (if
        count_objects didn't use a trylock, this pattern would trivially
        deadlock).
      
      This change significantly increases responsiveness of the system while
      in this state.  It makes a real difference because it unblocks kswapd.
      In the bug report analyzed, kswapd was hung:
      
         kswapd0         D ffffffc000204fd8     0    72      2 0x00000000
         Call trace:
         [<ffffffc000204fd8>] __switch_to+0x9c/0xa8
         [<ffffffc00090b794>] __schedule+0x440/0x6d8
         [<ffffffc00090bac0>] schedule+0x94/0xb4
         [<ffffffc00090be44>] schedule_preempt_disabled+0x28/0x44
         [<ffffffc00090d900>] __mutex_lock_slowpath+0x120/0x1ac
         [<ffffffc00090d9d8>] mutex_lock+0x4c/0x68
         [<ffffffc000708e7c>] dm_bufio_shrink_count+0x38/0x78
         [<ffffffc00030b268>] shrink_slab.part.54.constprop.65+0x100/0x464
         [<ffffffc00030dbd8>] shrink_zone+0xa8/0x198
         [<ffffffc00030e578>] balance_pgdat+0x328/0x508
         [<ffffffc00030eb7c>] kswapd+0x424/0x51c
         [<ffffffc00023f06c>] kthread+0x10c/0x114
         [<ffffffc000203dd0>] ret_from_fork+0x10/0x40
      
      By unblocking kswapd memory pressure should be reduced.
      Suggested-by: default avatarDavid Rientjes <rientjes@google.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7396cb30
    • Vlastimil Babka's avatar
      mm, page_alloc: do not break __GFP_THISNODE by zonelist reset · aaf87537
      Vlastimil Babka authored
      commit 7810e678 upstream.
      
      In __alloc_pages_slowpath() we reset zonelist and preferred_zoneref for
      allocations that can ignore memory policies.  The zonelist is obtained
      from current CPU's node.  This is a problem for __GFP_THISNODE
      allocations that want to allocate on a different node, e.g.  because the
      allocating thread has been migrated to a different CPU.
      
      This has been observed to break SLAB in our 4.4-based kernel, because
      there it relies on __GFP_THISNODE working as intended.  If a slab page
      is put on wrong node's list, then further list manipulations may corrupt
      the list because page_to_nid() is used to determine which node's
      list_lock should be locked and thus we may take a wrong lock and race.
      
      Current SLAB implementation seems to be immune by luck thanks to commit
      511e3a05 ("mm/slab: make cache_grow() handle the page allocated on
      arbitrary node") but there may be others assuming that __GFP_THISNODE
      works as promised.
      
      We can fix it by simply removing the zonelist reset completely.  There
      is actually no reason to reset it, because memory policies and cpusets
      don't affect the zonelist choice in the first place.  This was different
      when commit 183f6371 ("mm: ignore mempolicies when using
      ALLOC_NO_WATERMARK") introduced the code, as mempolicies provided their
      own restricted zonelists.
      
      We might consider this for 4.17 although I don't know if there's
      anything currently broken.
      
      SLAB is currently not affected, but in kernels older than 4.7 that don't
      yet have 511e3a05 ("mm/slab: make cache_grow() handle the page
      allocated on arbitrary node") it is.  That's at least 4.4 LTS.  Older
      ones I'll have to check.
      
      So stable backports should be more important, but will have to be
      reviewed carefully, as the code went through many changes.  BTW I think
      that also the ac->preferred_zoneref reset is currently useless if we
      don't also reset ac->nodemask from a mempolicy to NULL first (which we
      probably should for the OOM victims etc?), but I would leave that for a
      separate patch.
      
      Link: http://lkml.kernel.org/r/20180525130853.13915-1-vbabka@suse.czSigned-off-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Fixes: 183f6371 ("mm: ignore mempolicies when using ALLOC_NO_WATERMARK")
      Acked-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aaf87537
    • Brad Love's avatar
      media: cx25840: Use subdev host data for PLL override · 7f9c65ea
      Brad Love authored
      commit 3ee9bc12 upstream.
      
      The cx25840 driver currently configures 885, 887, and 888 using
      default divisors for each chip. This check to see if the cx23885
      driver has passed the cx25840 a non-default clock rate for a
      specific chip. If a cx23885 board has left clk_freq at 0, the
      clock default values will be used to configure the PLLs.
      
      This patch only has effect on 888 boards who set clk_freq to 25M.
      Signed-off-by: default avatarBrad Love <brad@nextdimension.cc>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f9c65ea
    • Tony Luck's avatar
      x86/mce: Fix incorrect "Machine check from unknown source" message · 99b6d2c3
      Tony Luck authored
      commit 40c36e27 upstream.
      
      Some injection testing resulted in the following console log:
      
        mce: [Hardware Error]: CPU 22: Machine Check Exception: f Bank 1: bd80000000100134
        mce: [Hardware Error]: RIP 10:<ffffffffc05292dd> {pmem_do_bvec+0x11d/0x330 [nd_pmem]}
        mce: [Hardware Error]: TSC c51a63035d52 ADDR 3234bc4000 MISC 88
        mce: [Hardware Error]: PROCESSOR 0:50654 TIME 1526502199 SOCKET 0 APIC 38 microcode 2000043
        mce: [Hardware Error]: Run the above through 'mcelog --ascii'
        Kernel panic - not syncing: Machine check from unknown source
      
      This confused everybody because the first line quite clearly shows
      that we found a logged error in "Bank 1", while the last line says
      "unknown source".
      
      The problem is that the Linux code doesn't do the right thing
      for a local machine check that results in a fatal error.
      
      It turns out that we know very early in the handler whether the
      machine check is fatal. The call to mce_no_way_out() has checked
      all the banks for the CPU that took the local machine check. If
      it says we must crash, we can do so right away with the right
      messages.
      
      We do scan all the banks again. This means that we might initially
      not see a problem, but during the second scan find something fatal.
      If this happens we print a slightly different message (so I can
      see if it actually every happens).
      
      [ bp: Remove unneeded severity assignment. ]
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: stable@vger.kernel.org # 4.2
      Link: http://lkml.kernel.org/r/52e049a497e86fd0b71c529651def8871c804df0.1527283897.git.tony.luck@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99b6d2c3
    • Yazen Ghannam's avatar
      x86/mce: Detect local MCEs properly · e462d226
      Yazen Ghannam authored
      commit fead35c6 upstream.
      
      Check the MCG_STATUS_LMCES bit on Intel to verify that current MCE is
      local. It is always local on AMD.
      Signed-off-by: default avatarYazen Ghannam <Yazen.Ghannam@amd.com>
      [ Massaged it a bit. Reflowed comments. Shut up -Wmaybe-uninitialized. ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      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: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1462019637-16474-8-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e462d226
    • Daniel Rosenberg's avatar
      HID: debug: check length before copy_to_user() · ef111ea3
      Daniel Rosenberg authored
      commit 717adfda upstream.
      
      If our length is greater than the size of the buffer, we
      overflow the buffer
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Rosenberg <drosen@google.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef111ea3
    • Gustavo A. R. Silva's avatar
      HID: hiddev: fix potential Spectre v1 · c0b166a6
      Gustavo A. R. Silva authored
      commit 4f65245f upstream.
      
      uref->field_index, uref->usage_index, finfo.field_index and cinfo.index can be
      indirectly controlled by user-space, hence leading to a potential exploitation
      of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      drivers/hid/usbhid/hiddev.c:473 hiddev_ioctl_usage() warn: potential spectre issue 'report->field' (local cap)
      drivers/hid/usbhid/hiddev.c:477 hiddev_ioctl_usage() warn: potential spectre issue 'field->usage' (local cap)
      drivers/hid/usbhid/hiddev.c:757 hiddev_ioctl() warn: potential spectre issue 'report->field' (local cap)
      drivers/hid/usbhid/hiddev.c:801 hiddev_ioctl() warn: potential spectre issue 'hid->collection' (local cap)
      
      Fix this by sanitizing such structure fields before using them to index
      report->field, field->usage and hid->collection
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0b166a6