1. 28 2月, 2009 7 次提交
  2. 27 2月, 2009 20 次提交
  3. 26 2月, 2009 13 次提交
    • J
      xen/blkfront: use blk_rq_map_sg to generate ring entries · 9e973e64
      Jens Axboe 提交于
      On occasion, the request will apparently have more segments than we
      fit into the ring. Jens says:
      
      > The second problem is that the block layer then appears to create one
      > too many segments, but from the dump it has rq->nr_phys_segments ==
      > BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to
      > xen-blkfront not handling the merging on its own. It should check that
      > the new page doesn't form part of the previous page. The
      > rq_for_each_segment() iterates all single bits in the request, not dma
      > segments. The "easiest" way to do this is to call blk_rq_map_sg() and
      > then iterate the mapped sg list. That will give you what you are
      > looking for.
      
      > Here's a test patch, compiles but otherwise untested. I spent more
      > time figuring out how to enable XEN than to code it up, so YMMV!
      > Probably the sg list wants to be put inside the ring and only
      > initialized on allocation, then you can get rid of the sg on stack and
      > sg_init_table() loop call in the function. I'll leave that, and the
      > testing, to you.
      
      [Moved sg array into info structure, and initialize once. -J]
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      9e973e64
    • J
      block: reduce stack footprint of blk_recount_segments() · 1e428079
      Jens Axboe 提交于
      blk_recalc_rq_segments() requires a request structure passed in, which
      we don't have from blk_recount_segments(). So the latter allocates one on
      the stack, using > 400 bytes of stack for that. This can cause us to spill
      over one page of stack from ext4 at least:
      
       0)     4560     400   blk_recount_segments+0x43/0x62
       1)     4160      32   bio_phys_segments+0x1c/0x24
       2)     4128      32   blk_rq_bio_prep+0x2a/0xf9
       3)     4096      32   init_request_from_bio+0xf9/0xfe
       4)     4064     112   __make_request+0x33c/0x3f6
       5)     3952     144   generic_make_request+0x2d1/0x321
       6)     3808      64   submit_bio+0xb9/0xc3
       7)     3744      48   submit_bh+0xea/0x10e
       8)     3696     368   ext4_mb_init_cache+0x257/0xa6a [ext4]
       9)     3328     288   ext4_mb_regular_allocator+0x421/0xcd9 [ext4]
      10)     3040     160   ext4_mb_new_blocks+0x211/0x4b4 [ext4]
      11)     2880     336   ext4_ext_get_blocks+0xb61/0xd45 [ext4]
      12)     2544      96   ext4_get_blocks_wrap+0xf2/0x200 [ext4]
      13)     2448      80   ext4_da_get_block_write+0x6e/0x16b [ext4]
      14)     2368     352   mpage_da_map_blocks+0x7e/0x4b3 [ext4]
      15)     2016     352   ext4_da_writepages+0x2ce/0x43c [ext4]
      16)     1664      32   do_writepages+0x2d/0x3c
      17)     1632     144   __writeback_single_inode+0x162/0x2cd
      18)     1488      96   generic_sync_sb_inodes+0x1e3/0x32b
      19)     1392      16   sync_sb_inodes+0xe/0x10
      20)     1376      48   writeback_inodes+0x69/0xb3
      21)     1328     208   balance_dirty_pages_ratelimited_nr+0x187/0x2f9
      22)     1120     224   generic_file_buffered_write+0x1d4/0x2c4
      23)      896     176   __generic_file_aio_write_nolock+0x35f/0x393
      24)      720      80   generic_file_aio_write+0x6c/0xc8
      25)      640      80   ext4_file_write+0xa9/0x137 [ext4]
      26)      560     320   do_sync_write+0xf0/0x137
      27)      240      48   vfs_write+0xb3/0x13c
      28)      192      64   sys_write+0x4c/0x74
      29)      128     128   system_call_fastpath+0x16/0x1b
      
      Split the segment counting out into a __blk_recalc_rq_segments() helper
      to avoid allocating an onstack request just for checking the physical
      segment count.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      1e428079
    • J
      cciss: shorten 30s timeout on controller reset · 5e4c91c8
      Jens Axboe 提交于
      If reset_devices is set for kexec, then cciss will delay 30 seconds
      since the old 5i controller _may_ need that long to recover. Replace
      the long sleep with incremental sleep and tests to reduce the 30 seconds
      to worst case for 5i, so that other controllers will proceed quickly.
      Reviewed-by: NMike Miller <mike.miller@hp.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      5e4c91c8
    • M
      block: add documentation for register_blkdev() · 9e8c0bcc
      Márton Németh 提交于
      Add documentation for register_blkdev() function and for the parameters.
      Signed-off-by: NMárton Németh <nm127@freemail.hu>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      9e8c0bcc
    • J
      block: fix bogus gcc warning for uninitialized var usage · b2bf9683
      Jens Axboe 提交于
      Newer gcc throw this warning:
      
              fs/bio.c: In function ?bio_alloc_bioset?:
              fs/bio.c:305: warning: ?p? may be used uninitialized in this function
      
      since it cannot figure out that 'p' is only ever used if 'bs' is non-NULL.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      b2bf9683
    • M
      powerpc: Fix 64bit __copy_tofrom_user() regression · f72b728b
      Mark Nelson 提交于
      This fixes a regression introduced by commit
      a4e22f02 ("powerpc: Update 64bit
      __copy_tofrom_user() using CPU_FTR_UNALIGNED_LD_STD").
      
      The same bug that existed in the 64bit memcpy() also exists here so fix
      it here too. The fix is the same as that applied to memcpy() with the
      addition of fixes for the exception handling code required for
      __copy_tofrom_user().
      
      This stops us reading beyond the end of the source region we were told
      to copy.
      Signed-off-by: NMark Nelson <markn@au1.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f72b728b
    • M
      powerpc: Fix 64bit memcpy() regression · e423b9ec
      Mark Nelson 提交于
      This fixes a regression introduced by commit
      25d6e2d7 ("powerpc: Update 64bit memcpy()
      using CPU_FTR_UNALIGNED_LD_STD").
      
      This commit allowed CPUs that have the CPU_FTR_UNALIGNED_LD_STD CPU
      feature bit present to do the memcpy() with unaligned load doubles. But,
      along with this came a bug where our final load double would read bytes
      beyond a page boundary and into the next (unmapped) page. This was caught
      by enabling CONFIG_DEBUG_PAGEALLOC,
      
      The fix was to read only the number of bytes that we need to store rather
      than reading a full 8-byte doubleword and storing only a portion of that.
      
      In order to minimise the amount of existing code touched we use the
      original do_tail for the src_unaligned case.
      
      Below is an example of the regression, as reported by Sachin Sant:
      
      Unable to handle kernel paging request for data at address 0xc00000003f380000
      Faulting instruction address: 0xc000000000039574
      cpu 0x1: Vector: 300 (Data Access) at [c00000003baf3020]
          pc: c000000000039574: .memcpy+0x74/0x244
          lr: d00000000244916c: .ext3_xattr_get+0x288/0x2f4 [ext3]
          sp: c00000003baf32a0
         msr: 8000000000009032
         dar: c00000003f380000
       dsisr: 40000000
        current = 0xc00000003e54b010
        paca    = 0xc000000000a53680
          pid   = 1840, comm = readahead
      enter ? for help
      [link register   ] d00000000244916c .ext3_xattr_get+0x288/0x2f4 [ext3]
      [c00000003baf32a0] d000000002449104 .ext3_xattr_get+0x220/0x2f4 [ext3]
      (unreliab
      le)
      [c00000003baf3390] d00000000244a6e8 .ext3_xattr_security_get+0x40/0x5c [ext3]
      [c00000003baf3400] c000000000148154 .generic_getxattr+0x74/0x9c
      [c00000003baf34a0] c000000000333400 .inode_doinit_with_dentry+0x1c4/0x678
      [c00000003baf3560] c00000000032c6b0 .security_d_instantiate+0x50/0x68
      [c00000003baf35e0] c00000000013c818 .d_instantiate+0x78/0x9c
      [c00000003baf3680] c00000000013ced0 .d_splice_alias+0xf0/0x120
      [c00000003baf3720] d00000000243e05c .ext3_lookup+0xec/0x134 [ext3]
      [c00000003baf37c0] c000000000131e74 .do_lookup+0x110/0x260
      [c00000003baf3880] c000000000134ed0 .__link_path_walk+0xa98/0x1010
      [c00000003baf3970] c0000000001354a0 .path_walk+0x58/0xc4
      [c00000003baf3a20] c000000000135720 .do_path_lookup+0x138/0x1e4
      [c00000003baf3ad0] c00000000013645c .path_lookup_open+0x6c/0xc8
      [c00000003baf3b70] c000000000136780 .do_filp_open+0xcc/0x874
      [c00000003baf3d10] c0000000001251e0 .do_sys_open+0x80/0x140
      [c00000003baf3dc0] c00000000016aaec .compat_sys_open+0x24/0x38
      [c00000003baf3e30] c00000000000855c syscall_exit+0x0/0x40
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e423b9ec
    • M
      powerpc: Fix load/store float double alignment handler · 49f297f8
      Michael Neuling 提交于
      When we introduced VSX, we changed the way FPRs are stored in the
      thread_struct.  Unfortunately we missed the load/store float double
      alignment handler code when updating how we access FPRs in the
      thread_struct.
      
      Below fixes this and merges the little/big endian case.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      49f297f8
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 · 169d418b
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
        ALSA: emu10k1 - Fix digital/analog switch on audigy2 ZS
        ALSA: hda - Quirk for Acer Aspire 6530G
        ALSA: hda - add another MacBook Pro 3,1 SSID
        ALSA: fix excessive background noise introduced by OSS emulation rate shrink
        ALSA: aw2: do not grab every saa7146 based device
        ALSA: hda - Fix parse of init_verbs sysfs entry
        ALSA: pcxhr.h replace signed one-bit bitfields
      169d418b
    • L
      Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 · 70c01f01
      Linus Torvalds 提交于
      * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
        [IA64] Don't go beyond iosapic_intr_info's arraysize
        [IA64] Do not go beyond ARRAY_SIZE of unw.hash
        [IA64] enable setting DMAR on by default
      70c01f01
    • L
      Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · c4eb1bf6
      Linus Torvalds 提交于
      * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        [libata] pata_legacy: for VLB 32bit PIO don't try tricks with slop
        [libata] pata_amd: program FIFO
        sata_mv: fix SoC interrupt breakage
        pata_it821x: resume from hibernation fails with RAID volume
      c4eb1bf6
    • A
      [libata] pata_legacy: for VLB 32bit PIO don't try tricks with slop · c55af1f5
      Alan Cox 提交于
      These devices are generally used with ATA anyway and it seems that some
      ATAPI will need us to issue the right number of words.  Therefore as we
      can't switch mid burst on VLB devices we should only use 32bit I/O for
      suitable block sizes.
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      c55af1f5
    • A
      [libata] pata_amd: program FIFO · c48052cc
      Alan Cox 提交于
      With 32bit PIO we can use the posted write buffers, but only for 32bit I/O
      cycles.  This means we must disable the FIFO for ATAPI where a final 16bit
      cycle may occur.
      
      Rework the FIFO logic so that we disable the FIFO then selectively
      re-enable it when we set the timings on AMD devices.  Also fix a case
      where we scribbled on PCI config 0x41 of Nvidia chips when we shouldn't.
      Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      c48052cc