1. 05 Jan, 2015 7 commits
  2. 30 Dec, 2014 1 commit
  3. 19 Dec, 2014 1 commit
  4. 15 Dec, 2014 17 commits
  5. 10 Dec, 2014 14 commits
    • Christian König's avatar
      drm/radeon: sync all BOs involved in a CS v2 · ba7f6b63
      Christian König authored
      commit 86b27638 upstream.
      
      Not just the userspace relocs, otherwise we won't wait
      for a swapped out page tables to be swapped in again.
      
      v2: rebased on Alex current drm-fixes-3.18
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      [ luis: backported to 3.16: used Christian's backport to 3.17 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ba7f6b63
    • Vishnu Motghare's avatar
      i2c: cadence: Set the hardware time-out register to maximum value · 3847a42c
      Vishnu Motghare authored
      commit 681d15a0 upstream.
      
      Cadence I2C controller has bug wherein it generates invalid read transactions
      after timeout in master receiver mode. This driver does not use the HW
      timeout and this interrupt is disabled but the feature itself cannot be
      disabled. Hence, this patch writes the maximum value (0xFF) to this register.
      This is one of the workarounds to this bug and it will not avoid the issue
      completely but reduces the chances of error.
      Signed-off-by: default avatarVishnu Motghare <vishnum@xilinx.com>
      Signed-off-by: default avatarHarini Katakam <harinik@xilinx.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3847a42c
    • Grygorii Strashko's avatar
      i2c: davinci: generate STP always when NACK is received · 40196dd2
      Grygorii Strashko authored
      commit 9ea359f7 upstream.
      
      According to I2C specification the NACK should be handled as follows:
      "When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
      Acknowledge signal. The master can then generate either a STOP condition to
      abort the transfer, or a repeated START condition to start a new transfer."
      [I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]
      
      Currently the Davinci i2c driver interrupts the transfer on receipt of a
      NACK but fails to send a STOP in some situations and so makes the bus
      stuck until next I2C IP reset (idle/enable).
      
      For example, the issue will happen during SMBus read transfer which
      consists from two i2c messages write command/address and read data:
      
      S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
      <--- write -----------------------> <--- read --------------------->
      
      The I2C client device will send NACK if it can't recognize "Command Code"
      and it's expected from I2C master to generate STP in this case.
      But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
      not be generated.
      
      Hence, fix it by generating Stop condition (STP) always when NACK is received.
      
      This patch fixes Davinci I2C in the same way it was done for OMAP I2C
      commit cda2109a ("i2c: omap: query STP always when NACK is received").
      Reviewed-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reported-by: default avatarHein Tibosch <hein_tibosch@yahoo.es>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      40196dd2
    • Tejun Heo's avatar
      ahci: disable MSI on SAMSUNG 0xa800 SSD · 283cc0c2
      Tejun Heo authored
      commit 2b21ef0a upstream.
      
      Just like 0x1600 which got blacklisted by 66a7cbc3 ("ahci: disable
      MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes
      on NCQ commands if MSI is enabled.  Disable MSI.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarDominik Mierzejewski <dominik@greysector.net>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      283cc0c2
    • Paul Mackerras's avatar
      slab: fix nodeid bounds check for non-contiguous node IDs · fbbd7295
      Paul Mackerras authored
      commit 7c3fbbdd upstream.
      
      The bounds check for nodeid in ____cache_alloc_node gives false
      positives on machines where the node IDs are not contiguous, leading to
      a panic at boot time.  For example, on a POWER8 machine the node IDs are
      typically 0, 1, 16 and 17.  This means that num_online_nodes() returns
      4, so when ____cache_alloc_node is called with nodeid = 16 the VM_BUG_ON
      triggers, like this:
      
        kernel BUG at /home/paulus/kernel/kvm/mm/slab.c:3079!
        Call Trace:
          .____cache_alloc_node+0x5c/0x270 (unreliable)
          .kmem_cache_alloc_node_trace+0xdc/0x360
          .init_list+0x3c/0x128
          .kmem_cache_init+0x1dc/0x258
          .start_kernel+0x2a0/0x568
          start_here_common+0x20/0xa8
      
      To fix this, we instead compare the nodeid with MAX_NUMNODES, and
      additionally make sure it isn't negative (since nodeid is an int).  The
      check is there mainly to protect the array dereference in the get_node()
      call in the next line, and the array being dereferenced is of size
      MAX_NUMNODES.  If the nodeid is in range but invalid (for example if the
      node is off-line), the BUG_ON in the next line will catch that.
      
      Fixes: 14e50c6a ("mm: slab: Verify the nodeid passed to ____cache_alloc_node")
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Reviewed-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reviewed-by: default avatarPekka Enberg <penberg@kernel.org>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fbbd7295
    • Daniel Forrest's avatar
      mm: fix anon_vma_clone() error treatment · 7a26114b
      Daniel Forrest authored
      commit c4ea95d7 upstream.
      
      Andrew Morton noticed that the error return from anon_vma_clone() was
      being dropped and replaced with -ENOMEM (which is not itself a bug
      because the only error return value from anon_vma_clone() is -ENOMEM).
      
      I did an audit of callers of anon_vma_clone() and discovered an actual
      bug where the error return was being lost.  In __split_vma(), between
      Linux 3.11 and 3.12 the code was changed so the err variable is used
      before the call to anon_vma_clone() and the default initial value of
      -ENOMEM is overwritten.  So a failure of anon_vma_clone() will return
      success since err at this point is now zero.
      
      Below is a patch which fixes this bug and also propagates the error
      return value from anon_vma_clone() in all cases.
      
      Fixes: ef0855d3 ("mm: mempolicy: turn vma_set_policy() into vma_dup_policy()")
      Signed-off-by: default avatarDaniel Forrest <dan.forrest@ssec.wisc.edu>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Tim Hartrick <tim@edgecast.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7a26114b
    • Hugh Dickins's avatar
      mm: fix swapoff hang after page migration and fork · a3edfa39
      Hugh Dickins authored
      commit 2022b4d1 upstream.
      
      I've been seeing swapoff hangs in recent testing: it's cycling around
      trying unsuccessfully to find an mm for some remaining pages of swap.
      
      I have been exercising swap and page migration more heavily recently,
      and now notice a long-standing error in copy_one_pte(): it's trying to
      add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing
      so even when it's a migration entry or an hwpoison entry.
      
      Which wouldn't matter much, except it adds dst_mm next to src_mm,
      assuming src_mm is already on the mmlist: which may not be so.  Then if
      pages are later swapped out from dst_mm, swapoff won't be able to find
      where to replace them.
      
      There's already a !non_swap_entry() test for stats: move that up before
      the swap_duplicate() and the addition to mmlist.
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Kelley Nielsen <kelleynnn@gmail.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 avatarLuis Henriques <luis.henriques@canonical.com>
      a3edfa39
    • Andrew Morton's avatar
      drivers/input/evdev.c: don't kfree() a vmalloc address · 93ecb50a
      Andrew Morton authored
      commit 92788ac1 upstream.
      
      If kzalloc() failed and then evdev_open_device() fails, evdev_open()
      will pass a vmalloc'ed pointer to kfree.
      
      This might fix https://bugzilla.kernel.org/show_bug.cgi?id=88401, where
      there was a crash in kfree().
      Reported-by: default avatarChristian Casteyde <casteyde.christian@free.fr>
      Belatedly-Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Henrik Rydberg <rydberg@euromail.se>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      93ecb50a
    • Seth Forshee's avatar
      xen-netfront: Remove BUGs on paged skb data which crosses a page boundary · a10a000e
      Seth Forshee authored
      commit 8d609725 upstream.
      
      These BUGs can be erroneously triggered by frags which refer to
      tail pages within a compound page. The data in these pages may
      overrun the hardware page while still being contained within the
      compound page, but since compound_order() evaluates to 0 for tail
      pages the assertion fails. The code already iterates through
      subsequent pages correctly in this scenario, so the BUGs are
      unnecessary and can be removed.
      
      Fixes: f36c3747 ("xen/netfront: handle compound page fragments on transmit")
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a10a000e
    • Andrew Morton's avatar
      mm/vmpressure.c: fix race in vmpressure_work_fn() · 98d7f839
      Andrew Morton authored
      commit 91b57191 upstream.
      
      In some android devices, there will be a "divide by zero" exception.
      vmpr->scanned could be zero before spin_lock(&vmpr->sr_lock).
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=88051
      
      [akpm@linux-foundation.org: neaten]
      Reported-by: default avatarji_ang <ji_ang@163.com>
      Cc: Anton Vorontsov <anton.vorontsov@linaro.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 avatarLuis Henriques <luis.henriques@canonical.com>
      98d7f839
    • Weijie Yang's avatar
      mm: frontswap: invalidate expired data on a dup-store failure · c153b494
      Weijie Yang authored
      commit fb993fa1 upstream.
      
      If a frontswap dup-store failed, it should invalidate the expired page
      in the backend, or it could trigger some data corruption issue.
      Such as:
       1. use zswap as the frontswap backend with writeback feature
       2. store a swap page(version_1) to entry A, success
       3. dup-store a newer page(version_2) to the same entry A, fail
       4. use __swap_writepage() write version_2 page to swapfile, success
       5. zswap do shrink, writeback version_1 page to swapfile
       6. version_2 page is overwrited by version_1, data corrupt.
      
      This patch fixes this issue by invalidating expired data immediately
      when meet a dup-store failure.
      Signed-off-by: default avatarWeijie Yang <weijie.yang@samsung.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Seth Jennings <sjennings@variantweb.net>
      Cc: Dan Streetman <ddstreet@ieee.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Bob Liu <bob.liu@oracle.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 avatarLuis Henriques <luis.henriques@canonical.com>
      c153b494
    • Petr Mladek's avatar
      drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 · 5293a688
      Petr Mladek authored
      commit f5475cc4 upstream.
      
      I was unable too boot 3.18.0-rc6 because of the following kernel
      panic in drm_calc_vbltimestamp_from_scanoutpos():
      
          [drm] Initialized drm 1.1.0 20060810
          [drm] radeon kernel modesetting enabled.
          [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
          [drm] register mmio base: 0xC8400000
          [drm] register mmio size: 65536
          radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
          radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
          [drm] Detected VRAM RAM=128M, BAR=128M
          [drm] RAM width 16bits DDR
          [TTM] Zone  kernel: Available graphics memory: 3829346 kiB
          [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
          [TTM] Initializing pool allocator
          [TTM] Initializing DMA pool allocator
          [drm] radeon: 16M of VRAM memory ready
          [drm] radeon: 512M of GTT memory ready.
          [drm] GART: num cpu pages 131072, num gpu pages 131072
          [drm] PCI GART of 512M enabled (table at 0x0000000037880000).
          radeon 0000:0b:01.0: WB disabled
          radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
          [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
          [drm] Driver supports precise vblank timestamp query.
          [drm] radeon: irq initialized.
          [drm] Loading R100 Microcode
          radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
          radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
          [drm:r100_cp_init] *ERROR* Failed to load firmware!
          radeon 0000:0b:01.0: failed initializing CP (-2).
          radeon 0000:0b:01.0: Disabling GPU acceleration
          [drm] radeon: cp finalized
          BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
          IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
          PGD 0
          Oops: 0000 [#1] SMP
          Modules linked in:
          CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
          Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
          task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
          RIP: 0010:[<ffffffff8150423b>]  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
          RSP: 0000:ffff880234da7918  EFLAGS: 00010086
          RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
          RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
          RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
          R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
          R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
          FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
          CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
          Stack:
           ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
           ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
           ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
          Call Trace:
           [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
           [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
           [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
           [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
           [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
           [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
           [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
           [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
           [<ffffffff8156c07e>] r100_init+0x26e/0x410
           [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
           [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
           [<ffffffff81506965>] drm_dev_register+0xb5/0x110
           [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
           [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
           [<ffffffff8141a365>] local_pci_probe+0x45/0xa0
           [<ffffffff8141b741>] pci_device_probe+0xd1/0x130
           [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
           [<ffffffff8163413b>] __driver_attach+0x9b/0xa0
           [<ffffffff816340a0>] ? __device_attach+0x40/0x40
           [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
           [<ffffffff8163378e>] driver_attach+0x1e/0x20
           [<ffffffff81633390>] bus_add_driver+0x180/0x240
           [<ffffffff81634914>] driver_register+0x64/0xf0
           [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50
           [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120
           [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a
           [<ffffffff821dc908>] radeon_init+0x97/0xb5
           [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
           [<ffffffff810e3278>] ? __wake_up+0x48/0x60
           [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
           [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
           [<ffffffff818a78f0>] ? rest_init+0x80/0x80
           [<ffffffff818a78fe>] kernel_init+0xe/0xf0
           [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
           [<ffffffff818a78f0>] ? rest_init+0x80/0x80
          Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
          RIP  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
           RSP <ffff880234da7918>
          CR2: 000000000000025c
          ---[ end trace ad2c0aadf48e2032 ]---
          Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
      
      It has helped me to add a NULL pointer check that was suggested at
      http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html
      
      I am not familiar with the code. But the change looks sane
      and we need something fast at this stage of 3.18 development.
      Suggested-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.cz>
      Tested-by: default avatarPetr Mladek <pmladek@suse.cz>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5293a688
    • Dmitry Torokhov's avatar
      sata_fsl: fix error handling of irq_of_parse_and_map · 11cffaea
      Dmitry Torokhov authored
      commit aad0b624 upstream.
      
      irq_of_parse_and_map() returns 0 on error (the result is unsigned int),
      so testing for negative result never works.
      Signed-off-by: default avatarDmitry Torokhov <dtor@chromium.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      11cffaea
    • Devin Ryles's avatar
      AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller · 93a5d64e
      Devin Ryles authored
      commit 249cd0a1 upstream.
      
      This patch adds DeviceIDs for Sunrise Point-LP.
      Signed-off-by: default avatarDevin Ryles <devin.ryles@intel.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      93a5d64e