1. 27 3月, 2006 2 次提交
  2. 26 3月, 2006 1 次提交
  3. 25 3月, 2006 2 次提交
  4. 24 3月, 2006 1 次提交
  5. 22 3月, 2006 1 次提交
  6. 19 3月, 2006 1 次提交
  7. 17 3月, 2006 1 次提交
    • K
      [PATCH] dm stripe: Fix bounds · 8ba32fde
      Kevin Corry 提交于
      The dm-stripe target currently does not enforce that the size of a stripe
      device be a multiple of the chunk-size.  Under certain conditions, this can
      lead to I/O requests going off the end of an underlying device.  This
      test-case shows one example.
      
      echo "0 100 linear /dev/hdb1 0" | dmsetup create linear0
      echo "0 100 linear /dev/hdb1 100" | dmsetup create linear1
      echo "0 200 striped 2 32 /dev/mapper/linear0 0 /dev/mapper/linear1 0" | \
         dmsetup create stripe0
      dd if=/dev/zero of=/dev/mapper/stripe0 bs=1k
      
      This will produce the output:
      dd: writing '/dev/mapper/stripe0': Input/output error
      97+0 records in
      96+0 records out
      
      And in the kernel log will be:
      attempt to access beyond end of device
      dm-0: rw=0, want=104, limit=100
      
      The patch will check that the table size is a multiple of the stripe
      chunk-size when the table is created, which will prevent the above striped
      device from being created.
      
      This should not affect tools like LVM or EVMS, since in all the cases I can
      think of, striped devices are always created with the sizes being a
      multiple of the chunk-size.
      
      The size of a stripe device must be a multiple of its chunk-size.
      
      (akpm: that typecast is quite gratuitous)
      Signed-off-by: NKevin Corry <kevcorry@us.ibm.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8ba32fde
  8. 10 3月, 2006 1 次提交
  9. 25 2月, 2006 2 次提交
  10. 04 2月, 2006 3 次提交
  11. 03 2月, 2006 5 次提交
  12. 02 2月, 2006 7 次提交
  13. 19 1月, 2006 1 次提交
    • A
      [PATCH] EDAC: atomic scrub operations · 715b49ef
      Alan Cox 提交于
      EDAC requires a way to scrub memory if an ECC error is found and the chipset
      does not do the work automatically.  That means rewriting memory locations
      atomically with respect to all CPUs _and_ bus masters.  That means we can't
      use atomic_add(foo, 0) as it gets optimised for non-SMP
      
      This adds a function to include/asm-foo/atomic.h for the platforms currently
      supported which implements a scrub of a mapped block.
      
      It also adjusts a few other files include order where atomic.h is included
      before types.h as this now causes an error as atomic_scrub uses u32.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      715b49ef
  14. 17 1月, 2006 1 次提交
  15. 15 1月, 2006 1 次提交
  16. 13 1月, 2006 1 次提交
  17. 11 1月, 2006 2 次提交
  18. 10 1月, 2006 1 次提交
  19. 09 1月, 2006 2 次提交
    • A
      [PATCH] remove gcc-2 checks · a1365647
      Andrew Morton 提交于
      Remove various things which were checking for gcc-1.x and gcc-2.x compilers.
      
      From: Adrian Bunk <bunk@stusta.de>
      
          Some documentation updates and removes some code paths for gcc < 3.2.
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a1365647
    • C
      [PATCH] Add block_device_operations.getgeo block device method · a885c8c4
      Christoph Hellwig 提交于
      HDIO_GETGEO is implemented in most block drivers, and all of them have to
      duplicate the code to copy the structure to userspace, as well as getting
      the start sector.  This patch moves that to common code [1] and adds a
      ->getgeo method to fill out the raw kernel hd_geometry structure.  For many
      drivers this means ->ioctl can go away now.
      
      [1] the s390 block drivers are odd in this respect.  xpram sets ->start
          to 4 always which seems more than odd, and the dasd driver shifts
          the start offset around, probably because of it's non-standard
          sector size.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Jens Axboe <axboe@suse.de>
      Cc: <mike.miller@hp.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Cc: Markus Lidel <Markus.Lidel@shadowconnect.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a885c8c4
  20. 07 1月, 2006 4 次提交