1. 12 12月, 2014 2 次提交
    • M
      fuse: flush requests on umount · 580640ba
      Miklos Szeredi 提交于
      Use fuse_abort_conn() instead of fuse_conn_kill() in fuse_put_super().
      This flushes and aborts requests still on any queues.  But since we've
      already reset fc->connected, those requests would not be useful anyway and
      would be flushed when the fuse device is closed.
      
      Next patches will rely on requests being flushed before the superblock is
      destroyed.
      
      Use fuse_abort_conn() in cuse_process_init_reply() too, since it makes no
      difference there, and we can get rid of fuse_conn_kill().
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      580640ba
    • M
      fuse: don't wake up reserved req in fuse_conn_kill() · 0c4dd4ba
      Miklos Szeredi 提交于
      Waking up reserved_req_waitq from fuse_conn_kill() doesn't make sense since
      we aren't chaging ff->reserved_req here, which is what this waitqueue
      signals.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      0c4dd4ba
  2. 08 12月, 2014 2 次提交
  3. 07 12月, 2014 2 次提交
  4. 06 12月, 2014 3 次提交
  5. 05 12月, 2014 8 次提交
  6. 04 12月, 2014 16 次提交
  7. 03 12月, 2014 7 次提交
    • H
    • S
      xen-netfront: Remove BUGs on paged skb data which crosses a page boundary · 8d609725
      Seth Forshee 提交于
      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")
      Cc: <stable@vger.kernel.org> # 3.7+
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d609725
    • A
      mm/vmpressure.c: fix race in vmpressure_work_fn() · 91b57191
      Andrew Morton 提交于
      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: Nji_ang <ji_ang@163.com>
      Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      91b57191
    • W
      mm: frontswap: invalidate expired data on a dup-store failure · fb993fa1
      Weijie Yang 提交于
      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: NWeijie 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>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fb993fa1
    • R
      mm: do not overwrite reserved pages counter at show_mem() · bc127bda
      Rafael Aquini 提交于
      Minor fixlet to perform the reserved pages counter aggregation for each
      node, at show_mem()
      Signed-off-by: NRafael Aquini <aquini@redhat.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Acked-by: NJohannes Weiner <jweiner@redhat.com>
      Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bc127bda
    • D
      Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 00d6a9b6
      Dave Airlie 提交于
      A few more small fixes for 3.18.
      
      * 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
        drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6
        drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86
        drm/radeon: sync all BOs involved in a CS v2
      00d6a9b6
    • P
      drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 · f5475cc4
      Petr Mladek 提交于
      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: NHelge Deller <deller@gmx.de>
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Tested-by: NPetr Mladek <pmladek@suse.cz>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f5475cc4