1. 03 10月, 2006 19 次提交
  2. 01 10月, 2006 2 次提交
    • D
      [PATCH] BLOCK: Make it possible to disable the block layer [try #6] · 9361401e
      David Howells 提交于
      Make it possible to disable the block layer.  Not all embedded devices require
      it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
      the block layer to be present.
      
      This patch does the following:
      
       (*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
           support.
      
       (*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
           an item that uses the block layer.  This includes:
      
           (*) Block I/O tracing.
      
           (*) Disk partition code.
      
           (*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
      
           (*) The SCSI layer.  As far as I can tell, even SCSI chardevs use the
           	 block layer to do scheduling.  Some drivers that use SCSI facilities -
           	 such as USB storage - end up disabled indirectly from this.
      
           (*) Various block-based device drivers, such as IDE and the old CDROM
           	 drivers.
      
           (*) MTD blockdev handling and FTL.
      
           (*) JFFS - which uses set_bdev_super(), something it could avoid doing by
           	 taking a leaf out of JFFS2's book.
      
       (*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
           linux/elevator.h contingent on CONFIG_BLOCK being set.  sector_div() is,
           however, still used in places, and so is still available.
      
       (*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
           parts of linux/fs.h.
      
       (*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
      
       (*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
      
       (*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
           is not enabled.
      
       (*) fs/no-block.c is created to hold out-of-line stubs and things that are
           required when CONFIG_BLOCK is not set:
      
           (*) Default blockdev file operations (to give error ENODEV on opening).
      
       (*) Makes some /proc changes:
      
           (*) /proc/devices does not list any blockdevs.
      
           (*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
      
       (*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
      
       (*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
           given command other than Q_SYNC or if a special device is specified.
      
       (*) In init/do_mounts.c, no reference is made to the blockdev routines if
           CONFIG_BLOCK is not defined.  This does not prohibit NFS roots or JFFS2.
      
       (*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
           error ENOSYS by way of cond_syscall if so).
      
       (*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
           CONFIG_BLOCK is not set, since they can't then happen.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      9361401e
    • J
      [PATCH] Split struct request ->flags into two parts · 4aff5e23
      Jens Axboe 提交于
      Right now ->flags is a bit of a mess: some are request types, and
      others are just modifiers. Clean this up by splitting it into
      ->cmd_type and ->cmd_flags. This allows introduction of generic
      Linux block message types, useful for sending generic Linux commands
      to block devices.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      4aff5e23
  3. 21 9月, 2006 3 次提交
  4. 02 9月, 2006 1 次提交
  5. 28 8月, 2006 3 次提交
    • N
      [PATCH] md: fix recent breakage of md/raid1 array checking · 6394cca5
      NeilBrown 提交于
      A recent patch broke the ability to do a user-request check of a raid1.
      This patch fixes the breakage and also moves a comment that was dislocated
      by the same patch.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6394cca5
    • N
      [PATCH] md: avoid backward event updates in md superblock when degraded. · 84692195
      NeilBrown 提交于
      If we
        - shut down a clean array,
        - restart with one (or more) drive(s) missing
        - make some changes
        - pause, so that they array gets marked 'clean',
      the event count on the superblock of included drives
      will be the same as that of the removed drives.
      So adding the removed drive back in will cause it
      to be included with no resync.
      
      To avoid this, we only update the eventcount backwards when the array
      is not degraded.  In this case there can (should) be no non-connected
      drives that we can get confused with, and this is the particular case
      where updating-backwards is valuable.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      84692195
    • D
      [PATCH] dm: Fix deadlock under high i/o load in raid1 setup. · c06aad85
      Daniel Kobras 提交于
      On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid,
      we experienced frequent deadlock of the system under high i/o load.  'cat
      /dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly
      after a few GB, 'cp' would be left in 'D' state along with kjournald and
      kmirrord.  The functions cp and kjournald were blocked in did vary, but
      kmirrord's wchan always pointed to 'mempool_alloc()'.  We've seen this pattern
      on 2.6.15 and 2.6.17 kernels.  http://lkml.org/lkml/2005/4/20/142 indicates
      that this problem has been around even before.
      
      So much for the facts, here's my interpretation: mempool_alloc() first tries
      to atomically allocate the requested memory, or falls back to hand out
      preallocated chunks from the mempool.  If both fail, it puts the calling
      process (kmirrord in this case) on a private waitqueue until somebody refills
      the pool.  Where the only 'somebody' is kmirrord itself, so we have a
      deadlock.
      
      I worked around this problem by falling back to a (blocking) kmalloc when
      before kmirrord would have ended up on the waitqueue.  This defeats part of
      the benefits of using the mempool, but at least keeps the system running.  And
      it could be done with a two-line change.  Note that mempool_alloc() clears the
      GFP_NOIO flag internally, and only uses it to decide whether to wait or return
      an error if immediate allocation fails, so the attached patch doesn't change
      behaviour in the non-deadlocking case.  Path is against current git
      (2.6.18-rc4), but should apply to earlier versions as well.  I've tested on
      2.6.15, where this patch makes the difference between random lockup and a
      stable system.
      Signed-off-by: NDaniel Kobras <kobras@linux.de>
      Acked-by: NAlasdair G Kergon <agk@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c06aad85
  6. 15 8月, 2006 1 次提交
    • M
      [PATCH] dm: BUG/OOPS fix · 485311a2
      Michal Miroslaw 提交于
      Fix BUG I tripped on while testing failover and multipathing.
      
      BUG shows up on error path in multipath_ctr() when parse_priority_group()
      fails after returning at least once without error.  The fix is to
      initialize m->ti early - just after alloc()ing it.
      
      BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
       printing eip:
      c027c3d2
      *pde = 00000000
      Oops: 0000 [#3]
      Modules linked in: qla2xxx ext3 jbd mbcache sg ide_cd cdrom floppy
      CPU:    0
      EIP:    0060:[<c027c3d2>]    Not tainted VLI
      EFLAGS: 00010202   (2.6.17.3 #1)
      EIP is at dm_put_device+0xf/0x3b
      eax: 00000001   ebx: ee4fcac0   ecx: 00000000   edx: ee4fcac0
      esi: ee4fc4e0   edi: ee4fc4e0   ebp: 00000000   esp: c5db3e78
      ds: 007b   es: 007b   ss: 0068
      Process multipathd (pid: 15912, threadinfo=c5db2000 task=ef485a90)
      Stack: ec4eda40 c02816bd ee4fc4c0 00000000 f7e89498 f883e0bc c02816f6 f7e89480
             f7e8948c c0281801 ffffffea f7e89480 f883e080 c0281ffe 00000001 00000000
             00000004 dfe9cab8 f7a693c0 f883e080 f883e0c0 ca4b99c0 c027c6ee 01400000
      Call Trace:
       <c02816bd> free_pgpaths+0x31/0x45  <c02816f6> free_priority_group+0x25/0x2e
       <c0281801> free_multipath+0x35/0x67  <c0281ffe> multipath_ctr+0x123/0x12d
       <c027c6ee> dm_table_add_target+0x11e/0x18b  <c027e5b4> populate_table+0x8a/0xaf
       <c027e62b> table_load+0x52/0xf9  <c027ec23> ctl_ioctl+0xca/0xfc
       <c027e5d9> table_load+0x0/0xf9  <c0152146> do_ioctl+0x3e/0x43
       <c0152360> vfs_ioctl+0x16c/0x178  <c01523b4> sys_ioctl+0x48/0x60
       <c01029b3> syscall_call+0x7/0xb
      Code: 97 f0 00 00 00 89 c1 83 c9 01 80 e2 01 0f 44 c1 88 43 14 8b 04 24 59 5b 5e 5f 5d c3 53 89 c1 89 d3 ff 4a 08 0f 94 c0 84 c0 74 2a <8b> 01 8b 10 89 d8 e8 f6 fb ff ff 8b 03 8b 53 04 89 50 04 89 02
      EIP: [<c027c3d2>] dm_put_device+0xf/0x3b SS:ESP 0068:c5db3e78
      Signed-off-by: NMichal Miroslaw <mirq-linux@rere.qmqm.pl>
      Acked-by: NAlasdair G Kergon <agk@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      485311a2
  7. 06 8月, 2006 1 次提交
  8. 11 7月, 2006 10 次提交