1. 21 2月, 2014 3 次提交
    • E
      ext4: silence warnings in extent status tree debugging code · ce140cdd
      Eric Whitney 提交于
      Adjust the conversion specifications in a few optionally compiled debug
      messages to match the return type of ext4_es_status().  Also, make a
      couple of minor grammatical message edits while we're at it.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      ce140cdd
    • E
      ext4: remove unused ac_ex_scanned · dc9ddd98
      Eric Sandeen 提交于
      When looking at a bug report with:
      
      > kernel: EXT4-fs: 0 scanned, 0 found
      
      I thought wow, 0 scanned, that's odd?  But it's not odd; it's printing
      a variable that is initialized to 0 and never touched again.
      
      It's never been used since the original merge, so I don't really even
      know what the original intent was, either.
      
      If anyone knows how to hook it up, speak now via patch, otherwise just
      yank it so it's not making a confusing situation more confusing in
      kernel logs.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      dc9ddd98
    • T
      ext4: avoid possible overflow in ext4_map_blocks() · e861b5e9
      Theodore Ts'o 提交于
      The ext4_map_blocks() function returns the number of blocks which
      satisfying the caller's request.  This number of blocks requested by
      the caller is specified by an unsigned integer, but the return value
      of ext4_map_blocks() is a signed integer (to accomodate error codes
      per the kernel's standard error signalling convention).
      
      Historically, overflows could never happen since mballoc() will refuse
      to allocate more than 2048 blocks at a time (which is something we
      should fix), and if the blocks were already allocated, the fact that
      there would be some number of intervening metadata blocks pretty much
      guaranteed that there could never be a contiguous region of data
      blocks that was greater than 2**31 blocks.
      
      However, this is now possible if there is a file system which is a bit
      bigger than 8TB, and is created using the new mke2fs hugeblock
      feature, which can create a perfectly contiguous file.  In that case,
      if a userspace program attempted to call fallocate() on this already
      fully allocated file, it's possible that ext4_map_blocks() could
      return a number large enough that it would overflow a signed integer,
      resulting in a ext4 thinking that the ext4_map_blocks() call had
      failed with some strange error code.
      
      Since ext4_map_blocks() is always free to return a smaller number of
      blocks than what was requested by the caller, fix this by capping the
      number of blocks that ext4_map_blocks() will ever try to map to 2**31
      - 1.  In practice this should never get hit, except by someone
      deliberately trying to provke the above-described bug.
      
      Thanks to the PaX team for asking whethre this could possibly happen
      in some off-line discussions about using some static code checking
      technology they are developing to find bugs in kernel code.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      e861b5e9
  2. 20 2月, 2014 4 次提交
    • T
      ext4: make sure ex.fe_logical is initialized · ab0c00fc
      Theodore Ts'o 提交于
      The lowest levels of mballoc set all of the fields of struct
      ext4_free_extent except for fe_logical, since they are just trying to
      find the requested free set of blocks, and the logical block hasn't
      been set yet.  This makes some static code checkers sad.  Set it to
      various different debug values, which would be useful when
      debugging mballoc if these values were to ever show up due to the
      parts of mballoc triyng to use ac->ac_b_ex.fe_logical before it is
      properly upper layers of mballoc failing to properly set, usually by
      ext4_mb_use_best_found().
      
      Addresses-Coverity-Id: #139697
      Addresses-Coverity-Id: #139698
      Addresses-Coverity-Id: #139699
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      
      ab0c00fc
    • T
      ext4: don't calculate total xattr header size unless needed · 7b1b2c1b
      Theodore Ts'o 提交于
      The function ext4_expand_extra_isize_ea() doesn't need the size of all
      of the extended attribute headers.  So if we don't calculate it when
      it is unneeded, it we can skip some undeeded memory references, and as
      a bonus, we eliminate some kvetching by static code analysis tools.
      
      Addresses-Coverity-Id: #741291
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      7b1b2c1b
    • T
      ext4: add ext4_es_store_pblock_status() · 9a6633b1
      Theodore Ts'o 提交于
      Avoid false positives by static code analysis tools such as sparse and
      coverity caused by the fact that we set the physical block, and then
      the status in the extent_status structure.  It is also more efficient
      to set both of these values at once.
      
      Addresses-Coverity-Id: #989077
      Addresses-Coverity-Id: #989078
      Addresses-Coverity-Id: #1080722
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reviewed-by: NZheng Liu <wenqing.lz@taobao.com>
      9a6633b1
    • E
      ext4: fix error return from ext4_ext_handle_uninitialized_extents() · ce37c429
      Eric Whitney 提交于
      Commit 37794732 breaks the return of error codes from
      ext4_ext_handle_uninitialized_extents() in ext4_ext_map_blocks().  A
      portion of the patch assigns that function's signed integer return
      value to an unsigned int.  Consequently, negatively valued error codes
      are lost and can be treated as a bogus allocated block count.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      ce37c429
  3. 18 2月, 2014 6 次提交
  4. 17 2月, 2014 1 次提交
  5. 16 2月, 2014 2 次提交
    • T
      ext4: fix online resize with a non-standard blocks per group setting · 3d2660d0
      Theodore Ts'o 提交于
      The set_flexbg_block_bitmap() function assumed that the number of
      blocks in a blockgroup was sb->blocksize * 8, which is normally true,
      but not always!  Use EXT4_BLOCKS_PER_GROUP(sb) instead, to fix block
      bitmap corruption after:
      
      mke2fs -t ext4 -g 3072 -i 4096 /dev/vdd 1G
      mount -t ext4 /dev/vdd /vdd
      resize2fs /dev/vdd 8G
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reported-by: NJon Bernard <jbernard@tuxion.com>
      Cc: stable@vger.kernel.org
      3d2660d0
    • T
      ext4: fix online resize with very large inode tables · b93c9535
      Theodore Ts'o 提交于
      If a file system has a large number of inodes per block group, all of
      the metadata blocks in a flex_bg may be larger than what can fit in a
      single block group.  Unfortunately, ext4_alloc_group_tables() in
      resize.c was never tested to see if it would handle this case
      correctly, and there were a large number of bugs which caused the
      following sequence to result in a BUG_ON:
      
      kernel bug at fs/ext4/resize.c:409!
         ...
      call trace:
       [<ffffffff81256768>] ext4_flex_group_add+0x1448/0x1830
       [<ffffffff81257de2>] ext4_resize_fs+0x7b2/0xe80
       [<ffffffff8123ac50>] ext4_ioctl+0xbf0/0xf00
       [<ffffffff811c111d>] do_vfs_ioctl+0x2dd/0x4b0
       [<ffffffff811b9df2>] ? final_putname+0x22/0x50
       [<ffffffff811c1371>] sys_ioctl+0x81/0xa0
       [<ffffffff81676aa9>] system_call_fastpath+0x16/0x1b
      code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0
      rip  [<ffffffff81254fa1>] set_flexbg_block_bitmap+0x171/0x180
      
      
      This can be reproduced with the following command sequence:
      
         mke2fs -t ext4 -i 4096 /dev/vdd 1G
         mount -t ext4 /dev/vdd /vdd
         resize2fs /dev/vdd 8G
      
      To fix this, we need to make sure the right thing happens when a block
      group's inode table straddles two block groups, which means the
      following bugs had to be fixed:
      
      1) Not clearing the BLOCK_UNINIT flag in the second block group in
         ext4_alloc_group_tables --- the was proximate cause of the BUG_ON.
      
      2) Incorrectly determining how many block groups contained contiguous
         free blocks in ext4_alloc_group_tables().
      
      3) Incorrectly setting the start of the next block range to be marked
         in use after a discontinuity in setup_new_flex_group_blocks().
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      b93c9535
  6. 13 2月, 2014 2 次提交
  7. 12 2月, 2014 1 次提交
    • E
      ext4: fix xfstest generic/299 block validity failures · 15cc1767
      Eric Whitney 提交于
      Commit a115f749 (ext4: remove wait for unwritten extent conversion from
      ext4_truncate) exposed a bug in ext4_ext_handle_uninitialized_extents().
      It can be triggered by xfstest generic/299 when run on a test file
      system created without a journal.  This test continuously fallocates and
      truncates files to which random dio/aio writes are simultaneously
      performed by a separate process.  The test completes successfully, but
      if the test filesystem is mounted with the block_validity option, a
      warning message stating that a logical block has been mapped to an
      illegal physical block is posted in the kernel log.
      
      The bug occurs when an extent is being converted to the written state
      by ext4_end_io_dio() and ext4_ext_handle_uninitialized_extents()
      discovers a mapping for an existing uninitialized extent. Although it
      sets EXT4_MAP_MAPPED in map->m_flags, it fails to set map->m_pblk to
      the discovered physical block number.  Because map->m_pblk is not
      otherwise initialized or set by this function or its callers, its
      uninitialized value is returned to ext4_map_blocks(), where it is
      stored as a bogus mapping in the extent status tree.
      
      Since map->m_pblk can accidentally contain illegal values that are
      larger than the physical size of the file system,  calls to
      check_block_validity() in ext4_map_blocks() that are enabled if the
      block_validity mount option is used can fail, resulting in the logged
      warning message.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org  # 3.11+
      15cc1767
  8. 10 2月, 2014 8 次提交
  9. 09 2月, 2014 10 次提交
    • F
      Btrfs: fix data corruption when reading/updating compressed extents · a2aa75e1
      Filipe David Borba Manana 提交于
      When using a mix of compressed file extents and prealloc extents, it
      is possible to fill a page of a file with random, garbage data from
      some unrelated previous use of the page, instead of a sequence of zeroes.
      
      A simple sequence of steps to get into such case, taken from the test
      case I made for xfstests, is:
      
         _scratch_mkfs
         _scratch_mount "-o compress-force=lzo"
         $XFS_IO_PROG -f -c "pwrite -S 0x06 -b 18670 266978 18670" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "falloc 26450 665194" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "truncate 542872" $SCRATCH_MNT/foobar
         $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar
      
      This results in the following file items in the fs tree:
      
         item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160
             inode generation 6 transid 6 size 542872 block group 0 mode 100600
         item 5 key (257 INODE_REF 256) itemoff 15863 itemsize 16
             inode ref index 2 namelen 6 name: foobar
         item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53
             extent data disk byte 0 nr 0 gen 6
             extent data offset 0 nr 24576 ram 266240
             extent compression 0
         item 7 key (257 EXTENT_DATA 24576) itemoff 15757 itemsize 53
             prealloc data disk byte 12849152 nr 241664 gen 6
             prealloc data offset 0 nr 241664
         item 8 key (257 EXTENT_DATA 266240) itemoff 15704 itemsize 53
             extent data disk byte 12845056 nr 4096 gen 6
             extent data offset 0 nr 20480 ram 20480
             extent compression 2
         item 9 key (257 EXTENT_DATA 286720) itemoff 15651 itemsize 53
             prealloc data disk byte 13090816 nr 405504 gen 6
             prealloc data offset 0 nr 258048
      
      The on disk extent at offset 266240 (which corresponds to 1 single disk block),
      contains 5 compressed chunks of file data. Each of the first 4 compress 4096
      bytes of file data, while the last one only compresses 3024 bytes of file data.
      Therefore a read into the file region [285648 ; 286720[ (length = 4096 - 3024 =
      1072 bytes) should always return zeroes (our next extent is a prealloc one).
      
      The solution here is the compression code path to zero the remaining (untouched)
      bytes of the last page it uncompressed data into, as the information about how
      much space the file data consumes in the last page is not known in the upper layer
      fs/btrfs/extent_io.c:__do_readpage(). In __do_readpage we were correctly zeroing
      the remainder of the page but only if it corresponds to the last page of the inode
      and if the inode's size is not a multiple of the page size.
      
      This would cause not only returning random data on reads, but also permanently
      storing random data when updating parts of the region that should be zeroed.
      For the example above, it means updating a single byte in the region [285648 ; 286720[
      would store that byte correctly but also store random data on disk.
      
      A test case for xfstests follows soon.
      Signed-off-by: NFilipe David Borba Manana <fdmanana@gmail.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      a2aa75e1
    • J
      Btrfs: don't loop forever if we can't run because of the tree mod log · 27a377db
      Josef Bacik 提交于
      A user reported a 100% cpu hang with my new delayed ref code.  Turns out I
      forgot to increase the count check when we can't run a delayed ref because of
      the tree mod log.  If we can't run any delayed refs during this there is no
      point in continuing to look, and we need to break out.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      27a377db
    • D
      btrfs: reserve no transaction units in btrfs_ioctl_set_features · 8051aa1a
      David Sterba 提交于
      Added in patch "btrfs: add ioctls to query/change feature bits online"
      modifications to superblock don't need to reserve metadata blocks when
      starting a transaction.
      Signed-off-by: NDavid Sterba <dsterba@suse.cz>
      Signed-off-by: NChris Mason <clm@fb.com>
      8051aa1a
    • J
      btrfs: commit transaction after setting label and features · d0270aca
      Jeff Mahoney 提交于
      The set_fslabel ioctl uses btrfs_end_transaction, which means it's
      possible that the change will be lost if the system crashes, same for
      the newly set features. Let's use btrfs_commit_transaction instead.
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.cz>
      Signed-off-by: NChris Mason <clm@fb.com>
      d0270aca
    • J
      Btrfs: fix assert screwup for the pending move stuff · 6cc98d90
      Josef Bacik 提交于
      Wang noticed that he was failing btrfs/030 even though me and Filipe couldn't
      reproduce.  Turns out this is because Wang didn't have CONFIG_BTRFS_ASSERT set,
      which meant that a key part of Filipe's original patch was not being built in.
      This appears to be a mess up with merging Filipe's patch as it does not exist in
      his original patch.  Fix this by changing how we make sure del_waiting_dir_move
      asserts that it did not error and take the function out of the ifdef check.
      This makes btrfs/030 pass with the assert on or off.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      Reviewed-by: NFilipe Manana <fdmanana@gmail.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      6cc98d90
    • L
      Merge tag 'pinctrl-v3.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · 49447903
      Linus Torvalds 提交于
      Pull pinctrl fixes from Linus Walleij:
       "First round of pin control fixes for v3.14:
      
         - Protect pinctrl_list_add() with the proper mutex.  This was
           identified by RedHat.  Caused nasty locking warnings was rootcased
           by Stanislaw Gruszka.
      
         - Avoid adding dangerous debugfs files when either half of the
           subsystem is unused: pinmux or pinconf.
      
         - Various fixes to various drivers: locking, hardware particulars, DT
           parsing, error codes"
      
      * tag 'pinctrl-v3.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: tegra: return correct error type
        pinctrl: do not init debugfs entries for unimplemented functionalities
        pinctrl: protect pinctrl_list add
        pinctrl: sirf: correct the pin index of ac97_pins group
        pinctrl: imx27: fix offset calculation in imx_read_2bit
        pinctrl: vt8500: Change devicetree data parsing
        pinctrl: imx27: fix wrong offset to ICONFB
        pinctrl: at91: use locked variant of irq_set_handler
      49447903
    • L
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · c132adef
      Linus Torvalds 提交于
      Pull irq fix from Thomas Gleixner:
       "Add a missing Kconfig dependency"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        genirq: Generic irq chip requires IRQ_DOMAIN
      c132adef
    • L
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · c1ff8431
      Linus Torvalds 提交于
      Pull x86 fixes from Peter Anvin:
       "Quite a varied little collection of fixes.  Most of them are
        relatively small or isolated; the biggest one is Mel Gorman's fixes
        for TLB range flushing.
      
        A couple of AMD-related fixes (including not crashing when given an
        invalid microcode image) and fix a crash when compiled with gcov"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, microcode, AMD: Unify valid container checks
        x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y
        x86/efi: Allow mapping BGRT on x86-32
        x86: Fix the initialization of physnode_map
        x86, cpu hotplug: Fix stack frame warning in check_irq_vectors_for_cpu_disable()
        x86/intel/mid: Fix X86_INTEL_MID dependencies
        arch/x86/mm/srat: Skip NUMA_NO_NODE while parsing SLIT
        mm, x86: Revisit tlb_flushall_shift tuning for page flushes except on IvyBridge
        x86: mm: change tlb_flushall_shift for IvyBridge
        x86/mm: Eliminate redundant page table walk during TLB range flushing
        x86/mm: Clean up inconsistencies when flushing TLB ranges
        mm, x86: Account for TLB flushes only when debugging
        x86/AMD/NB: Fix amd_set_subcaches() parameter type
        x86/quirks: Add workaround for AMD F16h Erratum792
        x86, doc, kconfig: Fix dud URL for Microcode data
      c1ff8431
    • L
      Merge tag 'jfs-3.14-rc2' of git://github.com/kleikamp/linux-shaggy · ec2e6cb2
      Linus Torvalds 提交于
      Pull jfs fix from David Kleikamp:
       "Fix regression"
      
      * tag 'jfs-3.14-rc2' of git://github.com/kleikamp/linux-shaggy:
        jfs: fix generic posix ACL regression
      ec2e6cb2
    • D
      jfs: fix generic posix ACL regression · c18f7b51
      Dave Kleikamp 提交于
      I missed a couple errors in reviewing the patches converting jfs
      to use the generic posix ACL function. Setting ACL's currently
      fails with -EOPNOTSUPP.
      Signed-off-by: NDave Kleikamp <dave.kleikamp@oracle.com>
      Reported-by: NMichael L. Semon <mlsemon35@gmail.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      c18f7b51
  10. 08 2月, 2014 3 次提交