1. 06 May, 2016 1 commit
    • Jens Axboe's avatar
      ext4: remove unnecessary bio get/put · 32157de2
      Jens Axboe authored
      ext4_io_submit() used to check for EOPNOTSUPP after bio submission,
      which is why it had to get an extra reference to the bio before
      submitting it. But since we no longer touch the bio after submission,
      get rid of the redundant get/put of the bio. If we do get the extra
      reference, we enter the slower path of having to flag this bio as now
      having external references.
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      32157de2
  2. 05 May, 2016 4 commits
    • Nicolai Stange's avatar
      ext4: silence UBSAN in ext4_mb_init() · 935244cd
      Nicolai Stange authored
      Currently, in ext4_mb_init(), there's a loop like the following:
      
        do {
          ...
          offset += 1 << (sb->s_blocksize_bits - i);
          i++;
        } while (i <= sb->s_blocksize_bits + 1);
      
      Note that the updated offset is used in the loop's next iteration only.
      
      However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
      the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
      and UBSAN reports
      
        UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
        shift exponent 4294967295 is too large for 32-bit type 'int'
        [...]
        Call Trace:
         [<ffffffff818c4d25>] dump_stack+0xbc/0x117
         [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
         [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
         [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
         [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
         [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
         [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
         [<ffffffff814293c7>] ? create_cache+0x57/0x1f0
         [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
         [<ffffffff821c2168>] ? mutex_lock+0x38/0x60
         [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
         [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
         [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
         [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
         [...]
      
      Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
      
      Unless compilers start to do some fancy transformations (which at least
      GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
      such calculated value of offset is never used again.
      
      Silence UBSAN by introducing another variable, offset_incr, holding the
      next increment to apply to offset and adjust that one by right shifting it
      by one position per loop iteration.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      935244cd
    • Nicolai Stange's avatar
      ext4: address UBSAN warning in mb_find_order_for_block() · b5cb316c
      Nicolai Stange authored
      Currently, in mb_find_order_for_block(), there's a loop like the following:
      
        while (order <= e4b->bd_blkbits + 1) {
          ...
          bb += 1 << (e4b->bd_blkbits - order);
        }
      
      Note that the updated bb is used in the loop's next iteration only.
      
      However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
      the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports
      
        UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
        shift exponent -1 is negative
        [...]
        Call Trace:
         [<ffffffff818c4d35>] dump_stack+0xbc/0x117
         [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
         [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e
         [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
         [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
         [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590
         [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80
         [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240
         [...]
      
      Unless compilers start to do some fancy transformations (which at least
      GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
      such calculated value of bb is never used again.
      
      Silence UBSAN by introducing another variable, bb_incr, holding the next
      increment to apply to bb and adjust that one by right shifting it by one
      position per loop iteration.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      b5cb316c
    • Jan Kara's avatar
      ext4: fix oops on corrupted filesystem · 74177f55
      Jan Kara authored
      When filesystem is corrupted in the right way, it can happen
      ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we
      subsequently remove inode from the in-memory orphan list. However this
      deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we
      leave i_orphan list_head with a stale content. Later we can look at this
      content causing list corruption, oops, or other issues. The reported
      trace looked like:
      
      WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100()
      list_del corruption, 0000000061c1d6e0->next is LIST_POISON1
      0000000000100100)
      CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250
      Stack:
       60462947 62219960 602ede24 62219960
       602ede24 603ca293 622198f0 602f02eb
       62219950 6002c12c 62219900 601b4d6b
      Call Trace:
       [<6005769c>] ? vprintk_emit+0x2dc/0x5c0
       [<602ede24>] ? printk+0x0/0x94
       [<600190bc>] show_stack+0xdc/0x1a0
       [<602ede24>] ? printk+0x0/0x94
       [<602ede24>] ? printk+0x0/0x94
       [<602f02eb>] dump_stack+0x2a/0x2c
       [<6002c12c>] warn_slowpath_common+0x9c/0xf0
       [<601b4d6b>] ? __list_del_entry+0x6b/0x100
       [<6002c254>] warn_slowpath_fmt+0x94/0xa0
       [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0
       [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0
       [<60023ebf>] ? set_signals+0x3f/0x50
       [<600a205a>] ? kmem_cache_free+0x10a/0x180
       [<602f4e88>] ? mutex_lock+0x18/0x30
       [<601b4d6b>] __list_del_entry+0x6b/0x100
       [<601177ec>] ext4_orphan_del+0x22c/0x2f0
       [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0
       [<6010b973>] ? ext4_truncate+0x383/0x390
       [<6010bc8b>] ext4_write_begin+0x30b/0x4b0
       [<6001bb50>] ? copy_from_user+0x0/0xb0
       [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0
       [<60072c4f>] generic_perform_write+0xaf/0x1e0
       [<600c4166>] ? file_update_time+0x46/0x110
       [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0
       [<6010030f>] ext4_file_write_iter+0x15f/0x470
       [<60094e10>] ? unlink_file_vma+0x0/0x70
       [<6009b180>] ? unlink_anon_vmas+0x0/0x260
       [<6008f169>] ? free_pgtables+0xb9/0x100
       [<600a6030>] __vfs_write+0xb0/0x130
       [<600a61d5>] vfs_write+0xa5/0x170
       [<600a63d6>] SyS_write+0x56/0xe0
       [<6029fcb0>] ? __libc_waitpid+0x0/0xa0
       [<6001b698>] handle_syscall+0x68/0x90
       [<6002633d>] userspace+0x4fd/0x600
       [<6002274f>] ? save_registers+0x1f/0x40
       [<60028bd7>] ? arch_prctl+0x177/0x1b0
       [<60017bd5>] fork_handler+0x85/0x90
      
      Fix the problem by using list_del_init() as we always should with
      i_orphan list.
      
      CC: stable@vger.kernel.org
      Reported-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      74177f55
    • Seth Forshee's avatar
      ext4: fix check of dqget() return value in ext4_ioctl_setproject() · ff0bc084
      Seth Forshee authored
      A failed call to dqget() returns an ERR_PTR() and not null. Fix
      the check in ext4_ioctl_setproject() to handle this correctly.
      
      Fixes: 9b7365fc ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support")
      Cc: stable@vger.kernel.org # v4.5
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      ff0bc084
  3. 30 Apr, 2016 2 commits
    • Theodore Ts'o's avatar
      ext4: clean up error handling when orphan list is corrupted · 7827a7f6
      Theodore Ts'o authored
      Instead of just printing warning messages, if the orphan list is
      corrupted, declare the file system is corrupted.  If there are any
      reserved inodes in the orphaned inode list, declare the file system
      corrupted and stop right away to avoid doing more potential damage to
      the file system.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      7827a7f6
    • Theodore Ts'o's avatar
      ext4: fix hang when processing corrupted orphaned inode list · c9eb13a9
      Theodore Ts'o authored
      If the orphaned inode list contains inode #5, ext4_iget() returns a
      bad inode (since the bootloader inode should never be referenced
      directly).  Because of the bad inode, we end up processing the inode
      repeatedly and this hangs the machine.
      
      This can be reproduced via:
      
         mke2fs -t ext4 /tmp/foo.img 100
         debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
         mount -o loop /tmp/foo.img /mnt
      
      (But don't do this if you are using an unpatched kernel if you care
      about the system staying functional.  :-)
      
      This bug was found by the port of American Fuzzy Lop into the kernel
      to find file system problems[1].  (Since it *only* happens if inode #5
      shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
      surprising that AFL needed two hours before it found it.)
      
      [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf
      
      Cc: stable@vger.kernel.org
      Reported by: Vegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      c9eb13a9
  4. 27 Apr, 2016 1 commit
  5. 26 Apr, 2016 3 commits
    • Daeho Jeong's avatar
      ext4: fix races between changing inode journal mode and ext4_writepages · c8585c6f
      Daeho Jeong authored
      In ext4, there is a race condition between changing inode journal mode
      and ext4_writepages(). While ext4_writepages() is executed on a
      non-journalled mode inode, the inode's journal mode could be enabled
      by ioctl() and then, some pages dirtied after switching the journal
      mode will be still exposed to ext4_writepages() in non-journaled mode.
      To resolve this problem, we use fs-wide per-cpu rw semaphore by Jan
      Kara's suggestion because we don't want to waste ext4_inode_info's
      space for this extra rare case.
      Signed-off-by: default avatarDaeho Jeong <daeho.jeong@samsung.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      c8585c6f
    • Daeho Jeong's avatar
      ext4: handle unwritten or delalloc buffers before enabling data journaling · 4c546592
      Daeho Jeong authored
      We already allocate delalloc blocks before changing the inode mode into
      "per-file data journal" mode to prevent delalloc blocks from remaining
      not allocated, but another issue concerned with "BH_Unwritten" status
      still exists. For example, by fallocate(), several buffers' status
      change into "BH_Unwritten", but these buffers cannot be processed by
      ext4_alloc_da_blocks(). So, they still remain in unwritten status after
      per-file data journaling is enabled and they cannot be changed into
      written status any more and, if they are journaled and eventually
      checkpointed, these unwritten buffer will cause a kernel panic by the
      below BUG_ON() function of submit_bh_wbc() when they are submitted
      during checkpointing.
      
      static int submit_bh_wbc(int rw, struct buffer_head *bh,...
      {
              ...
              BUG_ON(buffer_unwritten(bh));
      
      Moreover, when "dioread_nolock" option is enabled, the status of a
      buffer is changed into "BH_Unwritten" after write_begin() completes and
      the "BH_Unwritten" status will be cleared after I/O is done. Therefore,
      if a buffer's status is changed into unwrutten but the buffer's I/O is
      not submitted and completed, it can cause the same problem after
      enabling per-file data journaling. You can easily generate this bug by
      executing the following command.
      
      ./kvm-xfstests -C 10000 -m nodelalloc,dioread_nolock generic/269
      
      To resolve these problems and define a boundary between the previous
      mode and per-file data journaling mode, we need to flush and wait all
      the I/O of buffers of a file before enabling per-file data journaling
      of the file.
      Signed-off-by: default avatarDaeho Jeong <daeho.jeong@samsung.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      4c546592
    • Theodore Ts'o's avatar
      ext4: fix jbd2 handle extension in ext4_ext_truncate_extend_restart() · 7b808191
      Theodore Ts'o authored
      The function jbd2_journal_extend() takes as its argument the number of
      new credits to be added to the handle.  We weren't taking into account
      the currently unused handle credits; worse, we would try to extend the
      handle by N credits when it had N credits available.
      
      In the case where jbd2_journal_extend() fails because the transaction
      is too large, when jbd2_journal_restart() gets called, the N credits
      owned by the handle gets returned to the transaction, and the
      transaction commit is asynchronously requested, and then
      start_this_handle() will be able to successfully attach the handle to
      the current transaction since the required credits are now available.
      
      This is mostly harmless, but since ext4_ext_truncate_extend_restart()
      returns EAGAIN, the truncate machinery will once again try to call
      ext4_ext_truncate_extend_restart(), which will do the above sequence
      over and over again until the transaction has committed.
      
      This was found while I was debugging a lockup in caused by running
      xfstests generic/074 in the data=journal case.  I'm still not sure why
      we ended up looping forever, which suggests there may still be another
      bug hiding in the transaction accounting machinery, but this commit
      prevents us from looping in the first place.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      7b808191
  6. 24 Apr, 2016 5 commits
    • Jan Kara's avatar
      ext4: do not ask jbd2 to write data for delalloc buffers · ee0876bc
      Jan Kara authored
      Currently we ask jbd2 to write all dirty allocated buffers before
      committing a transaction when doing writeback of delay allocated blocks.
      However this is unnecessary since we move all pages to writeback state
      before dropping a transaction handle and then submit all the necessary
      IO. We still need the transaction commit to wait for all the outstanding
      writeback before flushing disk caches during transaction commit to avoid
      data exposure issues though. Use the new jbd2 capability and ask it to
      only wait for outstanding writeback during transaction commit when
      writing back data in ext4_writepages().
      Tested-by: default avatar"HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      ee0876bc
    • Jan Kara's avatar
      jbd2: add support for avoiding data writes during transaction commits · 41617e1a
      Jan Kara authored
      Currently when filesystem needs to make sure data is on permanent
      storage before committing a transaction it adds inode to transaction's
      inode list. During transaction commit, jbd2 writes back all dirty
      buffers that have allocated underlying blocks and waits for the IO to
      finish. However when doing writeback for delayed allocated data, we
      allocate blocks and immediately submit the data. Thus asking jbd2 to
      write dirty pages just unnecessarily adds more work to jbd2 possibly
      writing back other redirtied blocks.
      
      Add support to jbd2 to allow filesystem to ask jbd2 to only wait for
      outstanding data writes before committing a transaction and thus avoid
      unnecessary writes.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      41617e1a
    • Jan Kara's avatar
      ext4: remove EXT4_STATE_ORDERED_MODE · 3957ef53
      Jan Kara authored
      This flag is just duplicating what ext4_should_order_data() tells you
      and is used in a single place. Furthermore it doesn't reflect changes to
      inode data journalling flag so it may be possibly misleading. Just
      remove it.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      3957ef53
    • Jan Kara's avatar
      ext4: fix data exposure after a crash · 06bd3c36
      Jan Kara authored
      Huang has reported that in his powerfail testing he is seeing stale
      block contents in some of recently allocated blocks although he mounts
      ext4 in data=ordered mode. After some investigation I have found out
      that indeed when delayed allocation is used, we don't add inode to
      transaction's list of inodes needing flushing before commit. Originally
      we were doing that but commit f3b59291 removed the logic with a
      flawed argument that it is not needed.
      
      The problem is that although for delayed allocated blocks we write their
      contents immediately after allocating them, there is no guarantee that
      the IO scheduler or device doesn't reorder things and thus transaction
      allocating blocks and attaching them to inode can reach stable storage
      before actual block contents. Actually whenever we attach freshly
      allocated blocks to inode using a written extent, we should add inode to
      transaction's ordered inode list to make sure we properly wait for block
      contents to be written before committing the transaction. So that is
      what we do in this patch. This also handles other cases where stale data
      exposure was possible - like filling hole via mmap in
      data=ordered,nodelalloc mode.
      
      The only exception to the above rule are extending direct IO writes where
      blkdev_direct_IO() waits for IO to complete before increasing i_size and
      thus stale data exposure is not possible. For now we don't complicate
      the code with optimizing this special case since the overhead is pretty
      low. In case this is observed to be a performance problem we can always
      handle it using a special flag to ext4_map_blocks().
      
      CC: stable@vger.kernel.org
      Fixes: f3b59291Reported-by: default avatar"HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
      Tested-by: default avatar"HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      06bd3c36
    • Theodore Ts'o's avatar
      ext4: allow readdir()'s of large empty directories to be interrupted · 1f60fbe7
      Theodore Ts'o authored
      If a directory has a large number of empty blocks, iterating over all
      of them can take a long time, leading to scheduler warnings and users
      getting irritated when they can't kill a process in the middle of one
      of these long-running readdir operations.  Fix this by adding checks to
      ext4_readdir() and ext4_htree_fill_tree().
      
      This was reverted earlier due to a typo in the original commit where I
      experimented with using signal_pending() instead of
      fatal_signal_pending().  The test was in the wrong place if we were
      going to return signal_pending() since we would end up returning
      duplicant entries.  See 9f2394c9 for a more detailed explanation.
      
      Added fix as suggested by Linus to check for signal_pending() in
      in the filldir() functions.
      Reported-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Google-Bug-Id: 27880676
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      1f60fbe7
  7. 18 Apr, 2016 1 commit
  8. 17 Apr, 2016 5 commits
  9. 16 Apr, 2016 7 commits
  10. 15 Apr, 2016 11 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 2e572599
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "A few fixes for the current series. This contains:
      
         - Two fixes for NVMe:
      
           One fixes a reset race that can be triggered by repeated
           insert/removal of the module.
      
           The other fixes an issue on some platforms, where we get probe
           timeouts since legacy interrupts isn't working.  This used not to
           be a problem since we had the worker thread poll for completions,
           but since that was killed off, it means those poor souls can't
           successfully probe their NVMe device.  Use a proper IRQ check and
           probe (msi-x -> msi ->legacy), like most other drivers to work
           around this.  Both from Keith.
      
         - A loop corruption issue with offset in iters, from Ming Lei.
      
         - A fix for not having the partition stat per cpu ref count
           initialized before sending out the KOBJ_ADD, which could cause user
           space to access the counter prior to initialization.  Also from
           Ming Lei.
      
         - A fix for using the wrong congestion state, from Kaixu Xia"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: loop: fix filesystem corruption in case of aio/dio
        NVMe: Always use MSI/MSI-x interrupts
        NVMe: Fix reset/remove race
        writeback: fix the wrong congested state variable definition
        block: partition: initialize percpuref before sending out KOBJ_ADD
      2e572599
    • Linus Torvalds's avatar
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · f3c9a1ab
      Linus Torvalds authored
      Pull libnvdimm fixes from Ross Zwisler:
       "Two fixes:
      
         - Fix memcpy_from_pmem() to fallback to memcpy() for architectures
           where CONFIG_ARCH_HAS_PMEM_API=n.
      
         - Add a comment explaining why we write data twice when clearing
           poison in pmem_do_bvec().
      
        This has passed a boot test on an X86_32 config, which was the
        architecture where issue #1 above was first noticed"
      
      Dan Williams adds:
       "We're giving this multi-maintainer setup a shot, so expect libnvdimm
        pull requests from either Ross or I going forward"
      
      * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        libnvdimm, pmem: clarify the write+clear_poison+write flow
        pmem: fix BUG() error in pmem.h:48 on X86_32
      f3c9a1ab
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd · 29dde7c2
      Linus Torvalds authored
      Pull MTD fix from Brian Norris:
       "One MTD fix for v4.6-rc4:
      
        In the v4.4 cycle, we relaxed the requirement for assigning
        mtd->owner, but we didn't remove this error case.  It's hit only
        by drivers that are both:
      
         (a) using nand_scan() directly
        and
         (b) built as modules
      
        We haven't seen explicit complaints about this (most use cases don't
        fit one or both of the above), but we should definitely not be
        BUG()'ing here"
      
      * tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd:
        mtd: nand: Drop mtd.owner requirement in nand_scan
      29dde7c2
    • Linus Torvalds's avatar
      Merge tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc · 2fffad12
      Linus Torvalds authored
      Pull MMC fixes from Ulf Hansson:
       "Here are a couple of mmc fixes intended for v4.6 rc4.
      
        Regarding the fix for the regression about mmcblk device indexes.  The
        approach taken to solve the problem seems to be good enough.  There
        were some discussions around the solution, but it seems like people
        were happy about it in the end.
      
        MMC core:
         - Restore similar old behaviour when assigning mmcblk device indexes
      
        MMC host:
         - tegra: Disable UHS-I modes for Tegra124 to fix regression"
      
      * tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc:
        mmc: tegra: Disable UHS-I modes for Tegra124
        mmc: block: Use the mmc host device index as the mmcblk device index
      2fffad12
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · ab5f9eba
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "This contains fixes for exynos, amdgpu, radeon, i915 and qxl.
      
        It also contains some fixes to the core drm edid parser.
      
        qxl:
         - fix for a cursor hotspot issue
      
        radeon:
         - some MST fixes that I've been running locally and make my monitor a
           bit happier
      
        exynos:
         - fix some regressions and build fixes
      
        amdgpu:
         - a couple of small fixes
      
        i915:
         - two DP MST fixes and a couple of other regression fixes
      
        Nothing too out of the ordinary or surprising at this point"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
        drm/exynos: fix a warning message
        drm/exynos: mic: fix an error code
        drm/exynos: fimd: fix broken dp_clock control
        drm/exynos: build fbdev code conditionally
        drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
        drm/exynos: fix error handling in exynos_drm_subdrv_open
        drm/amd/amdgpu: fix irq domain remove for tonga ih
        drm/i915: fix deadlock on lid open
        drm/radeon: use helper for mst connector dpms.
        drm/radeon/mst: port some MST setup code from DAL.
        drm/amdgpu: add invisible pin size statistic
        drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings
        drm/i915: Exit cherryview_irq_handler() after one pass
        drm/i915: Call intel_dp_mst_resume() before resuming displays
        drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
        drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor
        drm/edid: Fix EDID Established Timings I and II
        drm/qxl: fix cursor position with non-zero hotspot
      ab5f9eba
    • Linus Torvalds's avatar
      Merge branch 'parisc-4.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 60ea7bb0
      Linus Torvalds authored
      Pull parisc ftrace fixes from Helge Deller:
       "This is (most likely) the last pull request for v4.6 for the parisc
        architecture.
      
        It fixes the FTRACE feature for parisc, which is horribly broken since
         quite some time and doesn't even compile.  This patch just fixes the
        bare minimum (it actually removes more lines than it adds), so that
        the function tracer works again on 32- and 64bit kernels.
      
        I've queued up additional patches on top of this patch which e.g. add
        the syscall tracer, but those have to wait for the merge window for
        v4.7."
      
      * 'parisc-4.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Fix ftrace function tracer
      60ea7bb0
    • Dan Williams's avatar
      libnvdimm, pmem: clarify the write+clear_poison+write flow · 0a370d26
      Dan Williams authored
      The ACPI specification does not specify the state of data after a clear
      poison operation.  Potential future libnvdimm bus implementations for
      other architectures also might not specify or disagree on the state of
      data after clear poison.  Clarify why we write twice.
      Reported-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Reported-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Reviewed-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      0a370d26
    • Ming Lei's avatar
      block: loop: fix filesystem corruption in case of aio/dio · a7297a6a
      Ming Lei authored
      Starting from commit e36f6204(block: split bios to max possible length),
      block core starts to split bio in the middle of bvec.
      
      Unfortunately loop dio/aio doesn't consider this situation, and
      always treat 'iter.iov_offset' as zero. Then filesystem corruption
      is observed.
      
      This patch figures out the offset of the base bvevc via
      'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset
      to iov iterator.
      
      Fixes: e36f6204 (block: split bios to max possible length)
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@vger.kernel.org (4.5)
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      a7297a6a
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 806fdcce
      Linus Torvalds authored
      Pull x86 fixes from Ingo Molnar:
       "Misc fixes: a binutils fix, an lguest fix, an mcelog fix and a missing
        documentation fix"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/mce: Avoid using object after free in genpool
        lguest, x86/entry/32: Fix handling of guest syscalls using interrupt gates
        x86/build: Build compressed x86 kernels as PIE
        x86/mm/pkeys: Add missing Documentation
      806fdcce
    • Linus Torvalds's avatar
      Merge branch 'mm-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a1f98317
      Linus Torvalds authored
      Pull mm gup cleanup from Ingo Molnar:
       "This removes the ugly get-user-pages API hack, now that all upstream
        code has been migrated to it"
      
      ("ugly" is putting it mildly. But it worked.. - Linus)
      
      * 'mm-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        mm/gup: Remove the macro overload API migration helpers from the get_user*() APIs
      a1f98317
    • Linus Torvalds's avatar
      Merge tag 'dm-4.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · 63a1281b
      Linus Torvalds authored
      Pull device mapper fixes from Mike Snitzer:
      
       - fix a 4.6-rc1 bio-based DM 'struct dm_target_io' leak in an error
         path
      
       - stable@ fix for DM cache metadata's READ_LOCK macros that were
         incorrectly returning error if the block manager was in read-only
         mode; also cleanup multi-statement macros to use do {} while(0)
      
      * tag 'dm-4.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros
        dm: fix dm_target_io leak if clone_bio() returns an error
      63a1281b