1. 09 Nov, 2009 4 commits
  2. 04 Jun, 2009 1 commit
  3. 24 Aug, 2009 1 commit
  4. 04 Jun, 2009 1 commit
  5. 28 Oct, 2009 7 commits
  6. 12 Nov, 2009 2 commits
  7. 13 Nov, 2009 1 commit
  8. 12 Nov, 2009 4 commits
    • Albin Tonnerre's avatar
      - changes to ach/arch/boot/Makefile to make it easier to add new · 88db364d
      Albin Tonnerre authored
         compression types
       - new piggy.lzo.S necessary for lzo compression
       - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
         gzip, depending on the config
       - Kconfig support
      Signed-off-by: default avatarAlbin Tonnerre <albin.tonnerre@free-electrons.com>
      Tested-by: default avatarWu Zhangjin <wuzhangjin@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      88db364d
    • Andrew Morton's avatar
      Cc: "H. Peter Anvin" <hpa@zytor.com> · fe29501b
      Andrew Morton authored
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wu Zhangjin <wuzhangjin@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      fe29501b
    • Andrew Morton's avatar
      ERROR: that open brace { should be on the previous line · 0aa09174
      Andrew Morton authored
      #184: FILE: lib/decompress_unlzo.c:48:
      +static const unsigned char lzop_magic[] =
      +	{ 0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a };
      
      WARNING: line over 80 characters
      #254: FILE: lib/decompress_unlzo.c:118:
      +		error("Both input pointer and fill function provided, don't know what to do");
      
      WARNING: line over 80 characters
      #259: FILE: lib/decompress_unlzo.c:123:
      +		error("NULL input pointer and missing position pointer or fill function");
      
      WARNING: line over 80 characters
      #313: FILE: lib/decompress_unlzo.c:177:
      +		r = lzo1x_decompress_safe((u8 *) in_buf, src_len, out_buf, &tmp);
      
      total: 1 errors, 3 warnings, 291 lines checked
      
      ./patches/lib-add-support-for-lzo-compressed-kernels.patch has style problems, please review.  If any of these errors
      are false positives report them to the maintainer, see
      CHECKPATCH in MAINTAINERS.
      
      Please run checkpatch prior to sending patches
      
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wu Zhangjin <wuzhangjin@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      0aa09174
    • Albin Tonnerre's avatar
      This patch series adds generic support for creating and extracting · b36196aa
      Albin Tonnerre authored
      LZO-compressed kernel images, as well as support for using such images on
      the x86 and ARM architectures, and support for creating and using
      LZO-compressed initrd and initramfs images.
      
      
      
      This patch:
      
      The lzo compressor is worse than gzip at compression, but faster at
      extraction.  Here are some figures for an ARM board I'm working on:
      
      Uncompressed size: 3.24Mo
      gzip  1.61Mo 0.72s
      lzo   1.75Mo 0.48s
      
      So for a compression ratio that is still relatively close to gzip, it's
      much faster to extract, at least in that case.
      
      This part contains:
       - Makefile routine to support lzo compression
       - Fixes to the existing lzo compressor so that it can be used in
         compressed kernels
       - wrapper around the existing lzo1x_decompress, as it only extracts one
         block at a time, while we need to extract a whole file here
       - config dialog for kernel compression
      Signed-off-by: default avatarAlbin Tonnerre <albin.tonnerre@free-electrons.com>
      Tested-by: default avatarWu Zhangjin <wuzhangjin@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      b36196aa
  9. 13 Nov, 2009 1 commit
    • Andrew Morton's avatar
      ERROR: code indent should use tabs where possible · 43321ea4
      Andrew Morton authored
      #90: FILE: lib/zlib_inflate/inffast.c:250:
      +                    /* minimum length is three */$
      
      ERROR: space prohibited before that close parenthesis ')'
      #97: FILE: lib/zlib_inflate/inffast.c:257:
      +		    if (dist > 2 ) {
      
      WARNING: suspect code indent for conditional statements (24, 28)
      #111: FILE: lib/zlib_inflate/inffast.c:271:
      +			if (dist == 1)
      [...]
      +			    pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8);
      
      ERROR: space prohibited before that close parenthesis ')'
      #113: FILE: lib/zlib_inflate/inffast.c:273:
      +			    pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8);
      
      ERROR: space prohibited before that close parenthesis ')'
      #115: FILE: lib/zlib_inflate/inffast.c:275:
      +			    pat16 = (pat16 & 0xff00) | ((pat16 & 0xff00 ) >> 8);
      
      total: 4 errors, 1 warnings, 93 lines checked
      
      ./patches/zlib-optimize-inffast-when-copying-direct-from-output.patch has style problems, please review.  If any of these errors
      are false positives report them to the maintainer, see
      CHECKPATCH in MAINTAINERS.
      
      Please run checkpatch prior to sending patches
      
      Cc: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      43321ea4
  10. 14 Nov, 2009 1 commit
  11. 13 Nov, 2009 1 commit
  12. 10 Oct, 2009 1 commit
  13. 12 Nov, 2009 1 commit
  14. 10 Nov, 2009 2 commits
    • Andrew Morton's avatar
      ERROR: space prohibited before that close parenthesis ')' · f1bf8841
      Andrew Morton authored
      #252: FILE: fs/direct-io.c:1212:
      +			if (end > isize )
      
      total: 1 errors, 0 warnings, 338 lines checked
      
      ./patches/direct-io-cleanup-blockdev_direct_io-locking.patch has style problems, please review.  If any of these errors
      are false positives report them to the maintainer, see
      CHECKPATCH in MAINTAINERS.
      
      Please run checkpatch prior to sending patches
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      f1bf8841
    • Christoph Hellwig's avatar
      Currently the locking in blockdev_direct_IO is a mess, we have three · 385fc1ba
      Christoph Hellwig authored
      different locking types and very confusing checks for some of them.  The
      most complicated one is DIO_OWN_LOCKING for reads, which happens to not
      actually be used.
      
      This patch gets rid of the DIO_OWN_LOCKING - as mentioned above the read
      case is unused anyway, and the write side is almost identical to
      DIO_NO_LOCKING.  The difference is that DIO_NO_LOCKING always sets the
      create argument for the get_blocks callback to zero, but we can easily
      move that to the actual get_blocks callbacks.  There are four users of the
      DIO_NO_LOCKING mode: gfs already ignores the create argument and thus is
      fine with the new version, ocfs2 only errors out if create were ever set,
      and we can remove this dead code now, the block device code only ever uses
      create for an error message if we are fully beyond the device which can
      never happen, and last but not least XFS will need the new behavour for
      writes.
      
      Now we can replace the lock_type variable with a flags one, where no flag
      means the DIO_NO_LOCKING behaviour and DIO_LOCKING is kept as the first
      flag.  Separate out the check for not allowing to fill holes into a
      separate flag, although for now both flags always get set at the same
      time.
      
      Also revamp the documentation of the locking scheme to actually make
      sense.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Zach Brown <zach.brown@oracle.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Alex Elder <aelder@sgi.com>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Joel Becker <joel.becker@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      385fc1ba
  15. 30 Oct, 2009 2 commits
    • Andrew Morton's avatar
      Cc: Jeff Moyer <jmoyer@redhat.com> · fec2996f
      Andrew Morton authored
      Cc: Zach Brown <zach.brown@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      fec2996f
    • Jeff Moyer's avatar
      Intel reported a performance regression caused by the following commit: · f3260275
      Jeff Moyer authored
      commit 848c4dd5
      Author: Zach Brown <zach.brown@oracle.com>
      Date:   Mon Aug 20 17:12:01 2007 -0700
      
          dio: zero struct dio with kzalloc instead of manually
      
          This patch uses kzalloc to zero all of struct dio rather than
          manually trying to track which fields we rely on being zero.  It
          passed aio+dio stress testing and some bug regression testing on
          ext3.
      
          This patch was introduced by Linus in the conversation that lead up
          to Badari's minimal fix to manually zero .map_bh.b_state in commit:
      
            6a648fa7
      
          It makes the code a bit smaller.  Maybe a couple fewer cachelines to
          load, if we're lucky:
      
             text    data     bss     dec     hex filename
          3285925  568506 1304616 5159047  4eb887 vmlinux
          3285797  568506 1304616 5158919  4eb807 vmlinux.patched
      
          I was unable to measure a stable difference in the number of cpu
          cycles spent in blockdev_direct_IO() when pushing aio+dio 256K reads
          at ~340MB/s.
      
          So the resulting intent of the patch isn't a performance gain but to
          avoid exposing ourselves to the risk of finding another field like
          .map_bh.b_state where we rely on zeroing but don't enforce it in the
          code.
      
      Zach surmised that zeroing out the page array was what caused most of
      the problem, and suggested the approach taken in the attached patch for
      resolving the issue.  Intel re-tested with this patch and saw a 0.6%
      performance gain (the original regression was 0.5%).
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Acked-by: default avatarZach Brown <zach.brown@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      f3260275
  16. 13 Nov, 2009 2 commits
  17. 14 Oct, 2009 1 commit
  18. 09 Nov, 2009 1 commit
  19. 30 Sep, 2009 3 commits
  20. 13 Nov, 2009 2 commits
    • Karel Zak's avatar
      The size of EFI GPT header is not static, but whole sector is · c9f1dfbe
      Karel Zak authored
      allocated for the header. The HeaderSize field must be greater
      than 92 (= sizeof(struct gpt_header) and must be less than or
      equal to the logical block size.
      
      It means we have to read whole sector with the header, because the
      header crc32 checksum is calculated according to HeaderSize.
      
      For more details see UEFI standard (version 2.3, May 2009):
        - 5.3.1 GUID Format overview, page 93
        - Table 13. GUID Partition Table Header, page 96
      Signed-off-by: default avatarKarel Zak <kzak@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      c9f1dfbe
    • Karel Zak's avatar
      Currently, kernel uses strictly 512-byte sectors for EFI GPT parsing. · 9ec8011b
      Karel Zak authored
      That's wrong.
      
      UEFI standard (version 2.3, May 2009, 5.3.1 GUID Format overview, page
      95) defines that LBA is always based on the logical block size. It
      means bdev_logical_block_size() (aka BLKSSZGET) for Linux.
      
      This patch removes static sector size from EFI GPT parser.
      
      The problem is reproducible with the latest GNU Parted:
      
       # modprobe scsi_debug dev_size_mb=50 sector_size=4096
      
        # ./parted /dev/sdb print
        Model: Linux scsi_debug (scsi)
        Disk /dev/sdb: 52.4MB
        Sector size (logical/physical): 4096B/4096B
        Partition Table: gpt
      
        Number  Start   End     Size    File system  Name     Flags
         1      24.6kB  3002kB  2978kB               primary
         2      3002kB  6001kB  2998kB               primary
         3      6001kB  9003kB  3002kB               primary
      
        # blockdev --rereadpt /dev/sdb
        # dmesg | tail -1
         sdb: unknown partition table      <---- !!!
      
      with this patch:
      
        # blockdev --rereadpt /dev/sdb
        # dmesg | tail -1
         sdb: sdb1 sdb2 sdb3
      Signed-off-by: default avatarKarel Zak <kzak@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      9ec8011b
  21. 12 Nov, 2009 1 commit