1. 24 4月, 2018 1 次提交
    • L
      ext4: fix bitmap position validation · 22be37ac
      Lukas Czerner 提交于
      Currently in ext4_valid_block_bitmap() we expect the bitmap to be
      positioned anywhere between 0 and s_blocksize clusters, but that's
      wrong because the bitmap can be placed anywhere in the block group. This
      causes false positives when validating bitmaps on perfectly valid file
      system layouts. Fix it by checking whether the bitmap is within the group
      boundary.
      
      The problem can be reproduced using the following
      
      mkfs -t ext3 -E stride=256 /dev/vdb1
      mount /dev/vdb1 /mnt/test
      cd /mnt/test
      wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.3.tar.xz
      tar xf linux-4.16.3.tar.xz
      
      This will result in the warnings in the logs
      
      EXT4-fs error (device vdb1): ext4_validate_block_bitmap:399: comm tar: bg 84: block 2774529: invalid block bitmap
      
      [ Changed slightly for clarity and to not drop a overflow test -- TYT ]
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reported-by: NIlya Dryomov <idryomov@gmail.com>
      Fixes: 7dac4a17 ("ext4: add validity checks for bitmap block numbers")
      Cc: stable@vger.kernel.org
      22be37ac
  2. 18 4月, 2018 1 次提交
    • T
      ext4: set h_journal if there is a failure starting a reserved handle · b2569260
      Theodore Ts'o 提交于
      If ext4 tries to start a reserved handle via
      jbd2_journal_start_reserved(), and the journal has been aborted, this
      can result in a NULL pointer dereference.  This is because the fields
      h_journal and h_transaction in the handle structure share the same
      memory, via a union, so jbd2_journal_start_reserved() will clear
      h_journal before calling start_this_handle().  If this function fails
      due to an aborted handle, h_journal will still be NULL, and the call
      to jbd2_journal_free_reserved() will pass a NULL journal to
      sub_reserve_credits().
      
      This can be reproduced by running "kvm-xfstests -c dioread_nolock
      generic/475".
      
      Cc: stable@kernel.org # 3.11
      Fixes: 8f7d89f3 ("jbd2: transaction reservation support")
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: NAndreas Dilger <adilger@dilger.ca>
      Reviewed-by: NJan Kara <jack@suse.cz>
      b2569260
  3. 12 4月, 2018 1 次提交
    • E
      ext4: prevent right-shifting extents beyond EXT_MAX_BLOCKS · 349fa7d6
      Eric Biggers 提交于
      During the "insert range" fallocate operation, extents starting at the
      range offset are shifted "right" (to a higher file offset) by the range
      length.  But, as shown by syzbot, it's not validated that this doesn't
      cause extents to be shifted beyond EXT_MAX_BLOCKS.  In that case
      ->ee_block can wrap around, corrupting the extent tree.
      
      Fix it by returning an error if the space between the end of the last
      extent and EXT4_MAX_BLOCKS is smaller than the range being inserted.
      
      This bug can be reproduced by running the following commands when the
      current directory is on an ext4 filesystem with a 4k block size:
      
              fallocate -l 8192 file
              fallocate --keep-size -o 0xfffffffe000 -l 4096 -n file
              fallocate --insert-range -l 8192 file
      
      Then after unmounting the filesystem, e2fsck reports corruption.
      
      Reported-by: syzbot+06c885be0edcdaeab40c@syzkaller.appspotmail.com
      Fixes: 331573fe ("ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate")
      Cc: stable@vger.kernel.org # v4.2+
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      349fa7d6
  4. 02 4月, 2018 1 次提交
    • T
      ext4: force revalidation of directory pointer after seekdir(2) · e40ff213
      Theodore Ts'o 提交于
      A malicious user could force the directory pointer to be in an invalid
      spot by using seekdir(2).  Use the mechanism we already have to notice
      if the directory has changed since the last time we called
      ext4_readdir() to force a revalidation of the pointer.
      
      Reported-by: syzbot+1236ce66f79263e8a862@syzkaller.appspotmail.com
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      e40ff213
  5. 31 3月, 2018 3 次提交
  6. 30 3月, 2018 10 次提交
  7. 27 3月, 2018 1 次提交
  8. 26 3月, 2018 2 次提交
  9. 22 3月, 2018 5 次提交
    • E
      ext4: don't complain about incorrect features when probing · 0d9366d6
      Eric Sandeen 提交于
      If mount is auto-probing for filesystem type, it will try various
      filesystems in order, with the MS_SILENT flag set.  We get
      that flag as the silent arg to ext4_fill_super.
      
      If we're probing (silent==1) then don't complain about feature
      incompatibilities that are found if it looks like it's actually
      a different valid extN type - failed probes should be silent
      in this case.
      
      If the on-disk features are unknown even to ext4, then complain.
      Reported-by: NJoakim Tjernlund <Joakim.Tjernlund@infinera.com>
      Tested-by: NJoakim Tjernlund <Joakim.Tjernlund@infinera.com>
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: NJan Kara <jack@suse.cz>
      0d9366d6
    • N
      ext4: remove EXT4_STATE_DIOREAD_LOCK flag · 1d39834f
      Nikolay Borisov 提交于
      Commit 16c54688 ("ext4: Allow parallel DIO reads") reworked the way
      locking happens around parallel dio reads. This resulted in obviating
      the need for EXT4_STATE_DIOREAD_LOCK flag and accompanying logic.
      Currently this amounts to dead code so let's remove it. No functional
      changes
      Signed-off-by: NNikolay Borisov <nborisov@suse.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: NJan Kara <jack@suse.cz>
      1d39834f
    • J
      ext4: fix offset overflow on 32-bit archs in ext4_iomap_begin() · fe23cb65
      Jiri Slaby 提交于
      ext4_iomap_begin() has a bug where offset returned in the iomap
      structure will be truncated to unsigned long size. On 64-bit
      architectures this is fine but on 32-bit architectures obviously not.
      Not many places actually use the offset stored in the iomap structure
      but one of visible failures is in SEEK_HOLE / SEEK_DATA implementation.
      If we create a file like:
      
      dd if=/dev/urandom of=file bs=1k seek=8m count=1
      
      then
      
      lseek64("file", 0x100000000ULL, SEEK_DATA)
      
      wrongly returns 0x100000000 on unfixed kernel while it should return
      0x200000000. Avoid the overflow by proper type cast.
      
      Fixes: 545052e9 ("ext4: Switch to iomap for SEEK_HOLE / SEEK_DATA")
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org # v4.15
      fe23cb65
    • E
      ext4: update i_disksize if direct write past ondisk size · 45d8ec4d
      Eryu Guan 提交于
      Currently in ext4 direct write path, we update i_disksize only when
      new eof is greater than i_size, and don't update it even when new
      eof is greater than i_disksize but less than i_size. This doesn't
      work well with delalloc buffer write, which updates i_size and
      i_disksize only when delalloc blocks are resolved (at writeback
      time), the i_disksize from direct write can be lost if a previous
      buffer write succeeded at write time but failed at writeback time,
      then results in corrupted ondisk inode size.
      
      Consider this case, first buffer write 4k data to a new file at
      offset 16k with delayed allocation, then direct write 4k data to the
      same file at offset 4k before delalloc blocks are resolved, which
      doesn't update i_disksize because it writes within i_size(20k), but
      the extent tree metadata has been committed in journal. Then
      writeback of the delalloc blocks fails (due to device error etc.),
      and i_size/i_disksize from buffer write can't be written to disk
      (still zero). A subsequent umount/mount cycle recovers journal and
      writes extent tree metadata from direct write to disk, but with
      i_disksize being zero.
      
      Fix it by updating i_disksize too in direct write path when new eof
      is greater than i_disksize but less than i_size, so i_disksize is
      always consistent with direct write.
      
      This fixes occasional i_size corruption in fstests generic/475.
      Signed-off-by: NEryu Guan <guaneryu@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      45d8ec4d
    • E
      ext4: protect i_disksize update by i_data_sem in direct write path · 73fdad00
      Eryu Guan 提交于
      i_disksize update should be protected by i_data_sem, by either taking
      the lock explicitly or by using ext4_update_i_disksize() helper. But the
      i_disksize updates in ext4_direct_IO_write() are not protected at all,
      which may be racing with i_disksize updates in writeback path in
      delalloc buffer write path.
      
      This is found by code inspection, and I didn't hit any i_disksize
      corruption due to this bug. Thanks to Jan Kara for catching this bug and
      suggesting the fix!
      Reported-by: NJan Kara <jack@suse.cz>
      Suggested-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NEryu Guan <guaneryu@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      73fdad00
  10. 20 2月, 2018 2 次提交
  11. 19 2月, 2018 5 次提交
  12. 12 2月, 2018 7 次提交
    • L
      Linux 4.16-rc1 · 7928b2cb
      Linus Torvalds 提交于
      7928b2cb
    • A
      unify {de,}mangle_poll(), get rid of kernel-side POLL... · 7a163b21
      Al Viro 提交于
      except, again, POLLFREE and POLL_BUSY_LOOP.
      
      With this, we finally get to the promised end result:
      
       - POLL{IN,OUT,...} are plain integers and *not* in __poll_t, so any
         stray instances of ->poll() still using those will be caught by
         sparse.
      
       - eventpoll.c and select.c warning-free wrt __poll_t
      
       - no more kernel-side definitions of POLL... - userland ones are
         visible through the entire kernel (and used pretty much only for
         mangle/demangle)
      
       - same behavior as after the first series (i.e. sparc et.al. epoll(2)
         working correctly).
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7a163b21
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
    • L
      Merge branch 'work.poll2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · ee5daa13
      Linus Torvalds 提交于
      Pull more poll annotation updates from Al Viro:
       "This is preparation to solving the problems you've mentioned in the
        original poll series.
      
        After this series, the kernel is ready for running
      
            for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
                  L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
                  for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
            done
      
        as a for bulk search-and-replace.
      
        After that, the kernel is ready to apply the patch to unify
        {de,}mangle_poll(), and then get rid of kernel-side POLL... uses
        entirely, and we should be all done with that stuff.
      
        Basically, that's what you suggested wrt KPOLL..., except that we can
        use EPOLL... instead - they already are arch-independent (and equal to
        what is currently kernel-side POLL...).
      
        After the preparations (in this series) switch to returning EPOLL...
        from ->poll() instances is completely mechanical and kernel-side
        POLL... can go away. The last step (killing kernel-side POLL... and
        unifying {de,}mangle_poll() has to be done after the
        search-and-replace job, since we need userland-side POLL... for
        unified {de,}mangle_poll(), thus the cherry-pick at the last step.
      
        After that we will have:
      
         - POLL{IN,OUT,...} *not* in __poll_t, so any stray instances of
           ->poll() still using those will be caught by sparse.
      
         - eventpoll.c and select.c warning-free wrt __poll_t
      
         - no more kernel-side definitions of POLL... - userland ones are
           visible through the entire kernel (and used pretty much only for
           mangle/demangle)
      
         - same behavior as after the first series (i.e. sparc et.al. epoll(2)
           working correctly)"
      
      * 'work.poll2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        annotate ep_scan_ready_list()
        ep_send_events_proc(): return result via esed->res
        preparation to switching ->poll() to returning EPOLL...
        add EPOLLNVAL, annotate EPOLL... and event_poll->event
        use linux/poll.h instead of asm/poll.h
        xen: fix poll misannotation
        smc: missing poll annotations
      ee5daa13
    • L
      Merge tag 'xtensa-20180211' of git://github.com/jcmvbkbc/linux-xtensa · 3fc928dc
      Linus Torvalds 提交于
      Pull xtense fix from Max Filippov:
       "Build fix for xtensa architecture with KASAN enabled"
      
      * tag 'xtensa-20180211' of git://github.com/jcmvbkbc/linux-xtensa:
        xtensa: fix build with KASAN
      3fc928dc
    • L
      Merge tag 'nios2-v4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2 · 60d7a21a
      Linus Torvalds 提交于
      Pull nios2 update from Ley Foon Tan:
      
       - clean up old Kconfig options from defconfig
      
       - remove leading 0x and 0s from bindings notation in dts files
      
      * tag 'nios2-v4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2:
        nios2: defconfig: Cleanup from old Kconfig options
        nios2: dts: Remove leading 0x and 0s from bindings notation
      60d7a21a
    • M
      xtensa: fix build with KASAN · f8d0cbf2
      Max Filippov 提交于
      The commit 917538e2 ("kasan: clean up KASAN_SHADOW_SCALE_SHIFT
      usage") removed KASAN_SHADOW_SCALE_SHIFT definition from
      include/linux/kasan.h and added it to architecture-specific headers,
      except for xtensa. This broke the xtensa build with KASAN enabled.
      Define KASAN_SHADOW_SCALE_SHIFT in arch/xtensa/include/asm/kasan.h
      
      Reported by: kbuild test robot <fengguang.wu@intel.com>
      Fixes: 917538e2 ("kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage")
      Acked-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      f8d0cbf2
  13. 11 2月, 2018 1 次提交