1. 02 Mar, 2016 5 commits
  2. 25 Feb, 2016 19 commits
  3. 24 Feb, 2016 16 commits
    • Naoya Horiguchi's avatar
      mm: soft-offline: check return value in second __get_any_page() call · 5b48ad31
      Naoya Horiguchi authored
      commit d96b339f upstream.
      
      I saw the following BUG_ON triggered in a testcase where a process calls
      madvise(MADV_SOFT_OFFLINE) on thps, along with a background process that
      calls migratepages command repeatedly (doing ping-pong among different
      NUMA nodes) for the first process:
      
         Soft offlining page 0x60000 at 0x700000600000
         __get_any_page: 0x60000 free buddy page
         page:ffffea0001800000 count:0 mapcount:-127 mapping:          (null) index:0x1
         flags: 0x1fffc0000000000()
         page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
         ------------[ cut here ]------------
         kernel BUG at /src/linux-dev/include/linux/mm.h:342!
         invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
         Modules linked in: cfg80211 rfkill crc32c_intel serio_raw virtio_balloon i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi
         CPU: 3 PID: 3035 Comm: test_alloc_gene Tainted: G           O    4.4.0-rc8-v4.4-rc8-160107-1501-00000-rc8+ #74
         Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
         task: ffff88007c63d5c0 ti: ffff88007c210000 task.ti: ffff88007c210000
         RIP: 0010:[<ffffffff8118998c>]  [<ffffffff8118998c>] put_page+0x5c/0x60
         RSP: 0018:ffff88007c213e00  EFLAGS: 00010246
         Call Trace:
           put_hwpoison_page+0x4e/0x80
           soft_offline_page+0x501/0x520
           SyS_madvise+0x6bc/0x6f0
           entry_SYSCALL_64_fastpath+0x12/0x6a
         Code: 8b fc ff ff 5b 5d c3 48 89 df e8 b0 fa ff ff 48 89 df 31 f6 e8 c6 7d ff ff 5b 5d c3 48 c7 c6 08 54 a2 81 48 89 df e8 a4 c5 01 00 <0f> 0b 66 90 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b 47
         RIP  [<ffffffff8118998c>] put_page+0x5c/0x60
          RSP <ffff88007c213e00>
      
      The root cause resides in get_any_page() which retries to get a refcount
      of the page to be soft-offlined.  This function calls
      put_hwpoison_page(), expecting that the target page is putback to LRU
      list.  But it can be also freed to buddy.  So the second check need to
      care about such case.
      
      Fixes: af8fae7c ("mm/memory-failure.c: clean up soft_offline_page()")
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      5b48ad31
    • Roman Gushchin's avatar
      fuse: break infinite loop in fuse_fill_write_pages() · affc1b9e
      Roman Gushchin authored
      commit 3ca8138f upstream.
      
      I got a report about unkillable task eating CPU. Further
      investigation shows, that the problem is in the fuse_fill_write_pages()
      function. If iov's first segment has zero length, we get an infinite
      loop, because we never reach iov_iter_advance() call.
      
      Fix this by calling iov_iter_advance() before repeating an attempt to
      copy data from userspace.
      
      A similar problem is described in 124d3b70 ("fix writev regression:
      pan hanging unkillable and un-straceable"). If zero-length segmend
      is followed by segment with invalid address,
      iov_iter_fault_in_readable() checks only first segment (zero-length),
      iov_iter_copy_from_user_atomic() skips it, fails at second and
      returns zero -> goto again without skipping zero-length segment.
      
      Patch calls iov_iter_advance() before goto again: we'll skip zero-length
      segment at second iteraction and iov_iter_fault_in_readable() will detect
      invalid address.
      
      Special thanks to Konstantin Khlebnikov, who helped a lot with the commit
      description.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Maxim Patlasov <mpatlasov@parallels.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarRoman Gushchin <klamm@yandex-team.ru>
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Fixes: ea9b9907 ("fuse: implement perform_write")
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      affc1b9e
    • Linus Walleij's avatar
      ARM: 8517/1: ICST: avoid arithmetic overflow in icst_hz() · 8c6bd581
      Linus Walleij authored
      commit 5070fb14 upstream.
      
      When trying to set the ICST 307 clock to 25174000 Hz I ran into
      this arithmetic error: the icst_hz_to_vco() correctly figure out
      DIVIDE=2, RDW=100 and VDW=99 yielding a frequency of
      25174000 Hz out of the VCO. (I replicated the icst_hz() function
      in a spreadsheet to verify this.)
      
      However, when I called icst_hz() on these VCO settings it would
      instead return 4122709 Hz. This causes an error in the common
      clock driver for ICST as the common clock framework will call
      .round_rate() on the clock which will utilize icst_hz_to_vco()
      followed by icst_hz() suggesting the erroneous frequency, and
      then the clock gets set to this.
      
      The error did not manifest in the old clock framework since
      this high frequency was only used by the CLCD, which calls
      clk_set_rate() without first calling clk_round_rate() and since
      the old clock framework would not call clk_round_rate() before
      setting the frequency, the correct values propagated into
      the VCO.
      
      After some experimenting I figured out that it was due to a simple
      arithmetic overflow: the divisor for 24Mhz reference frequency
      as reference becomes 24000000*2*(99+8)=0x132212400 and the "1"
      in bit 32 overflows and is lost.
      
      But introducing an explicit 64-by-32 bit do_div() and casting
      the divisor into (u64) we get the right frequency back, and the
      right frequency gets set.
      
      Tested on the ARM Versatile.
      
      Cc: linux-clk@vger.kernel.org
      Cc: Pawel Moll <pawel.moll@arm.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8c6bd581
    • Linus Walleij's avatar
      ARM: 8519/1: ICST: try other dividends than 1 · d306ee9e
      Linus Walleij authored
      commit e972c374 upstream.
      
      Since the dawn of time the ICST code has only supported divide
      by one or hang in an eternal loop. Luckily we were always dividing
      by one because the reference frequency for the systems using
      the ICSTs is 24MHz and the [min,max] values for the PLL input
      if [10,320] MHz for ICST307 and [6,200] for ICST525, so the loop
      will always terminate immediately without assigning any divisor
      for the reference frequency.
      
      But for the code to make sense, let's insert the missing i++
      Reported-by: default avatarDavid Binderman <dcb314@hotmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d306ee9e
    • Anson Huang's avatar
      ARM: 8471/1: need to save/restore arm register(r11) when it is corrupted · 02d2716d
      Anson Huang authored
      commit fa0708b3 upstream.
      
      In cpu_v7_do_suspend routine, r11 is used while it is NOT
      saved/restored, different compiler may have different usage
      of ARM general registers, so it may cause issues during
      calling cpu_v7_do_suspend.
      
      We meet kernel fault occurs when using GCC 4.8.3, r11 contains
      valid value before calling into cpu_v7_do_suspend, but when returned
      from this routine, r11 is corrupted and lead to kernel fault.
      Doing save/restore for those corrupted registers is a must in
      assemble code.
      Signed-off-by: default avatarAnson Huang <Anson.Huang@freescale.com>
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      02d2716d
    • Helmut Klein's avatar
      ARM: dts: Kirkwood: Fix QNAP TS219 power-off · 58893eec
      Helmut Klein authored
      commit 5442f0ea upstream.
      
      The "reg" entry in the "poweroff" section of "kirkwood-ts219.dtsi"
      addressed the wrong uart (0 = console). This patch changes the address
      to select uart 1, which is the uart connected to the pic
      microcontroller, which can switch the device off.
      Signed-off-by: default avatarHelmut Klein <hgkr.klein@gmail.com>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Fixes: 4350a47b ("ARM: Kirkwood: Make use of the QNAP Power off driver.")
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      58893eec
    • Andrew Gabbasov's avatar
      udf: Check output buffer length when converting name to CS0 · fc530807
      Andrew Gabbasov authored
      commit bb00c898 upstream.
      
      If a name contains at least some characters with Unicode values
      exceeding single byte, the CS0 output should have 2 bytes per character.
      And if other input characters have single byte Unicode values, then
      the single input byte is converted to 2 output bytes, and the length
      of output becomes larger than the length of input. And if the input
      name is long enough, the output length may exceed the allocated buffer
      length.
      
      All this means that conversion from UTF8 or NLS to CS0 requires
      checking of output length in order to stop when it exceeds the given
      output buffer size.
      
      [JK: Make code return -ENAMETOOLONG instead of silently truncating the
      name]
      Signed-off-by: default avatarAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      fc530807
    • Andrew Gabbasov's avatar
      udf: Prevent buffer overrun with multi-byte characters · b20777e7
      Andrew Gabbasov authored
      commit ad402b26 upstream.
      
      udf_CS0toUTF8 function stops the conversion when the output buffer
      length reaches UDF_NAME_LEN-2, which is correct maximum name length,
      but, when checking, it leaves the space for a single byte only,
      while multi-bytes output characters can take more space, causing
      buffer overflow.
      
      Similar error exists in udf_CS0toNLS function, that restricts
      the output length to UDF_NAME_LEN, while actual maximum allowed
      length is UDF_NAME_LEN-2.
      
      In these cases the output can override not only the current buffer
      length field, causing corruption of the name buffer itself, but also
      following allocation structures, causing kernel crash.
      
      Adjust the output length checks in both functions to prevent buffer
      overruns in case of multi-bytes UTF8 or NLS characters.
      Signed-off-by: default avatarAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b20777e7
    • Vegard Nossum's avatar
      udf: limit the maximum number of indirect extents in a row · ac79eb71
      Vegard Nossum authored
      commit b0918d9f upstream.
      
      udf_next_aext() just follows extent pointers while extents are marked as
      indirect. This can loop forever for corrupted filesystem. Limit number
      the of indirect extents we are willing to follow in a row.
      
      [JK: Updated changelog, limit, style]
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Cc: Jan Kara <jack@suse.com>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ac79eb71
    • Andrew Elble's avatar
      nfs: Fix race in __update_open_stateid() · d92f5225
      Andrew Elble authored
      commit 361cad3c upstream.
      
      We've seen this in a packet capture - I've intermixed what I
      think was going on. The fix here is to grab the so_lock sooner.
      
      1964379 -> #1 open (for write) reply seqid=1
      1964393 -> #2 open (for read) reply seqid=2
      
        __nfs4_close(), state->n_wronly--
        nfs4_state_set_mode_locked(), changes state->state = [R]
        state->flags is [RW]
        state->state is [R], state->n_wronly == 0, state->n_rdonly == 1
      
      1964398 -> #3 open (for write) call -> because close is already running
      1964399 -> downgrade (to read) call seqid=2 (close of #1)
      1964402 -> #3 open (for write) reply seqid=3
      
       __update_open_stateid()
         nfs_set_open_stateid_locked(), changes state->flags
         state->flags is [RW]
         state->state is [R], state->n_wronly == 0, state->n_rdonly == 1
         new sequence number is exposed now via nfs4_stateid_copy()
      
         next step would be update_open_stateflags(), pending so_lock
      
      1964403 -> downgrade reply seqid=2, fails with OLD_STATEID (close of #1)
      
         nfs4_close_prepare() gets so_lock and recalcs flags -> send close
      
      1964405 -> downgrade (to read) call seqid=3 (close of #1 retry)
      
         __update_open_stateid() gets so_lock
       * update_open_stateflags() updates state->n_wronly.
         nfs4_state_set_mode_locked() updates state->state
      
         state->flags is [RW]
         state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1
      
       * should have suppressed the preceding nfs4_close_prepare() from
         sending open_downgrade
      
      1964406 -> write call
      1964408 -> downgrade (to read) reply seqid=4 (close of #1 retry)
      
         nfs_clear_open_stateid_locked()
         state->flags is [R]
         state->state is [RW], state->n_wronly == 1, state->n_rdonly == 1
      
      1964409 -> write reply (fails, openmode)
      Signed-off-by: default avatarAndrew Elble <aweits@rit.edu>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d92f5225
    • Anton Protopopov's avatar
      cifs: fix erroneous return value · 69ef7d4f
      Anton Protopopov authored
      commit 4b550af5 upstream.
      
      The setup_ntlmv2_rsp() function may return positive value ENOMEM instead
      of -ENOMEM in case of kmalloc failure.
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      69ef7d4f
    • Vasily Averin's avatar
      cifs_dbg() outputs an uninitialized buffer in cifs_readdir() · ec6e80b8
      Vasily Averin authored
      commit 01b9b0b2 upstream.
      
      In some cases tmp_bug can be not filled in cifs_filldir and stay uninitialized,
      therefore its printk with "%s" modifier can leak content of kernelspace memory.
      If old content of this buffer does not contain '\0' access bejond end of
      allocated object can crash the host.
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ec6e80b8
    • Yong Li's avatar
      iio: dac: mcp4725: set iio name property in sysfs · d4cd077a
      Yong Li authored
      commit 97a249e9 upstream.
      
      Without this change, the name entity for mcp4725 is missing in
      /sys/bus/iio/devices/iio\:device*/name
      
      With this change, name is reported correctly
      Signed-off-by: default avatarYong Li <sdliyong@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d4cd077a
    • Lars-Peter Clausen's avatar
      iio: adis_buffer: Fix out-of-bounds memory access · 8506cf1d
      Lars-Peter Clausen authored
      commit d590faf9 upstream.
      
      The SPI tx and rx buffers are both supposed to be scan_bytes amount of
      bytes large and a common allocation is used to allocate both buffers. This
      puts the beginning of the tx buffer scan_bytes bytes after the rx buffer.
      The initialization of the tx buffer pointer is done adding scan_bytes to
      the beginning of the rx buffer, but since the rx buffer is of type __be16
      this will actually add two times as much and the tx buffer ends up pointing
      after the allocated buffer.
      
      Fix this by using scan_count, which is scan_bytes / 2, instead of
      scan_bytes when initializing the tx buffer pointer.
      
      Fixes: aacff892 ("staging:iio:adis: Preallocate transfer message")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8506cf1d
    • Dan Carpenter's avatar
      iio: fix some warning messages · 3a9194b1
      Dan Carpenter authored
      commit 231bfe53 upstream.
      
      WARN_ON() only takes a condition argument.  I have changed these to
      WARN() instead.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      3a9194b1
    • Lars-Peter Clausen's avatar
      iio: ad5064: Fix ad5629/ad5669 shift · c66e8114
      Lars-Peter Clausen authored
      commit 5dcbe97b upstream.
      
      The ad5629/ad5669 are the I2C variant of the ad5628/ad5668, which has a SPI
      interface. They are mostly identical with the exception that the shift
      factor is different. Currently the driver does not take care of this
      difference which leads to incorrect DAC output values.
      
      Fix this by introducing a custom channel spec for the ad5629/ad5669 with
      the correct shift factor.
      
      Fixes: commit 6a17a076 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c66e8114