1. 13 10月, 2011 4 次提交
  2. 27 7月, 2011 3 次提交
  3. 20 7月, 2011 1 次提交
  4. 14 7月, 2011 1 次提交
  5. 09 7月, 2011 1 次提交
  6. 01 7月, 2011 3 次提交
  7. 30 6月, 2011 6 次提交
  8. 09 6月, 2011 1 次提交
  9. 02 6月, 2011 1 次提交
    • L
      block: fix mismerge of the DISK_EVENT_MEDIA_CHANGE removal · 0f48f260
      Linus Torvalds 提交于
      Jens' back-merge commit 698567f3 ("Merge commit 'v2.6.39' into
      for-2.6.40/core") was incorrectly done, and re-introduced the
      DISK_EVENT_MEDIA_CHANGE lines that had been removed earlier in commits
      
       - 9fd097b1 ("block: unexport DISK_EVENT_MEDIA_CHANGE for
         legacy/fringe drivers")
      
       - 7eec77a1 ("ide: unexport DISK_EVENT_MEDIA_CHANGE for ide-gd
         and ide-cd")
      
      because of conflicts with the "g->flags" updates near-by by commit
      d4dc210f ("block: don't block events on excl write for non-optical
      devices")
      
      As a result, we re-introduced the hanging behavior due to infinite disk
      media change reports.
      
      Tssk, tssk, people! Don't do back-merges at all, and *definitely* don't
      do them to hide merge conflicts from me - especially as I'm likely
      better at merging them than you are, since I do so many merges.
      Reported-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Jens Axboe <jaxboe@fusionio.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f48f260
  10. 01 6月, 2011 2 次提交
  11. 30 5月, 2011 2 次提交
  12. 29 5月, 2011 1 次提交
    • L
      x86 idle floppy: deprecate disable_hlt() · 3b70b2e5
      Len Brown 提交于
      Plan to remove floppy_disable_hlt in 2012, an ancient
      workaround with comments that it should be removed.
      
      This allows us to remove clutter and a run-time branch
      from the idle code.
      
      WARN_ONCE() on invocation until it is removed.
      
      cc: x86@kernel.org
      cc: stable@kernel.org # .39.x
      Signed-off-by: NLen Brown <len.brown@intel.com>
      3b70b2e5
  13. 28 5月, 2011 3 次提交
    • N
      nbd: adjust 'max_part' according to part_shift · 5988ce23
      Namhyung Kim 提交于
      The 'max_part' parameter determines how many partitions are supported
      on each nbd device. However the actual number can be changed to the
      power of 2 minus 1 form during the module initialization as
      alloc_disk() is called with (1 << part_shift) for some reason.
      
      So adjust 'max_part' also at least for consistency with loop and brd.
      It is exported via sysfs already, and a user should check this value
      after module loading if [s]he wants to use that number correctly
      (i.e. fdisk or something).
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: Paul Clements <Paul.Clements@steeleye.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      5988ce23
    • N
      nbd: limit module parameters to a sane value · 3b271082
      Namhyung Kim 提交于
      The 'max_part' parameter controls the number of maximum partition
      a nbd device can have. However if a user specifies very large
      value it would exceed the limitation of device minor number and
      can cause a kernel oops (or, at least, produce invalid device
      nodes in some cases).
      
      In addition, specifying large 'nbds_max' value causes same
      problem for the same reason.
      
      On my desktop, following command results to the kernel bug:
      
      $ sudo modprobe nbd max_part=100000
       kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
       invalid opcode: 0000 [#1] SMP
       last sysfs file: /sys/devices/virtual/block/nbd4/range
       CPU 1
       Modules linked in: nbd(+) bridge stp llc kvm_intel kvm asus_atk0110 sg sr_mod cdrom
      
       Pid: 2522, comm: modprobe Tainted: G        W   2.6.39-leonard+ #159 System manufacturer System Product Name/P5G41TD-M PRO
       RIP: 0010:[<ffffffff8115aa08>]  [<ffffffff8115aa08>] internal_create_group+0x2f/0x166
       RSP: 0018:ffff8801009f1de8  EFLAGS: 00010246
       RAX: 00000000ffffffef RBX: ffff880103920478 RCX: 00000000000a7bd3
       RDX: ffffffff81a2dbe0 RSI: 0000000000000000 RDI: ffff880103920478
       RBP: ffff8801009f1e38 R08: ffff880103920468 R09: ffff880103920478
       R10: ffff8801009f1de8 R11: ffff88011eccbb68 R12: ffffffff81a2dbe0
       R13: ffff880103920468 R14: 0000000000000000 R15: ffff880103920400
       FS:  00007f3c49de9700(0000) GS:ffff88011f800000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 00007f3b7fe7c000 CR3: 00000000cd58d000 CR4: 00000000000406e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Process modprobe (pid: 2522, threadinfo ffff8801009f0000, task ffff8801009a93a0)
       Stack:
        ffff8801009f1e58 ffffffff812e8f6e ffff8801009f1e58 ffffffff812e7a80
        ffff880000000010 ffff880103920400 ffff8801002fd0c0 ffff880103920468
        0000000000000011 ffff880103920400 ffff8801009f1e48 ffffffff8115ab6a
       Call Trace:
        [<ffffffff812e8f6e>] ? device_add+0x4f1/0x5e4
        [<ffffffff812e7a80>] ? dev_set_name+0x41/0x43
        [<ffffffff8115ab6a>] sysfs_create_group+0x13/0x15
        [<ffffffff810b857e>] blk_trace_init_sysfs+0x14/0x16
        [<ffffffff811ee58b>] blk_register_queue+0x4c/0xfd
        [<ffffffff811f3bdf>] add_disk+0xe4/0x29c
        [<ffffffffa007e2ab>] nbd_init+0x2ab/0x30d [nbd]
        [<ffffffffa007e000>] ? 0xffffffffa007dfff
        [<ffffffff8100020f>] do_one_initcall+0x7f/0x13e
        [<ffffffff8107ab0a>] sys_init_module+0xa1/0x1e3
        [<ffffffff814f3542>] system_call_fastpath+0x16/0x1b
       Code: 41 57 41 56 41 55 41 54 53 48 83 ec 28 0f 1f 44 00 00 48 89 fb 41 89 f6 49 89 d4 48 85 ff 74 0b 85 f6 75 0b 48 83
        7f 30 00 75 14 <0f> 0b eb fe b9 ea ff ff ff 48 83 7f 30 00 0f 84 09 01 00 00 49
       RIP  [<ffffffff8115aa08>] internal_create_group+0x2f/0x166
        RSP <ffff8801009f1de8>
       ---[ end trace 753285ffbf72c57c ]---
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: Paul Clements <Paul.Clements@steeleye.com>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      3b271082
    • N
      nbd: pass MSG_* flags to kernel_recvmsg() · 35fbf5bc
      Namhyung Kim 提交于
      Unlike kernel_sendmsg(), kernel_recvmsg() requires passing flags explicitly
      via last parameter instead of struct msghdr.msg_flags. Therefore calls to
      sock_xmit(lo, 0, ..., MSG_WAITALL) have not been processed properly by tcp
      layer wrt. the flag. Fix it.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Paul Clements <Paul.Clements@steeleye.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      35fbf5bc
  14. 27 5月, 2011 6 次提交
    • N
      loop: export module parameters · ac04fee0
      Namhyung Kim 提交于
      Export 'max_loop' and 'max_part' parameters to sysfs so user can know
      that how many devices are allowed and how many partitions are supported.
      
      If 'max_loop' is 0, there is no restriction on the number of loop devices.
      User can create/use the devices as many as minor numbers available. If
      'max_part' is 0, it means simply the device doesn't support partitioning.
      
      Also note that 'max_part' can be adjusted to power of 2 minus 1 form if
      needed. User should check this value after the module loading if he/she
      want to use that number correctly (i.e. fdisk, mknod, etc.).
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      ac04fee0
    • N
      brd: export module parameters · 8892cbaf
      Namhyung Kim 提交于
      Export 'rd_nr', 'rd_size' and 'max_part' parameters to sysfs so user can
      know that how many devices are allowed, how big each device is and how
      many partitions are supported. If 'max_part' is 0, it means simply the
      device doesn't support partitioning.
      
      Also note that 'max_part' can be adjusted to power of 2 minus 1 form if
      needed. User should check this value after the module loading if he/she
      want to use that number correctly (i.e. fdisk, mknod, etc.).
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      8892cbaf
    • N
      brd: fix comment on initial device creation · 13868b76
      Namhyung Kim 提交于
      If 'rd_nr' param was not specified, 16 (can be adjusted via
      CONFIG_BLK_DEV_RAM_COUNT) devices would be created by default
      but comment said 1. Fix it.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      13868b76
    • N
      brd: handle on-demand devices correctly · af465668
      Namhyung Kim 提交于
      When finding or allocating a ram disk device, brd_probe() did not take
      partition numbers into account so that it can result to a different
      device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4
      for simplicity) :
      
      $ sudo modprobe brd max_part=15
      $ ls -l /dev/ram*
      brw-rw---- 1 root disk 1,  0 2011-05-25 15:41 /dev/ram0
      brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
      brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
      brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
      $ sudo mknod /dev/ram4 b 1 64
      $ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256
      256+0 records in
      256+0 records out
      1048576 bytes (1.0 MB) copied, 0.00215578 s, 486 MB/s
      namhyung@leonhard:linux$ ls -l /dev/ram*
      brw-rw---- 1 root disk 1,    0 2011-05-25 15:41 /dev/ram0
      brw-rw---- 1 root disk 1,   16 2011-05-25 15:41 /dev/ram1
      brw-rw---- 1 root disk 1,   32 2011-05-25 15:41 /dev/ram2
      brw-rw---- 1 root disk 1,   48 2011-05-25 15:41 /dev/ram3
      brw-r--r-- 1 root root 1,   64 2011-05-25 15:45 /dev/ram4
      brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64
      
      After this patch, /dev/ram4 - instead of /dev/ram64 - was
      accessed correctly.
      
      In addition, 'range' passed to blk_register_region() should
      include all range of dev_t that RAMDISK_MAJOR can address.
      It does not need to be limited by partition numbers unless
      'rd_nr' param was specified.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      af465668
    • N
      brd: limit 'max_part' module param to DISK_MAX_PARTS · 315980c8
      Namhyung Kim 提交于
      The 'max_part' parameter controls the number of maximum partition
      a brd device can have. However if a user specifies very large
      value it would exceed the limitation of device minor number and
      can cause a kernel panic (or, at least, produce invalid device
      nodes in some cases).
      
      On my desktop system, following command kills the kernel. On qemu,
      it triggers similar oops but the kernel was alive:
      
      $ sudo modprobe brd max_part=100000
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
       IP: [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
       PGD 7af1067 PUD 7b19067 PMD 0
       Oops: 0000 [#1] SMP
       last sysfs file:
       CPU 0
       Modules linked in: brd(+)
      
       Pid: 44, comm: insmod Tainted: G        W   2.6.39-qemu+ #158 Bochs Bochs
       RIP: 0010:[<ffffffff81110a9a>]  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
       RSP: 0018:ffff880007b15d78  EFLAGS: 00000286
       RAX: ffff880007b05478 RBX: ffff880007a52760 RCX: ffff880007b15dc8
       RDX: ffff880007a4f900 RSI: ffff880007b15e48 RDI: ffff880007a52760
       RBP: ffff880007b15da8 R08: 0000000000000002 R09: 0000000000000000
       R10: ffff880007b15e48 R11: ffff880007b05478 R12: 0000000000000000
       R13: ffff880007b05478 R14: 0000000000400920 R15: 0000000000000063
       FS:  0000000002160880(0063) GS:ffff880007c00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000058 CR3: 0000000007b1c000 CR4: 00000000000006b0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
       Process insmod (pid: 44, threadinfo ffff880007b14000, task ffff880007acb980)
       Stack:
        ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe
        ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a
        0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000
       Call Trace:
        [<ffffffff81143c0a>] kobject_add_internal+0xdf/0x1a0
        [<ffffffff81143da1>] kobject_add_varg+0x41/0x50
        [<ffffffff81143e6b>] kobject_add+0x64/0x66
        [<ffffffff8113bbe7>] blk_register_queue+0x5f/0xb8
        [<ffffffff81140f72>] add_disk+0xdf/0x289
        [<ffffffffa00040df>] brd_init+0xdf/0x1aa [brd]
        [<ffffffffa0004000>] ? 0xffffffffa0003fff
        [<ffffffffa0004000>] ? 0xffffffffa0003fff
        [<ffffffff8100020a>] do_one_initcall+0x7a/0x12e
        [<ffffffff8108516c>] sys_init_module+0x9c/0x1dc
        [<ffffffff812ff4bb>] system_call_fastpath+0x16/0x1b
       Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30
        8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89
       RIP  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
        RSP <ffff880007b15d78>
       CR2: 0000000000000058
       ---[ end trace aebb1175ce1f6739 ]---
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      315980c8
    • N
      brd: get rid of unused members from struct brd_device · a2cba291
      Namhyung Kim 提交于
      brd_refcnt, brd_offset, brd_sizelimit and brd_blocksize in struct
      brd_device seem to be copied from struct loop_device but they're
      not used anywhere. Let get rid of them.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      a2cba291
  15. 25 5月, 2011 3 次提交
  16. 24 5月, 2011 2 次提交
    • N
      loop: handle on-demand devices correctly · a1c15c59
      Namhyung Kim 提交于
      When finding or allocating a loop device, loop_probe() did not take
      partition numbers into account so that it can result to a different
      device. Consider following example:
      
      $ sudo modprobe loop max_part=15
      $ ls -l /dev/loop*
      brw-rw---- 1 root disk 7,   0 2011-05-24 22:16 /dev/loop0
      brw-rw---- 1 root disk 7,  16 2011-05-24 22:16 /dev/loop1
      brw-rw---- 1 root disk 7,  32 2011-05-24 22:16 /dev/loop2
      brw-rw---- 1 root disk 7,  48 2011-05-24 22:16 /dev/loop3
      brw-rw---- 1 root disk 7,  64 2011-05-24 22:16 /dev/loop4
      brw-rw---- 1 root disk 7,  80 2011-05-24 22:16 /dev/loop5
      brw-rw---- 1 root disk 7,  96 2011-05-24 22:16 /dev/loop6
      brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
      $ sudo mknod /dev/loop8 b 7 128
      $ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img
      $ sudo losetup -a
      /dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img)
      $ ls -l /dev/loop*
      brw-rw---- 1 root disk 7,    0 2011-05-24 22:16 /dev/loop0
      brw-rw---- 1 root disk 7,   16 2011-05-24 22:16 /dev/loop1
      brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128
      brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1
      brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2
      brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3
      brw-rw---- 1 root disk 7,   32 2011-05-24 22:16 /dev/loop2
      brw-rw---- 1 root disk 7,   48 2011-05-24 22:16 /dev/loop3
      brw-rw---- 1 root disk 7,   64 2011-05-24 22:16 /dev/loop4
      brw-rw---- 1 root disk 7,   80 2011-05-24 22:16 /dev/loop5
      brw-rw---- 1 root disk 7,   96 2011-05-24 22:16 /dev/loop6
      brw-rw---- 1 root disk 7,  112 2011-05-24 22:16 /dev/loop7
      brw-r--r-- 1 root root 7,  128 2011-05-24 22:17 /dev/loop8
      
      After this patch, /dev/loop8 - instead of /dev/loop128 - was
      accessed correctly.
      
      In addition, 'range' passed to blk_register_region() should
      include all range of dev_t that LOOP_MAJOR can address. It does
      not need to be limited by partition numbers unless 'max_loop'
      param was specified.
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      a1c15c59
    • N
      loop: limit 'max_part' module param to DISK_MAX_PARTS · 78f4bb36
      Namhyung Kim 提交于
      The 'max_part' parameter controls the number of maximum partition
      a loop block device can have. However if a user specifies very
      large value it would exceed the limitation of device minor number
      and can cause a kernel panic (or, at least, produce invalid
      device nodes in some cases).
      
      On my desktop system, following command kills the kernel. On qemu,
      it triggers similar oops but the kernel was alive:
      
      $ sudo modprobe loop max_part0000
       ------------[ cut here ]------------
       kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
       invalid opcode: 0000 [#1] SMP
       last sysfs file:
       CPU 0
       Modules linked in: loop(+)
      
       Pid: 43, comm: insmod Tainted: G        W   2.6.39-qemu+ #155 Bochs Bochs
       RIP: 0010:[<ffffffff8113ce61>]  [<ffffffff8113ce61>] internal_create_group=
      +0x2a/0x170
       RSP: 0018:ffff880007b3fde8  EFLAGS: 00000246
       RAX: 00000000ffffffef RBX: ffff880007b3d878 RCX: 00000000000007b4
       RDX: ffffffff8152da50 RSI: 0000000000000000 RDI: ffff880007b3d878
       RBP: ffff880007b3fe38 R08: ffff880007b3fde8 R09: 0000000000000000
       R10: ffff88000783b4a8 R11: ffff880007b3d878 R12: ffffffff8152da50
       R13: ffff880007b3d868 R14: 0000000000000000 R15: ffff880007b3d800
       FS:  0000000002137880(0063) GS:ffff880007c00000(0000) knlGS:00000000000000=
      00
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000422680 CR3: 0000000007b50000 CR4: 00000000000006b0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
       Process insmod (pid: 43, threadinfo ffff880007b3e000, task ffff880007afb9c=
      0)
       Stack:
        ffff880007b3fe58 ffffffff811e66dd ffff880007b3fe58 ffffffff811e570b
        0000000000000010 ffff880007b3d800 ffff880007a7b390 ffff880007b3d868
        0000000000400920 ffff880007b3d800 ffff880007b3fe48 ffffffff8113cfc8
       Call Trace:
        [<ffffffff811e66dd>] ? device_add+0x4bc/0x5af
        [<ffffffff811e570b>] ? dev_set_name+0x3c/0x3e
        [<ffffffff8113cfc8>] sysfs_create_group+0xe/0x12
        [<ffffffff810b420e>] blk_trace_init_sysfs+0x14/0x16
        [<ffffffff8116a090>] blk_register_queue+0x47/0xf7
        [<ffffffff8116f527>] add_disk+0xdf/0x290
        [<ffffffffa00060eb>] loop_init+0xeb/0x1b8 [loop]
        [<ffffffffa0006000>] ? 0xffffffffa0005fff
        [<ffffffff8100020a>] do_one_initcall+0x7a/0x12e
        [<ffffffff81096804>] sys_init_module+0x9c/0x1e0
        [<ffffffff813329bb>] system_call_fastpath+0x16/0x1b
       Code: c3 55 48 89 e5 41 57 41 56 41 89 f6 41 55 41 54 49 89 d4 53 48 89 fb=
       48 83 ec 28 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe =
      48 83 7f 30 00 b9 ea ff ff ff 0f 84 18 01 00 00 49
       RIP  [<ffffffff8113ce61>] internal_create_group+0x2a/0x170
        RSP <ffff880007b3fde8>
       ---[ end trace a123eb592043acad ]---
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Cc: Laurent Vivier <Laurent.Vivier@bull.net>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      78f4bb36