1. 04 10月, 2017 1 次提交
  2. 09 9月, 2017 1 次提交
  3. 07 9月, 2017 9 次提交
  4. 11 8月, 2017 1 次提交
  5. 10 8月, 2017 1 次提交
  6. 11 7月, 2017 1 次提交
  7. 07 7月, 2017 1 次提交
  8. 13 6月, 2017 1 次提交
  9. 09 6月, 2017 1 次提交
  10. 04 5月, 2017 7 次提交
  11. 14 4月, 2017 2 次提交
  12. 09 4月, 2017 1 次提交
  13. 09 3月, 2017 1 次提交
  14. 25 2月, 2017 2 次提交
  15. 23 2月, 2017 1 次提交
  16. 03 2月, 2017 1 次提交
  17. 11 1月, 2017 2 次提交
  18. 08 12月, 2016 1 次提交
  19. 02 12月, 2016 1 次提交
  20. 01 12月, 2016 1 次提交
    • T
      zram: fix unbalanced idr management at hot removal · 529e71e1
      Takashi Iwai 提交于
      The zram hot removal code calls idr_remove() even when zram_remove()
      returns an error (typically -EBUSY).  This results in a leftover at the
      device release, eventually leading to a crash when the module is
      reloaded.
      
      As described in the bug report below, the following procedure would
      cause an Oops with zram:
      
       - provision three zram devices via modprobe zram num_devices=3
       - configure a size for each device
         + echo "1G" > /sys/block/$zram_name/disksize
       - mkfs and mount zram0 only
       - attempt to hot remove all three devices
         + echo 2 > /sys/class/zram-control/hot_remove
         + echo 1 > /sys/class/zram-control/hot_remove
         + echo 0 > /sys/class/zram-control/hot_remove
           - zram0 removal fails with EBUSY, as expected
       - unmount zram0
       - try zram0 hot remove again
         + echo 0 > /sys/class/zram-control/hot_remove
           - fails with ENODEV (unexpected)
       - unload zram kernel module
         + completes successfully
       - zram0 device node still exists
       - attempt to mount /dev/zram0
         + mount command is killed
         + following BUG is encountered
      
       BUG: unable to handle kernel paging request at ffffffffa0002ba0
       IP: get_disk+0x16/0x50
       Oops: 0000 [#1] SMP
       CPU: 0 PID: 252 Comm: mount Not tainted 4.9.0-rc6 #176
       Call Trace:
         exact_lock+0xc/0x20
         kobj_lookup+0xdc/0x160
         get_gendisk+0x2f/0x110
         __blkdev_get+0x10c/0x3c0
         blkdev_get+0x19d/0x2e0
         blkdev_open+0x56/0x70
         do_dentry_open.isra.19+0x1ff/0x310
         vfs_open+0x43/0x60
         path_openat+0x2c9/0xf30
         do_filp_open+0x79/0xd0
         do_sys_open+0x114/0x1e0
         SyS_open+0x19/0x20
         entry_SYSCALL_64_fastpath+0x13/0x94
      
      This patch adds the proper error check in hot_remove_store() not to call
      idr_remove() unconditionally.
      
      Fixes: 17ec4cd9 ("zram: don't call idr_remove() from zram_remove()")
      Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1010970
      Link: http://lkml.kernel.org/r/20161121132140.12683-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      Reviewed-by: NDavid Disseldorp <ddiss@suse.de>
      Reported-by: NDavid Disseldorp <ddiss@suse.de>
      Tested-by: NDavid Disseldorp <ddiss@suse.de>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: <stable@vger.kernel.org>    [4.4+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      529e71e1
  21. 08 8月, 2016 1 次提交
  22. 05 8月, 2016 1 次提交
  23. 27 7月, 2016 1 次提交
    • M
      zram: use __GFP_MOVABLE for memory allocation · 9bc482d3
      Minchan Kim 提交于
      Zsmalloc is ready for page migration so zram can use __GFP_MOVABLE from
      now on.
      
      I did test to see how it helps to make higher order pages.  Test
      scenario is as follows.
      
      KVM guest, 1G memory, ext4 formated zram block device,
      
        for i in `seq 1 8`;
        do
                dd if=/dev/vda1 of=mnt/test$i.txt bs=128M count=1 &
        done
      
        wait `pidof dd`
      
        for i in `seq 1 2 8`;
        do
                rm -rf mnt/test$i.txt
        done
        fstrim -v mnt
      
        echo "init"
        cat /proc/buddyinfo
      
        echo "compaction"
        echo 1 > /proc/sys/vm/compact_memory
        cat /proc/buddyinfo
      
      old:
      
        init
        Node 0, zone      DMA    208    120     51     41     11      0      0      0      0      0      0
        Node 0, zone    DMA32  16380  13777   9184   3805    789     54      3      0      0      0      0
        compaction
        Node 0, zone      DMA    132     82     40     39     16      2      1      0      0      0      0
        Node 0, zone    DMA32   5219   5526   4969   3455   1831    677    139     15      0      0      0
      
      new:
      
        init
        Node 0, zone      DMA    379    115     97     19      2      0      0      0      0      0      0
        Node 0, zone    DMA32  18891  16774  10862   3947    637     21      0      0      0      0      0
        compaction
        Node 0, zone      DMA    214     66     87     29     10      3      0      0      0      0      0
        Node 0, zone    DMA32   1612   3139   3154   2469   1745    990    384     94      7      0      0
      
      As you can see, compaction made so many high-order pages. Yay!
      
      Link: http://lkml.kernel.org/r/1464736881-24886-13-git-send-email-minchan@kernel.orgSigned-off-by: NMinchan Kim <minchan@kernel.org>
      Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9bc482d3