The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/914733d4b0838959f818cf54c7ccd5e230766f22

commit 914733d4b0838959f818cf54c7ccd5e230766f22
Author: Dmitry Monakhov <dmonakhov@openvz.org>
Date: Tue Oct 10 21:52:11 2017

UPSTREAM: ext4: move_extent improve bh vanishing success factor

Xiaoguang Wang has reported sporadic EBUSY failures of ext4/302
Unfortunetly there is nothing we can do if some other task holds BH's
refenrence.  So we must return EBUSY in this case.  But we can try
kicking the journal to see if the other task releases the bh reference
after the commit is complete.  Also decrease false positives by
properly checking for ENOSPC and retrying the allocation after kicking
the journal --- which is done by ext4_should_retry_alloc().

[ Modified by tytso to properly check for ENOSPC. ]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ia9a4b250ddd818d2b808ac50aea139064e4e1554
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 88c6b61ff1cfb4013a3523227d91ad11b2892388)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696560

[modify] https://crrev.com/914733d4b0838959f818cf54c7ccd5e230766f22/fs/ext4/move_extent.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/71155c225898a427a6229b0a4ab69f52cafcb086

commit 71155c225898a427a6229b0a4ab69f52cafcb086
Author: Eryu Guan <guaneryu@gmail.com>
Date: Tue Oct 10 21:52:12 2017

UPSTREAM: ext4: don't read blocks from disk after extents being swapped

I notice ext4/307 fails occasionally on ppc64 host, reporting md5
checksum mismatch after moving data from original file to donor file.

The reason is that move_extent_per_page() calls __block_write_begin()
and block_commit_write() to write saved data from original inode blocks
to donor inode blocks, but __block_write_begin() not only maps buffer
heads but also reads block content from disk if the size is not block
size aligned.  At this time the physical block number in mapped buffer
head is pointing to the donor file not the original file, and that
results in reading wrong data to page, which get written to disk in
following block_commit_write call.

This also can be reproduced by the following script on 1k block size ext4
on x86_64 host:

    mnt=/mnt/ext4
    donorfile=$mnt/donor
    testfile=$mnt/testfile
    e4compact=~/xfstests/src/e4compact

    rm -f $donorfile $testfile

    # reserve space for donor file, written by 0xaa and sync to disk to
    # avoid EBUSY on EXT4_IOC_MOVE_EXT
    xfs_io -fc "pwrite -S 0xaa 0 1m" -c "fsync" $donorfile

    # create test file written by 0xbb
    xfs_io -fc "pwrite -S 0xbb 0 1023" -c "fsync" $testfile

    # compute initial md5sum
    md5sum $testfile | tee md5sum.txt
    # drop cache, force e4compact to read data from disk
    echo 3 > /proc/sys/vm/drop_caches

    # test defrag
    echo "$testfile" | $e4compact -i -v -f $donorfile
    # check md5sum
    md5sum -c md5sum.txt

Fix it by creating & mapping buffer heads only but not reading blocks
from disk, because all the data in page is guaranteed to be up-to-date
in mext_page_mkuptodate().

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I73739c30d36caaaabd290cae4e093fa23fdb7894
Cc: stable@vger.kernel.org
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit bcff24887d00bce102e0857d7b0a8c44a40f53d1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696561

[modify] https://crrev.com/71155c225898a427a6229b0a4ab69f52cafcb086/fs/ext4/move_extent.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/72aaaaa26862e16db8054e3fd7abae068b0e9854

commit 72aaaaa26862e16db8054e3fd7abae068b0e9854
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date: Tue Oct 10 21:52:13 2017

UPSTREAM: kernel: Provide READ_ONCE and ASSIGN_ONCE

ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)

Let's provide READ_ONCE/ASSIGN_ONCE that will do all accesses via
scalar types as suggested by Linus Torvalds. Accesses larger than
the machines word size cannot be guaranteed to be atomic. These
macros will use memcpy and emit a build warning.

BUG=chromium:766786
TEST=build/boot samus, xfstest

Change-Id: Ibe0e3119526758b56a1895ef2a619c17344a04bf
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
(cherry picked from commit 230fa253df6352af12ad0a16128760b5cb3f92df)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696562

[modify] https://crrev.com/72aaaaa26862e16db8054e3fd7abae068b0e9854/include/linux/compiler.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9d8ae51b0f0ca3c31d850bcdcbf5a1f2b79a6de2

commit 9d8ae51b0f0ca3c31d850bcdcbf5a1f2b79a6de2
Author: Jan Kara <jack@suse.com>
Date: Tue Oct 10 21:52:14 2017

UPSTREAM: ext4: fix bh->b_state corruption

ext4 can update bh->b_state non-atomically in _ext4_get_block() and
ext4_da_get_block_prep(). Usually this is fine since bh is just a
temporary storage for mapping information on stack but in some cases it
can be fully living bh attached to a page. In such case non-atomic
update of bh->b_state can race with an atomic update which then gets
lost. Usually when we are mapping bh and thus updating bh->b_state
non-atomically, nobody else touches the bh and so things work out fine
but there is one case to especially worry about: ext4_finish_bio() uses
BH_Uptodate_Lock on the first bh in the page to synchronize handling of
PageWriteback state. So when blocksize < pagesize, we can be atomically
modifying bh->b_state of a buffer that actually isn't under IO and thus
can race e.g. with delalloc trying to map that buffer. The result is
that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the
corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock.

Fix the problem by always updating bh->b_state bits atomically.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I94f7c66304aae9119ad35455a18df237d1dc7827
CC: stable@vger.kernel.org
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit ed8ad83808f009ade97ebbf6519bc3a97fefbc0c)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696563

[modify] https://crrev.com/9d8ae51b0f0ca3c31d850bcdcbf5a1f2b79a6de2/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4cb1380602596666327fed3d0019b849aeea70a1

commit 4cb1380602596666327fed3d0019b849aeea70a1
Author: Jan Kara <jack@suse.cz>
Date: Tue Oct 10 21:52:15 2017

UPSTREAM: ext4: fix crashes in dioread_nolock mode

Competing overwrite DIO in dioread_nolock mode will just overwrite
pointer to io_end in the inode. This may result in data corruption or
extent conversion happening from IO completion interrupt because we
don't properly set buffer_defer_completion() when unlocked DIO races
with locked DIO to unwritten extent.

Since unlocked DIO doesn't need io_end for anything, just avoid
allocating it and corrupting pointer from inode for locked DIO.
A cleaner fix would be to avoid these games with io_end pointer from the
inode but that requires more intrusive changes so we leave that for
later.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ie7d8e94ac556eda0ee3afda463c695682e40d42d
Cc: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 74dae4278546b897eb81784fdfcce872ddd8b2b8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696564

[modify] https://crrev.com/4cb1380602596666327fed3d0019b849aeea70a1/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/365cb51c79b4c597aa966b8cc9ff82ad450bb423

commit 365cb51c79b4c597aa966b8cc9ff82ad450bb423
Author: Jan Kara <jack@suse.cz>
Date: Tue Oct 10 21:52:17 2017

UPSTREAM: ext4: shortcut setting of xattr to the same value

When someone tried to set xattr to the same value (i.e., not changing
anything) we did all the work of removing original xattr, possibly
breaking references to shared xattr block, inserting new xattr, and
merging xattr blocks again. Since this is not so rare operation and it
is relatively cheap for us to detect this case, check for this and
shortcut xattr setting in that case.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ie7d5da9efd31221f9c7941cd889cf7aeb0c0f0c9
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 3fd164629d25b04f291a79a013dcc7ce1a301269)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696565

[modify] https://crrev.com/365cb51c79b4c597aa966b8cc9ff82ad450bb423/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bed11c3316169da637f3f3b5e61210dcaa62d02f

commit bed11c3316169da637f3f3b5e61210dcaa62d02f
Author: Eryu Guan <guaneryu@gmail.com>
Date: Tue Oct 10 21:52:18 2017

UPSTREAM: ext4: iterate over buffer heads correctly in move_extent_per_page()

In commit bcff24887d00 ("ext4: don't read blocks from disk after extents
being swapped") bh is not updated correctly in the for loop and wrong
data has been written to disk. generic/324 catches this on sub-page
block size ext4.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I1a02a4990a8cb22f9c31676faa94207752a44665
Fixes: bcff24887d00 ("ext4: don't read blocks from disk after extentsbeing swapped")
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 6ffe77bad545f4a7c8edd2a4ee797ccfcd894ab4)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696566

[modify] https://crrev.com/bed11c3316169da637f3f3b5e61210dcaa62d02f/fs/ext4/move_extent.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/efbf9cf415163e8e5d448886808a103bbe270f61

commit efbf9cf415163e8e5d448886808a103bbe270f61
Author: Eryu Guan <guaneryu@gmail.com>
Date: Tue Oct 10 21:52:19 2017

UPSTREAM: ext4: fix NULL pointer dereference in ext4_mark_inode_dirty()

ext4_reserve_inode_write() in ext4_mark_inode_dirty() could fail on
error (e.g. EIO) and iloc.bh can be NULL in this case. But the error is
ignored in the following "if" condition and ext4_expand_extra_isize()
might be called with NULL iloc.bh set, which triggers NULL pointer
dereference.

This is uncovered by commit 8b4953e13f4c ("ext4: reserve code points for
the project quota feature"), which enlarges the ext4_inode size, and
run the following script on new kernel but with old mke2fs:

  #/bin/bash
  mnt=/mnt/ext4
  devname=ext4-error
  dev=/dev/mapper/$devname
  fsimg=/home/fs.img

  trap cleanup 0 1 2 3 9 15

  cleanup()
  {
          umount $mnt >/dev/null 2>&1
          dmsetup remove $devname
          losetup -d $backend_dev
          rm -f $fsimg
          exit 0
  }

  rm -f $fsimg
  fallocate -l 1g $fsimg
  backend_dev=`losetup -f --show $fsimg`
  devsize=`blockdev --getsz $backend_dev`

  good_tab="0 $devsize linear $backend_dev 0"
  error_tab="0 $devsize error $backend_dev 0"

  dmsetup create $devname --table "$good_tab"

  mkfs -t ext4 $dev
  mount -t ext4 -o errors=continue,strictatime $dev $mnt

  dmsetup load $devname --table "$error_tab" && dmsetup resume $devname
  echo 3 > /proc/sys/vm/drop_caches
  ls -l $mnt
  exit 0

[ Patch changed to simplify the function a tiny bit. -- Ted ]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I489e4027294c558f618c478f4c9104874659fc84
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 5e1021f2b6dff1a86a468a1424d59faae2bc63c1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696567

[modify] https://crrev.com/efbf9cf415163e8e5d448886808a103bbe270f61/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a07612389fe17a328d166b58dfccc5946bcaf20c

commit a07612389fe17a328d166b58dfccc5946bcaf20c
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Tue Oct 10 21:52:20 2017

UPSTREAM: ext4: use __GFP_NOFAIL in ext4_free_blocks()

This might be unexpected but pages allocated for sbi->s_buddy_cache are
charged to current memory cgroup. So, GFP_NOFS allocation could fail if
current task has been killed by OOM or if current memory cgroup has no
free memory left. Block allocator cannot handle such failures here yet.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Id14151e9d69a37b4eea4bc5195aa29f0b321802c
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit adb7ef600cc9d9d15ecc934cc26af5c1379777df)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696568

[modify] https://crrev.com/a07612389fe17a328d166b58dfccc5946bcaf20c/fs/ext4/mballoc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/389052308135e5aa4e9105cc7431b4b21645bc62

commit 389052308135e5aa4e9105cc7431b4b21645bc62
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Tue Oct 10 21:52:21 2017

UPSTREAM: ext4: handle the rest of ext4_mb_load_buddy() ENOMEM errors

I've got another report about breaking ext4 by ENOMEM error returned from
ext4_mb_load_buddy() caused by memory shortage in memory cgroup.
This time inside ext4_discard_preallocations().

This patch replaces ext4_error() with ext4_warning() where errors returned
from ext4_mb_load_buddy() are not fatal and handled by caller:
* ext4_mb_discard_group_preallocations() - called before generating ENOSPC,
  we'll try to discard other group or return ENOSPC into user-space.
* ext4_trim_all_free() - just stop trimming and return ENOMEM from ioctl.

Some callers cannot handle errors, thus __GFP_NOFAIL is used for them:
* ext4_discard_preallocations()
* ext4_mb_discard_lg_preallocations()

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I158a65cdfa4dd00809da69f05888e57c49ed2242
Fixes: adb7ef600cc9 ("ext4: use __GFP_NOFAIL in ext4_free_blocks()")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 9651e6b2e20648d04d5e1fe6479a3056047e8781)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696569

[modify] https://crrev.com/389052308135e5aa4e9105cc7431b4b21645bc62/fs/ext4/mballoc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/633772b1ebe18321e0456bd9cfa5aadc8d3908c0

commit 633772b1ebe18321e0456bd9cfa5aadc8d3908c0
Author: Theodore Ts'o <tytso@mit.edu>
Date: Tue Oct 10 21:52:22 2017

UPSTREAM: FIXUP: BACKPORT: ext4: check if in-inode xattr is corrupted in ext4_expand_extra_isize_ea()

We aren't checking to see if the in-inode extended attribute is
corrupted before we try to expand the inode's extra isize fields.

This can lead to potential crashes caused by the BUG_ON() check in
ext4_xattr_shift_entries().

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ie1abc941c14244052440d15435a181b674af5c38
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 9e92f48c34eb2b9af9d12f892e2fe1fce5e8ce35)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: already got this in 666e91846dbf but now that we have ECORRUPTEDFS we should use it]
Conflicts:
	fs/ext4/xattr.c
Reviewed-on: https://chromium-review.googlesource.com/696570

[modify] https://crrev.com/633772b1ebe18321e0456bd9cfa5aadc8d3908c0/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a983d5f5e55e5f793f796bac4ff95bc06f118da0

commit a983d5f5e55e5f793f796bac4ff95bc06f118da0
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:31 2017

UPSTREAM: ext4: fix hang when processing corrupted orphaned inode list

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

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I8213b1f930d74433121585e7f38643147ffb3c7d
Cc: stable@vger.kernel.org
Reported by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit c9eb13a9105e2e418f72e46a2b6da3f49e696902)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696571

[modify] https://crrev.com/a983d5f5e55e5f793f796bac4ff95bc06f118da0/fs/ext4/ialloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ccdfc4f2be9ecff0a8826f13d161c32abb9c2af7

commit ccdfc4f2be9ecff0a8826f13d161c32abb9c2af7
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:33 2017

UPSTREAM: ext4: clean up error handling when orphan list is corrupted

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.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I2d7ac2f1d8c25b92e3f540d57ccd3e85c06464d5
Cc: stable@vger.kernel.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 7827a7f6ebfcb7f388dc47fddd48567a314701ba)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696572

[modify] https://crrev.com/ccdfc4f2be9ecff0a8826f13d161c32abb9c2af7/fs/ext4/ialloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/128304953f6f94ab7c7ad77bc36214d933f95cdf

commit 128304953f6f94ab7c7ad77bc36214d933f95cdf
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 11 00:39:34 2017

UPSTREAM: ext4: fix oops on corrupted filesystem

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.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ie713361b613ec95e31140afcc5f2b7d33ebee3a7
CC: stable@vger.kernel.org
Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 74177f55b70e2f2be770dd28684dd6d17106a4ba)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696573

[modify] https://crrev.com/128304953f6f94ab7c7ad77bc36214d933f95cdf/fs/ext4/namei.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/06f49bd684a2613dcae2f43454ad92e64d302d67

commit 06f49bd684a2613dcae2f43454ad92e64d302d67
Author: Eryu Guan <guaneryu@gmail.com>
Date: Wed Oct 11 00:39:35 2017

UPSTREAM: ext4: check for zero length extent explicitly

The following commit introduced a bug when checking for zero length extent

5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()

Zero length extent could pass the check if lblock is zero.

Adding the explicit check for zero length back.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I3516f8bcebbb9cc726739297c1088a8043baaa51
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit 2f974865ffdfe7b9f46a9940836c8b167342563d)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696574

[modify] https://crrev.com/06f49bd684a2613dcae2f43454ad92e64d302d67/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9cc8c397e4b73ea56eea2703c4b35624c29472ab

commit 9cc8c397e4b73ea56eea2703c4b35624c29472ab
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Wed Oct 11 00:39:36 2017

UPSTREAM: ext4: check for extents that wrap around

An extent with lblock = 4294967295 and len = 1 will pass the
ext4_valid_extent() test:

	ext4_lblk_t last = lblock + len - 1;

	if (len == 0 || lblock > last)
		return 0;

since last = 4294967295 + 1 - 1 = 4294967295. This would later trigger
the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end().

We can simplify it by removing the - 1 altogether and changing the test
to use lblock + len <= lblock, since now if len = 0, then lblock + 0 ==
lblock and it fails, and if len > 0 then lblock + len > lblock in order
to pass (i.e. it doesn't overflow).

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I5060a305db893724929b183fc2d4f49bc80fbc59
Fixes: 5946d0893 ("ext4: check for overlapping extents in ext4_valid_extent_entries()")
Fixes: 2f974865f ("ext4: check for zero length extent explicitly")
Cc: Eryu Guan <guaneryu@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit f70749ca42943faa4d4dcce46dfdcaadb1d0c4b6)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696575

[modify] https://crrev.com/9cc8c397e4b73ea56eea2703c4b35624c29472ab/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/88a73c9c85239882c5be9fbbd09afc2de4163119

commit 88a73c9c85239882c5be9fbbd09afc2de4163119
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Wed Oct 11 00:39:37 2017

UPSTREAM: ext4: don't call ext4_should_journal_data() on the journal inode

If ext4_fill_super() fails early, it's possible for ext4_evict_inode()
to call ext4_should_journal_data() before superblock options and flags
are fully set up.  In that case, the iput() on the journal inode can
end up causing a BUG().

Work around this problem by reordering the tests so we only call
ext4_should_journal_data() after we know it's not the journal inode.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I66b4086dbeabe6aba1e37223c3fe650435e169b3
Fixes: 2d859db3e4 ("ext4: fix data corruption in inodes with journalled data")
Fixes: 2b405bfa84 ("ext4: fix data=journal fast mount/umount hang")
Cc: Jan Kara <jack@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
(cherry picked from commit 6a7fd522a7c94cdef0a3b08acf8e6702056e635c)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696576

[modify] https://crrev.com/88a73c9c85239882c5be9fbbd09afc2de4163119/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/102ed435b60afbc2df2b72f495c7717ff5565052

commit 102ed435b60afbc2df2b72f495c7717ff5565052
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Wed Oct 11 00:39:38 2017

UPSTREAM: ext4: fix reference counting bug on block allocation error

If we hit this error when mounted with errors=continue or
errors=remount-ro:

    EXT4-fs error (device loop0): ext4_mb_mark_diskspace_used:2940: comm ext4.exe: Allocating blocks 5090-6081 which overlap fs metadata

then ext4_mb_new_blocks() will call ext4_mb_release_context() and try to
continue. However, ext4_mb_release_context() is the wrong thing to call
here since we are still actually using the allocation context.

Instead, just error out. We could retry the allocation, but there is a
possibility of getting stuck in an infinite loop instead, so this seems
safer.

[ Fixed up so we don't return EAGAIN to userspace. --tytso ]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I4e0888e3e8cbd8e770347eab5d7330da6430e5e3
Fixes: 8556e8f3b6 ("ext4: Don't allow new groups to be added during block allocation")
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 554a5ccc4e4a20c5f3ec859de0842db4b4b9c77e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696577

[modify] https://crrev.com/102ed435b60afbc2df2b72f495c7717ff5565052/fs/ext4/mballoc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/db76800fef69e42a0c71f3f90bd146d73a99cac5

commit db76800fef69e42a0c71f3f90bd146d73a99cac5
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Wed Oct 11 00:39:39 2017

UPSTREAM: ext4: short-cut orphan cleanup on error

If we encounter a filesystem error during orphan cleanup, we should stop.
Otherwise, we may end up in an infinite loop where the same inode is
processed again and again.

    EXT4-fs (loop0): warning: checktime reached, running e2fsck is recommended
    EXT4-fs error (device loop0): ext4_mb_generate_buddy:758: group 2, block bitmap and bg descriptor inconsistent: 6117 vs 0 free clusters
    Aborting journal on device loop0-8.
    EXT4-fs (loop0): Remounting filesystem read-only
    EXT4-fs error (device loop0) in ext4_free_blocks:4895: Journal has aborted
    EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
    EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
    EXT4-fs error (device loop0) in ext4_ext_remove_space:3068: IO failure
    EXT4-fs error (device loop0) in ext4_ext_truncate:4667: Journal has aborted
    EXT4-fs error (device loop0) in ext4_orphan_del:2927: Journal has aborted
    EXT4-fs error (device loop0) in ext4_do_update_inode:4893: Journal has aborted
    EXT4-fs (loop0): Inode 16 (00000000618192a0): orphan list check failed!
    [...]
    EXT4-fs (loop0): Inode 16 (0000000061819748): orphan list check failed!
    [...]
    EXT4-fs (loop0): Inode 16 (0000000061819bf0): orphan list check failed!
    [...]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I0254bae1c4dea0627b5ba02d80827a23a013e69c
See-also: c9eb13a9105 ("ext4: fix hang when processing corrupted orphaned inode list")
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit c65d5c6c81a1f27dec5f627f67840726fcd146de)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696578

[modify] https://crrev.com/db76800fef69e42a0c71f3f90bd146d73a99cac5/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/910dbdac8449acb17a899a45ee9c64abf9f3e695

commit 910dbdac8449acb17a899a45ee9c64abf9f3e695
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:40 2017

UPSTREAM: ext4: validate that metadata blocks do not overlap superblock

A number of fuzzing failures seem to be caused by allocation bitmaps
or other metadata blocks being pointed at the superblock.

This can cause kernel BUG or WARNings once the superblock is
overwritten, so validate the group descriptor blocks to make sure this
doesn't happen.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I1b9830be5e940f44ef535ca67cf95c9ca7c7d795
Cc: stable@vger.kernel.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 829fa70dddadf9dd041d62b82cd7cea63943899d)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696579

[modify] https://crrev.com/910dbdac8449acb17a899a45ee9c64abf9f3e695/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/99dd12d93a5b3dc73ad344fa06d6bd8fb6004de3

commit 99dd12d93a5b3dc73ad344fa06d6bd8fb6004de3
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 11 00:39:41 2017

UPSTREAM: ext4: fix xattr shifting when expanding inodes

The code in ext4_expand_extra_isize_ea() treated new_extra_isize
argument sometimes as the desired target i_extra_isize and sometimes as
the amount by which we need to grow current i_extra_isize. These happen
to coincide when i_extra_isize is 0 which used to be the common case and
so nobody noticed this until recently when we added i_projid to the
inode and so i_extra_isize now needs to grow from 28 to 32 bytes.

The result of these bugs was that we sometimes unnecessarily decided to
move xattrs out of inode even if there was enough space and we often
ended up corrupting in-inode xattrs because arguments to
ext4_xattr_shift_entries() were just wrong. This could demonstrate
itself as BUG_ON in ext4_xattr_shift_entries() triggering.

Fix the problem by introducing new isize_diff variable and use it where
appropriate.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Iaaa3845afe6b74b44d5fcad92bb8f07464428196
CC: stable@vger.kernel.org   # 4.4.x
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit d0141191a20289f8955c1e03dad08e42e6f71ca9)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696580

[modify] https://crrev.com/99dd12d93a5b3dc73ad344fa06d6bd8fb6004de3/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2294999ff8073dbf8929a6d322a85d0354439a66

commit 2294999ff8073dbf8929a6d322a85d0354439a66
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 11 00:39:43 2017

UPSTREAM: ext4: fix xattr shifting when expanding inodes part 2

When multiple xattrs need to be moved out of inode, we did not properly
recompute total size of xattr headers in the inode and the new header
position. Thus when moving the second and further xattr we asked
ext4_xattr_shift_entries() to move too much and from the wrong place,
resulting in possible xattr value corruption or general memory
corruption.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I0bb1fd60d1e1736668abe18912c85817ecae614b
CC: stable@vger.kernel.org  # 4.4.x
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 418c12d08dc64a45107c467ec1ba29b5e69b0715)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696581

[modify] https://crrev.com/2294999ff8073dbf8929a6d322a85d0354439a66/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/eff58fe44c9aab8c95e761900025aa57fb3e5126

commit eff58fe44c9aab8c95e761900025aa57fb3e5126
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 11 00:39:44 2017

UPSTREAM: ext4: properly align shifted xattrs when expanding inodes

We did not count with the padding of xattr value when computing desired
shift of xattrs in the inode when expanding i_extra_isize. As a result
we could create unaligned start of inline xattrs. Account for alignment
properly.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ia1a92a238989f9d268e6d2343c5b6d2a7b080aab
CC: stable@vger.kernel.org  # 4.4.x-
Signed-off-by: Jan Kara <jack@suse.cz>
(cherry picked from commit 443a8c41cd49de66a3fda45b32b9860ea0292b84)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696582

[modify] https://crrev.com/eff58fe44c9aab8c95e761900025aa57fb3e5126/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dab9813ad88c360bf63b7696d9456def2167c6f1

commit dab9813ad88c360bf63b7696d9456def2167c6f1
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 11 00:39:45 2017

UPSTREAM: ext4: avoid deadlock when expanding inode size

When we need to move xattrs into external xattr block, we call
ext4_xattr_block_set() from ext4_expand_extra_isize_ea(). That may end
up calling ext4_mark_inode_dirty() again which will recurse back into
the inode expansion code leading to deadlocks.

Protect from recursion using EXT4_STATE_NO_EXPAND inode flag and move
its management into ext4_expand_extra_isize_ea() since its manipulation
is safe there (due to xattr_sem) from possible races with
ext4_xattr_set_handle() which plays with it as well.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I4ee4c08c7dd4dd8028cce99a037f9ef3e0e93dff
CC: stable@vger.kernel.org   # 4.4.x
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 2e81a4eeedcaa66e35f58b81e0755b87057ce392)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696583

[modify] https://crrev.com/dab9813ad88c360bf63b7696d9456def2167c6f1/fs/ext4/inode.c
[modify] https://crrev.com/dab9813ad88c360bf63b7696d9456def2167c6f1/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8edad47049adc7aae4799997fc60dbb55e937652

commit 8edad47049adc7aae4799997fc60dbb55e937652
Author: Daeho Jeong <daeho.jeong@samsung.com>
Date: Wed Oct 11 00:39:46 2017

UPSTREAM: ext4: reinforce check of i_dtime when clearing high fields of uid and gid

Now, ext4_do_update_inode() clears high 16-bit fields of uid/gid
of deleted and evicted inode to fix up interoperability with old
kernels. However, it checks only i_dtime of an inode to determine
whether the inode was deleted and evicted, and this is very risky,
because i_dtime can be used for the pointer maintaining orphan inode
list, too. We need to further check whether the i_dtime is being
used for the orphan inode list even if the i_dtime is not NULL.

We found that high 16-bit fields of uid/gid of inode are unintentionally
and permanently cleared when the inode truncation is just triggered,
but not finished, and the inode metadata, whose high uid/gid bits are
cleared, is written on disk, and the sudden power-off follows that
in order.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I3373630b49b5986808506171b8e0bc03fb4eedc4
Cc: stable@vger.kernel.org
Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
Signed-off-by: Hobin Woo <hobin.woo@samsung.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 93e3b4e6631d2a74a8cf7429138096862ff9f452)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696584

[modify] https://crrev.com/8edad47049adc7aae4799997fc60dbb55e937652/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/21f06fff7e0b3690083e3c59f57efe08181e7aff

commit 21f06fff7e0b3690083e3c59f57efe08181e7aff
Author: wangguang <wang.guang55@zte.com.cn>
Date: Wed Oct 11 00:39:47 2017

BACKPORT: ext4: bugfix for mmaped pages in mpage_release_unused_pages()

Pages clear buffers after ext4 delayed block allocation failed,
However, it does not clean its pte_dirty flag.
if the pages unmap ,in cording to the pte_dirty ,
unmap_page_range may try to call __set_page_dirty,

which may lead to the bugon at
mpage_prepare_extent_to_map:head = page_buffers(page);.

This patch just call clear_page_dirty_for_io to clean pte_dirty
at mpage_release_unused_pages for pages mmaped.

Steps to reproduce the bug:

1 mmap a file in ext4
	addr = (char *)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED,
	       	            fd, 0);
	memset(addr, 'i', 4096);

2 return EIO at

	ext4_writepages->mpage_map_and_submit_extent->mpage_map_one_extent

which causes this log message to be print:

                ext4_msg(sb, KERN_CRIT,
                        "Delayed block allocation failed for "
                        "inode %lu at logical offset %llu with"
                        " max blocks %u with error %d",
                        inode->i_ino,
                        (unsigned long long)map->m_lblk,
                        (unsigned)map->m_len, -err);

(3Unmap the addr cause warning at

	__set_page_dirty:WARN_ON_ONCE(warn && !PageUptodate(page));

(4) wait for a minute,then bugon happen.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I6dcccfd3366a7053c0d35884fafd3d28dcfbbbcb
Cc: stable@vger.kernel.org
Signed-off-by: wangguang <wangguang03@zte.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 4e800c0359d9a53e6bf0ab216954971b2515247f)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: we don't have 09cbfeaf1a5a so use PAGE_CACHE_SIZE as before]
Conflicts:
	fs/ext4/inode.c
Reviewed-on: https://chromium-review.googlesource.com/696585
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/21f06fff7e0b3690083e3c59f57efe08181e7aff/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9e612914623f8c6c52b71f2502a0774e643352e8

commit 9e612914623f8c6c52b71f2502a0774e643352e8
Author: gmail <yngsion@gmail.com>
Date: Wed Oct 11 00:39:48 2017

UPSTREAM: ext4: release bh in make_indexed_dir

The commit 6050d47adcad: "ext4: bail out from make_indexed_dir() on
first error" could end up leaking bh2 in the error path.

[ Also avoid renaming bh2 to bh, which just confuses things --tytso ]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ie10062fe9f906d08a5912c15074164ca23bf2639
Cc: stable@vger.kernel.org
Signed-off-by: yangsheng <yngsion@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit e81d44778d1d57bbaef9e24c4eac7c8a7a401d40)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696586

[modify] https://crrev.com/9e612914623f8c6c52b71f2502a0774e643352e8/fs/ext4/namei.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c31aad3a2eb63686bca49fa702adc41864abd392

commit c31aad3a2eb63686bca49fa702adc41864abd392
Author: Richard Weinberger <richard@nod.at>
Date: Wed Oct 11 00:39:49 2017

UPSTREAM: ext4: require encryption feature for EXT4_IOC_SET_ENCRYPTION_POLICY

...otherwise an user can enable encryption for certain files even
when the filesystem is unable to support it.
Such a case would be a filesystem created by mkfs.ext4's default
settings, 1KiB block size. Ext4 supports encyption only when block size
is equal to PAGE_SIZE.
But this constraint is only checked when the encryption feature flag
is set.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I024aa0cf758c73ad74291325af465bcf19669e32
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 9a200d075e5d05be1fcad4547a0f8aee4e2f9a04)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696587

[modify] https://crrev.com/c31aad3a2eb63686bca49fa702adc41864abd392/fs/ext4/ioctl.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6692a9655bebd4f5226f051577cd4518ab6b6ffe

commit 6692a9655bebd4f5226f051577cd4518ab6b6ffe
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:50 2017

UPSTREAM: ext4: sanity check the block and cluster size at mount time

If the block size or cluster size is insane, reject the mount.  This
is important for security reasons (although we shouldn't be just
depending on this check).

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ife140b52f0539a6def897444a19493300d7bab9b
Ref: http://www.securityfocus.com/archive/1/539661
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506
Reported-by: Borislav Petkov <bp@alien8.de>
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit 9e47a4c9fc58032ee135bf76516809c7624b1551)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696588

[modify] https://crrev.com/6692a9655bebd4f5226f051577cd4518ab6b6ffe/fs/ext4/super.c
[modify] https://crrev.com/6692a9655bebd4f5226f051577cd4518ab6b6ffe/fs/ext4/ext4.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0422da849006600afb19e97a180a7a225b19b8e9

commit 0422da849006600afb19e97a180a7a225b19b8e9
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:51 2017

UPSTREAM: ext4: ratelimit the file system mounted message

The xfstests ext4/305 will mount and unmount the same file system over
4,000 times, and each one of these will cause a system log message.
Ratelimit this message since if we are getting more than a few dozen
of these messages, they probably aren't going to be helpful.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I739b925906bea9092cc740e05e46d69271055caf
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit e294a5371b2e0bd22d4a917d4c354a52a7057b6e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696589

[modify] https://crrev.com/0422da849006600afb19e97a180a7a225b19b8e9/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9b8fd4089639ec9fd803efa0b416d35d97178fa0

commit 9b8fd4089639ec9fd803efa0b416d35d97178fa0
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:53 2017

UPSTREAM: ext4: fix in-superblock mount options processing

Fix a large number of problems with how we handle mount options in the
superblock.  For one, if the string in the superblock is long enough
that it is not null terminated, we could run off the end of the string
and try to interpret superblocks fields as characters.  It's unlikely
this will cause a security problem, but it could result in an invalid
parse.  Also, parse_options is destructive to the string, so in some
cases if there is a comma-separated string, it would be modified in
the superblock.  (Fortunately it only happens on file systems with a
1k block size.)

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I76635c14bb25da1ca80bb83c873d32b1faadf215
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit 5aee0f8a3f42c94c5012f1673420aee96315925a)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696590

[modify] https://crrev.com/9b8fd4089639ec9fd803efa0b416d35d97178fa0/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/34d955ce9ca21b30d7cc9cce57e4616b0319cb80

commit 34d955ce9ca21b30d7cc9cce57e4616b0319cb80
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:54 2017

UPSTREAM: ext4: use more strict checks for inodes_per_block on mount

Centralize the checks for inodes_per_block and be more strict to make
sure the inodes_per_block_group can't end up being zero.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I3c855c335cd8aad8d458d986fd9ca5d84e108d4f
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Cc: stable@vger.kernel.org
(cherry picked from commit cd6bb35bf7f6d7d922509bf50265383a0ceabe96)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696591

[modify] https://crrev.com/34d955ce9ca21b30d7cc9cce57e4616b0319cb80/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/458d13b895b4636c82981e5a35be58dafbb7152f

commit 458d13b895b4636c82981e5a35be58dafbb7152f
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Oct 11 00:39:55 2017

UPSTREAM: ext4: add sanity checking to count_overhead()

The commit "ext4: sanity check the block and cluster size at mount
time" should prevent any problems, but in case the superblock is
modified while the file system is mounted, add an extra safety check
to make sure we won't overrun the allocated buffer.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I6e5f1e8af1fd61fadfdc4b42740e87ff092934d0
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit c48ae41bafe31e9a66d8be2ced4e42a6b57fa814)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696592

[modify] https://crrev.com/458d13b895b4636c82981e5a35be58dafbb7152f/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3efa0156b504d77859f3dfee18923d0a9f8372bc

commit 3efa0156b504d77859f3dfee18923d0a9f8372bc
Author: Eric Biggers <ebiggers@google.com>
Date: Wed Oct 11 00:39:56 2017

UPSTREAM: ext4: forbid i_extra_isize not divisible by 4

i_extra_isize not divisible by 4 is problematic for several reasons:

- It causes the in-inode xattr space to be misaligned, but the xattr
  header and entries are not declared __packed to express this
  possibility.  This may cause poor performance or incorrect code
  generation on some platforms.
- When validating the xattr entries we can read past the end of the
  inode if the size available for xattrs is not a multiple of 4.
- It allows the nonsensical i_extra_isize=1, which doesn't even leave
  enough room for i_extra_isize itself.

Therefore, update ext4_iget() to consider i_extra_isize not divisible by
4 to be an error, like the case where i_extra_isize is too large.

This also matches the rule recently added to e2fsck for determining
whether an inode has valid i_extra_isize.

This patch shouldn't have any noticeable effect on
non-corrupted/non-malicious filesystems, since the size of ext4_inode
has always been a multiple of 4.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: If08d46e04044087aa266dc8d2a82a4de19965001
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
(cherry picked from commit 2dc8d9e19b0d891b0d3675b5ac82be9be3875e36)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696593

[modify] https://crrev.com/3efa0156b504d77859f3dfee18923d0a9f8372bc/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/754a8d2a8fe17aba97dcd2a0b1e9b4d2413fe546

commit 754a8d2a8fe17aba97dcd2a0b1e9b4d2413fe546
Author: Eric Biggers <ebiggers@google.com>
Date: Wed Oct 11 00:39:57 2017

UPSTREAM: ext4: correct endianness conversion in __xattr_check_inode()

It should be cpu_to_le32(), not le32_to_cpu().  No change in behavior.

Found with sparse, and this was the only endianness warning in fs/ext4/.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Id84e323eae6adcee5009ae76267d4c28ce746e85
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
(cherry picked from commit 199625098a18a5522b424dea9b122b254c022fc5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696594

[modify] https://crrev.com/754a8d2a8fe17aba97dcd2a0b1e9b4d2413fe546/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bbf810ebd11776a2faa33dfe4eb40c39efd8abc5

commit bbf810ebd11776a2faa33dfe4eb40c39efd8abc5
Author: Eric Biggers <ebiggers@google.com>
Date: Wed Oct 11 00:39:58 2017

UPSTREAM: ext4: don't read out of bounds when checking for in-inode xattrs

With i_extra_isize equal to or close to the available space, it was
possible for us to read past the end of the inode when trying to detect
or validate in-inode xattrs.  Fix this by checking for the needed extra
space first.

This patch shouldn't have any noticeable effect on
non-corrupted/non-malicious filesystems.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I50ac2d4afa0be82f6e5491bcf0eedcf97819abe7
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
(cherry picked from commit 290ab230016f187c3551d8380ea742889276d03a)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696595

[modify] https://crrev.com/bbf810ebd11776a2faa33dfe4eb40c39efd8abc5/fs/ext4/inode.c
[modify] https://crrev.com/bbf810ebd11776a2faa33dfe4eb40c39efd8abc5/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f0ac1133cc7c99b6557dfd2c31c5cefe34256d46

commit f0ac1133cc7c99b6557dfd2c31c5cefe34256d46
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 11 00:39:59 2017

UPSTREAM: ext4: Check that external xattr value block is zero

Currently we don't support xattrs with values stored out of line. Check
for that in ext4_xattr_check_names() to make sure we never work with
such xattrs since not all the code counts with that resulting is possible
weird corruption issues.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I1bbfaa584a76eee60496313d7bbfa59196a65a55
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 2de58f1102cf1ac6091209e1dfa8eccbcb039570)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696596

[modify] https://crrev.com/f0ac1133cc7c99b6557dfd2c31c5cefe34256d46/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/316aea00ba1da7236e4c0bea9199b06c5f1826ce

commit 316aea00ba1da7236e4c0bea9199b06c5f1826ce
Author: Eric Biggers <ebiggers@google.com>
Date: Wed Oct 11 05:13:39 2017

UPSTREAM: ext4: correctly detect when an xattr value has an invalid size

It was possible for an xattr value to have a very large size, which
would then pass validation on 32-bit architectures due to a pointer
wraparound.  Fix this by validating the size in a way which avoids
pointer wraparound.

It was also possible that a value's size would fit in the available
space but its padded size would not.  This would cause an out-of-bounds
memory write in ext4_xattr_set_entry when replacing the xattr value.
For example, if an xattr value of unpadded size 253 bytes went until the
very end of the inode or block, then using setxattr(2) to replace this
xattr's value with 256 bytes would cause a write to the 3 bytes past the
end of the inode or buffer, and the new xattr value would be incorrectly
truncated.  Fix this by requiring that the padded size fit in the
available space rather than the unpadded size.

This patch shouldn't have any noticeable effect on
non-corrupted/non-malicious filesystems.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I7743742338a4ddbb171d6042c6cdaf02f702f8b8
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit d7614cc16146e3f0b4c33e71875c19607602aed5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696597

[modify] https://crrev.com/316aea00ba1da7236e4c0bea9199b06c5f1826ce/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1e03034e388eb374c1564ff7e1aa40617c13da3b

commit 1e03034e388eb374c1564ff7e1aa40617c13da3b
Author: Eryu Guan <guaneryu@gmail.com>
Date: Wed Oct 11 05:13:40 2017

UPSTREAM: ext4: validate s_first_meta_bg at mount time

Ralf Spenneberg reported that he hit a kernel crash when mounting a
modified ext4 image. And it turns out that kernel crashed when
calculating fs overhead (ext4_calculate_overhead()), this is because
the image has very large s_first_meta_bg (debug code shows it's
842150400), and ext4 overruns the memory in count_overhead() when
setting bitmap buffer, which is PAGE_SIZE.

ext4_calculate_overhead():
  buf = get_zeroed_page(GFP_NOFS);  <=== PAGE_SIZE buffer
  blks = count_overhead(sb, i, buf);

count_overhead():
  for (j = ext4_bg_num_gdb(sb, grp); j > 0; j--) { <=== j = 842150400
          ext4_set_bit(EXT4_B2C(sbi, s++), buf);   <=== buffer overrun
          count++;
  }

This can be reproduced easily for me by this script:

  #!/bin/bash
  rm -f fs.img
  mkdir -p /mnt/ext4
  fallocate -l 16M fs.img
  mke2fs -t ext4 -O bigalloc,meta_bg,^resize_inode -F fs.img
  debugfs -w -R "ssv first_meta_bg 842150400" fs.img
  mount -o loop fs.img /mnt/ext4

Fix it by validating s_first_meta_bg first at mount time, and
refusing to mount if its value exceeds the largest possible meta_bg
number.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I4cf6f8925a65b1a743873d1d985d348a381ca895
Reported-by: Ralf Spenneberg <ralf@os-t.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
(cherry picked from commit 3a4b77cd47bb837b8557595ec7425f281f2ca1fe)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696598

[modify] https://crrev.com/1e03034e388eb374c1564ff7e1aa40617c13da3b/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dc10d3677dd2bf75d1d28b5af500d9a55741abdd

commit dc10d3677dd2bf75d1d28b5af500d9a55741abdd
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date: Wed Oct 11 05:13:41 2017

UPSTREAM: ext4: reject inodes with negative size

Don't load an inode with a negative size; this causes integer overflow
problems in the VFS.

[ Added EXT4_ERROR_INODE() to mark file system as corrupted. -TYT]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ifef579b5f30c506b2b2d293d88308de1db5c81a0
Fixes: a48380f769df (ext4: rename i_dir_acl to i_size_high)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
(cherry picked from commit 7e6e1ef48fc02f3ac5d0edecbb0c6087cd758d58)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696599

[modify] https://crrev.com/dc10d3677dd2bf75d1d28b5af500d9a55741abdd/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/66bfeb35de82350fc48facb338b1a23f9a56ccf7

commit 66bfeb35de82350fc48facb338b1a23f9a56ccf7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed Oct 11 05:13:43 2017

UPSTREAM: ext4: return -ENOMEM instead of success

We should set the error code if kzalloc() fails.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I1d053cac98305a19369286355a7db31a246f4622
Fixes: 67cf5b09a46f ("ext4: add the basic function for inline data support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit 578620f451f836389424833f1454eeeb2ffc9e9f)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696600

[modify] https://crrev.com/66bfeb35de82350fc48facb338b1a23f9a56ccf7/fs/ext4/inline.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a6abf748af24c4820d4705a1cf7c8e621db5aeba

commit a6abf748af24c4820d4705a1cf7c8e621db5aeba
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Oct 12 03:44:20 2017

UPSTREAM: ext4: fix deadlock between inline_data and ext4_expand_extra_isize_ea()

The xattr_sem deadlock problems fixed in commit 2e81a4eeedca: "ext4:
avoid deadlock when expanding inode size" didn't include the use of
xattr_sem in fs/ext4/inline.c.  With the addition of project quota
which added a new extra inode field, this exposed deadlocks in the
inline_data code similar to the ones fixed by 2e81a4eeedca.

The deadlock can be reproduced via:

   dmesg -n 7
   mke2fs -t ext4 -O inline_data -Fq -I 256 /dev/vdc 32768
   mount -t ext4 -o debug_want_extra_isize=24 /dev/vdc /vdc
   mkdir /vdc/a
   umount /vdc
   mount -t ext4 /dev/vdc /vdc
   echo foo > /vdc/a/foo

and looks like this:

[   11.158815]
[   11.160276] =============================================
[   11.161960] [ INFO: possible recursive locking detected ]
[   11.161960] 4.10.0-rc3-00015-g011b30a8a3cf #160 Tainted: G        W
[   11.161960] ---------------------------------------------
[   11.161960] bash/2519 is trying to acquire lock:
[   11.161960]  (&ei->xattr_sem){++++..}, at: [<c1225a4b>] ext4_expand_extra_isize_ea+0x3d/0x4cd
[   11.161960]
[   11.161960] but task is already holding lock:
[   11.161960]  (&ei->xattr_sem){++++..}, at: [<c1227941>] ext4_try_add_inline_entry+0x3a/0x152
[   11.161960]
[   11.161960] other info that might help us debug this:
[   11.161960]  Possible unsafe locking scenario:
[   11.161960]
[   11.161960]        CPU0
[   11.161960]        ----
[   11.161960]   lock(&ei->xattr_sem);
[   11.161960]   lock(&ei->xattr_sem);
[   11.161960]
[   11.161960]  *** DEADLOCK ***
[   11.161960]
[   11.161960]  May be due to missing lock nesting notation
[   11.161960]
[   11.161960] 4 locks held by bash/2519:
[   11.161960]  #0:  (sb_writers#3){.+.+.+}, at: [<c11a2414>] mnt_want_write+0x1e/0x3e
[   11.161960]  #1:  (&type->i_mutex_dir_key){++++++}, at: [<c119508b>] path_openat+0x338/0x67a
[   11.161960]  #2:  (jbd2_handle){++++..}, at: [<c123314a>] start_this_handle+0x582/0x622
[   11.161960]  #3:  (&ei->xattr_sem){++++..}, at: [<c1227941>] ext4_try_add_inline_entry+0x3a/0x152
[   11.161960]
[   11.161960] stack backtrace:
[   11.161960] CPU: 0 PID: 2519 Comm: bash Tainted: G        W       4.10.0-rc3-00015-g011b30a8a3cf #160
[   11.161960] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1 04/01/2014
[   11.161960] Call Trace:
[   11.161960]  dump_stack+0x72/0xa3
[   11.161960]  __lock_acquire+0xb7c/0xcb9
[   11.161960]  ? kvm_clock_read+0x1f/0x29
[   11.161960]  ? __lock_is_held+0x36/0x66
[   11.161960]  ? __lock_is_held+0x36/0x66
[   11.161960]  lock_acquire+0x106/0x18a
[   11.161960]  ? ext4_expand_extra_isize_ea+0x3d/0x4cd
[   11.161960]  down_write+0x39/0x72
[   11.161960]  ? ext4_expand_extra_isize_ea+0x3d/0x4cd
[   11.161960]  ext4_expand_extra_isize_ea+0x3d/0x4cd
[   11.161960]  ? _raw_read_unlock+0x22/0x2c
[   11.161960]  ? jbd2_journal_extend+0x1e2/0x262
[   11.161960]  ? __ext4_journal_get_write_access+0x3d/0x60
[   11.161960]  ext4_mark_inode_dirty+0x17d/0x26d
[   11.161960]  ? ext4_add_dirent_to_inline.isra.12+0xa5/0xb2
[   11.161960]  ext4_add_dirent_to_inline.isra.12+0xa5/0xb2
[   11.161960]  ext4_try_add_inline_entry+0x69/0x152
[   11.161960]  ext4_add_entry+0xa3/0x848
[   11.161960]  ? __brelse+0x14/0x2f
[   11.161960]  ? _raw_spin_unlock_irqrestore+0x44/0x4f
[   11.161960]  ext4_add_nondir+0x17/0x5b
[   11.161960]  ext4_create+0xcf/0x133
[   11.161960]  ? ext4_mknod+0x12f/0x12f
[   11.161960]  lookup_open+0x39e/0x3fb
[   11.161960]  ? __wake_up+0x1a/0x40
[   11.161960]  ? lock_acquire+0x11e/0x18a
[   11.161960]  path_openat+0x35c/0x67a
[   11.161960]  ? sched_clock_cpu+0xd7/0xf2
[   11.161960]  do_filp_open+0x36/0x7c
[   11.161960]  ? _raw_spin_unlock+0x22/0x2c
[   11.161960]  ? __alloc_fd+0x169/0x173
[   11.161960]  do_sys_open+0x59/0xcc
[   11.161960]  SyS_open+0x1d/0x1f
[   11.161960]  do_int80_syscall_32+0x4f/0x61
[   11.161960]  entry_INT80_32+0x2f/0x2f
[   11.161960] EIP: 0xb76ad469
[   11.161960] EFLAGS: 00000286 CPU: 0
[   11.161960] EAX: ffffffda EBX: 08168ac8 ECX: 00008241 EDX: 000001b6
[   11.161960] ESI: b75e46bc EDI: b7755000 EBP: bfbdb108 ESP: bfbdafc0
[   11.161960]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I5be9727380617c28d145a0c09010f3d51b2b02cb
Cc: stable@vger.kernel.org # 3.10 (requires 2e81a4eeedca as a prereq)
Reported-by: George Spelvin <linux@sciencehorizons.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit c755e251357a0cee0679081f08c3f4ba797a8009)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696602

[modify] https://crrev.com/a6abf748af24c4820d4705a1cf7c8e621db5aeba/fs/ext4/inline.c
[modify] https://crrev.com/a6abf748af24c4820d4705a1cf7c8e621db5aeba/fs/ext4/xattr.c
[modify] https://crrev.com/a6abf748af24c4820d4705a1cf7c8e621db5aeba/fs/ext4/xattr.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/357b9c9f673289cf882ff0641cff56d3c4207f55

commit 357b9c9f673289cf882ff0641cff56d3c4207f55
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 12 03:44:21 2017

UPSTREAM: ext4: trim allocation requests to group size

If filesystem groups are artifically small (using parameter -g to
mkfs.ext4), ext4_mb_normalize_request() can result in a request that is
larger than a block group. Trim the request size to not confuse
allocation code.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ia17fb67f3342d6569f82e094c5697a8cb93f3eed
Reported-by: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit cd648b8a8fd5071d232242d5ee7ee3c0815776af)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696603

[modify] https://crrev.com/357b9c9f673289cf882ff0641cff56d3c4207f55/fs/ext4/mballoc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/03b0fdfd2fb60eb9231fa0f6f49eeb4fc596d298

commit 03b0fdfd2fb60eb9231fa0f6f49eeb4fc596d298
Author: Eric Biggers <ebiggers@google.com>
Date: Thu Oct 12 03:44:22 2017

BACKPORT: ext4: fix use-after-iput when fscrypt contexts are inconsistent

In the case where the child's encryption context was inconsistent with
its parent directory, we were using inode->i_sb and inode->i_ino after
the inode had already been iput().  Fix this by doing the iput() in the
correct places.

Note: only ext4 had this bug, not f2fs and ubifs.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I9ef7aab69a5a002980bf4d2518575ef17da19f45
Fixes: d9cdc9033181 ("ext4 crypto: enforce context consistency")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit dd01b690f8f4b1e414f89e5a9a5326bf720d6652)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: context differences]
 Conflicts:
	fs/ext4/namei.c
Reviewed-on: https://chromium-review.googlesource.com/696604
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/03b0fdfd2fb60eb9231fa0f6f49eeb4fc596d298/fs/ext4/namei.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/722236177407461fcd2934b624402fd3435cfcb8

commit 722236177407461fcd2934b624402fd3435cfcb8
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Oct 12 03:44:23 2017

UPSTREAM: ext4: fix fencepost in s_first_meta_bg validation

It is OK for s_first_meta_bg to be equal to the number of block group
descriptor blocks.  (It rarely happens, but it shouldn't cause any
problems.)

https://bugzilla.kernel.org/show_bug.cgi?id=194567

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ifd74def583f8d8f2147d4262ef675199793480ba
Fixes: 3a4b77cd47bb837b8557595ec7425f281f2ca1fe
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit 2ba3e6e8afc9b6188b471f27cf2b5e3cf34e7af2)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696605

[modify] https://crrev.com/722236177407461fcd2934b624402fd3435cfcb8/fs/ext4/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/97370e37dd701a9796482804a7ab7f648d0fd16a

commit 97370e37dd701a9796482804a7ab7f648d0fd16a
Author: Eric Biggers <ebiggers@google.com>
Date: Thu Oct 12 03:44:24 2017

UPSTREAM: ext4: mark inode dirty after converting inline directory

If ext4_convert_inline_data() was called on a directory with inline
data, the filesystem was left in an inconsistent state (as considered by
e2fsck) because the file size was not increased to cover the new block.
This happened because the inode was not marked dirty after i_disksize
was updated.  Fix this by marking the inode dirty at the end of
ext4_finish_convert_inline_dir().

This bug was probably not noticed before because most users mark the
inode dirty afterwards for other reasons.  But if userspace executed
FS_IOC_SET_ENCRYPTION_POLICY with invalid parameters, as exercised by
'kvm-xfstests -c adv generic/396', then the inode was never marked dirty
after updating i_disksize.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I2308e535fc6080aa290a65a33b6b8a0977314079
Cc: stable@vger.kernel.org  # 3.10+
Fixes: 3c47d54170b6a678875566b1b8d6dcf57904e49b
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit b9cf625d6ecde0d372e23ae022feead72b4228a6)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696606

[modify] https://crrev.com/97370e37dd701a9796482804a7ab7f648d0fd16a/fs/ext4/inline.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8d41181ed15f2a3999eda1f95980156c5a4c80bd

commit 8d41181ed15f2a3999eda1f95980156c5a4c80bd
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Oct 12 03:44:25 2017

BACKPORT: ext4: lock the xattr block before checksuming it

We must lock the xattr block before calculating or verifying the
checksum in order to avoid spurious checksum failures.

https://bugzilla.kernel.org/show_bug.cgi?id=193661

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I36c30689c2f1d04cf1e3d8468bca28582474bb7b
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit dac7a4b4b1f664934e8b713f529b629f67db313c)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: trivial context]
 Conflicts:
	fs/ext4/xattr.c
Reviewed-on: https://chromium-review.googlesource.com/696607

[modify] https://crrev.com/8d41181ed15f2a3999eda1f95980156c5a4c80bd/fs/ext4/xattr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/def5314208164fe9f7279b96ba3f6e856299100b

commit def5314208164fe9f7279b96ba3f6e856299100b
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Oct 12 03:44:26 2017

UPSTREAM: ext4: fix an ext3 collapse range regression in xfstests

The xfstests test suite assumes that an attempt to collapse range on
the range (0, 1) will return EOPNOTSUPP if the file system does not
support collapse range.  Commit 280227a75b56: "ext4: move check under
lock scope to close a race" broke this, and this caused xfstests to
fail when run when testing file systems that did not have the extents
feature enabled.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I04cffbdb4cd5b23ade3961939dcf62a2fb263386
Reported-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit b9576fc3624eb9fc88bec0d0ae883fd78be86239)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696608

[modify] https://crrev.com/def5314208164fe9f7279b96ba3f6e856299100b/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a749aaa832e205617d8be3cd9858f9768e1e9d6c

commit a749aaa832e205617d8be3cd9858f9768e1e9d6c
Author: Jan Kara <jack@suse.com>
Date: Thu Oct 12 03:44:28 2017

BACKPORT: ext4: fix races between page faults and hole punching

Currently, page faults and hole punching are completely unsynchronized.
This can result in page fault faulting in a page into a range that we
are punching after truncate_pagecache_range() has been called and thus
we can end up with a page mapped to disk blocks that will be shortly
freed. Filesystem corruption will shortly follow. Note that the same
race is avoided for truncate by checking page fault offset against
i_size but there isn't similar mechanism available for punching holes.

Fix the problem by creating new rw semaphore i_mmap_sem in inode and
grab it for writing over truncate, hole punching, and other functions
removing blocks from extent tree and for read over page faults. We
cannot easily use i_data_sem for this since that ranks below transaction
start and we need something ranking above it so that it can be held over
the whole truncate / hole punching operation. Also remove various
workarounds we had in the code to reduce race window when page fault
could have created pages with stale mapping information.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I7fb59b75c747757c55629b41767211eee510c7f7
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit ea3d7209ca01da209cda6f0dea8be9cc4b7a933b)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: context conflicts from not having DAX, ext4_insert, fallocate]
 Conflicts:
	fs/ext4/extents.c
	fs/ext4/file.c
	fs/ext4/inode.c
[SR: 3.14 context conflict from 2b8cd9bfe1fbc - Android interface
 patch]
 Conflicts:
	fs/ext4/file.c
Reviewed-on: https://chromium-review.googlesource.com/696609

[modify] https://crrev.com/a749aaa832e205617d8be3cd9858f9768e1e9d6c/fs/ext4/extents.c
[modify] https://crrev.com/a749aaa832e205617d8be3cd9858f9768e1e9d6c/fs/ext4/ext4.h
[modify] https://crrev.com/a749aaa832e205617d8be3cd9858f9768e1e9d6c/fs/ext4/inode.c
[modify] https://crrev.com/a749aaa832e205617d8be3cd9858f9768e1e9d6c/fs/ext4/truncate.h
[modify] https://crrev.com/a749aaa832e205617d8be3cd9858f9768e1e9d6c/fs/ext4/super.c
[modify] https://crrev.com/a749aaa832e205617d8be3cd9858f9768e1e9d6c/fs/ext4/file.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/418ac5d11284fd2a98ceea01852e70ba52ff68a0

commit 418ac5d11284fd2a98ceea01852e70ba52ff68a0
Author: Jan Kara <jack@suse.com>
Date: Thu Oct 12 03:44:30 2017

UPSTREAM: ext4: fix races of writeback with punch hole and zero range

commit 011278485ecc3cd2a3954b5d4c73101d919bf1fa upstream.

When doing delayed allocation, update of on-disk inode size is postponed
until IO submission time. However hole punch or zero range fallocate
calls can end up discarding the tail page cache page and thus on-disk
inode size would never be properly updated.

Make sure the on-disk inode size is updated before truncating page
cache.

BUG=chromium:766786
TEST=build/boot samus, xfstests generic/033 passes

Change-Id: I16ecab8dce985b77512cf896858bb9c52d435263
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 21228341bf17496062b0e6a1b37265f6bcf5c8f3)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696610

[modify] https://crrev.com/418ac5d11284fd2a98ceea01852e70ba52ff68a0/fs/ext4/extents.c
[modify] https://crrev.com/418ac5d11284fd2a98ceea01852e70ba52ff68a0/fs/ext4/ext4.h
[modify] https://crrev.com/418ac5d11284fd2a98ceea01852e70ba52ff68a0/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9ab2883963cbec6b7d2488f3f69f9fd7c808c306

commit 9ab2883963cbec6b7d2488f3f69f9fd7c808c306
Author: Lukas Czerner <lczerner@redhat.com>
Date: Thu Oct 12 03:44:27 2017

UPSTREAM: ext4: allocate entire range in zero range

Currently there is a bug in zero range code which causes zero range
calls to only allocate block aligned portion of the range, while
ignoring the rest in some cases.

In some cases, namely if the end of the range is past i_size, we do
attempt to preallocate the last nonaligned block. However this might
cause kernel to BUG() in some carefully designed zero range requests
on setups where page size > block size.

Fix this problem by first preallocating the entire range, including
the nonaligned edges and converting the written extents to unwritten
in the next step. This approach will also give us the advantage of
having the range to be as linearly contiguous as possible.

BUG=chromium:766786
TEST=build/boot samus, xfstests

Change-Id: I009c94e41f13f7dd87d041dba9f59e753ed17033
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 0f2af21aae11972fa924374ddcf52e88347cf5a8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696611

[modify] https://crrev.com/9ab2883963cbec6b7d2488f3f69f9fd7c808c306/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/67ee8816302f08a008ae4c3a5b0d1a7aab959126

commit 67ee8816302f08a008ae4c3a5b0d1a7aab959126
Author: Eric Biggers <ebiggers@google.com>
Date: Thu Oct 12 03:44:31 2017

UPSTREAM: ext4: evict inline data when writing to memory map

Currently the case of writing via mmap to a file with inline data is not
handled.  This is maybe a rare case since it requires a writable memory
map of a very small file, but it is trivial to trigger with on
inline_data filesystem, and it causes the
'BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));' in
ext4_writepages() to be hit:

    mkfs.ext4 -O inline_data /dev/vdb
    mount /dev/vdb /mnt
    xfs_io -f /mnt/file \
	-c 'pwrite 0 1' \
	-c 'mmap -w 0 1m' \
	-c 'mwrite 0 1' \
	-c 'fsync'

	kernel BUG at fs/ext4/inode.c:2723!
	invalid opcode: 0000 [#1] SMP
	CPU: 1 PID: 2532 Comm: xfs_io Not tainted 4.11.0-rc1-xfstests-00301-g071d9acf3d1f #633
	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
	task: ffff88003d3a8040 task.stack: ffffc90000300000
	RIP: 0010:ext4_writepages+0xc89/0xf8a
	RSP: 0018:ffffc90000303ca0 EFLAGS: 00010283
	RAX: 0000028410000000 RBX: ffff8800383fa3b0 RCX: ffffffff812afcdc
	RDX: 00000a9d00000246 RSI: ffffffff81e660e0 RDI: 0000000000000246
	RBP: ffffc90000303dc0 R08: 0000000000000002 R09: 869618e8f99b4fa5
	R10: 00000000852287a2 R11: 00000000a03b49f4 R12: ffff88003808e698
	R13: 0000000000000000 R14: 7fffffffffffffff R15: 7fffffffffffffff
	FS:  00007fd3e53094c0(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 00007fd3e4c51000 CR3: 000000003d554000 CR4: 00000000003406e0
	Call Trace:
	 ? _raw_spin_unlock+0x27/0x2a
	 ? kvm_clock_read+0x1e/0x20
	 do_writepages+0x23/0x2c
	 ? do_writepages+0x23/0x2c
	 __filemap_fdatawrite_range+0x80/0x87
	 filemap_write_and_wait_range+0x67/0x8c
	 ext4_sync_file+0x20e/0x472
	 vfs_fsync_range+0x8e/0x9f
	 ? syscall_trace_enter+0x25b/0x2d0
	 vfs_fsync+0x1c/0x1e
	 do_fsync+0x31/0x4a
	 SyS_fsync+0x10/0x14
	 do_syscall_64+0x69/0x131
	 entry_SYSCALL64_slow_path+0x25/0x25

We could try to be smart and keep the inline data in this case, or at
least support delayed allocation when allocating the block, but these
solutions would be more complicated and don't seem worthwhile given how
rare this case seems to be.  So just fix the bug by calling
ext4_convert_inline_data() when we're asked to make a page writable, so
that any inline data gets evicted, with the block allocated immediately.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Icaf5757bca7135bff66b1623dbee6e879630ca21
Reported-by: Nick Alcock <nick.alcock@oracle.com>
Cc: stable@vger.kernel.org
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 7b4cc9787fe35b3ee2dfb1c35e22eafc32e00c33)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696612

[modify] https://crrev.com/67ee8816302f08a008ae4c3a5b0d1a7aab959126/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/24e5499254998483aff6b19b33ef6930b65a47d4

commit 24e5499254998483aff6b19b33ef6930b65a47d4
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 12 03:44:32 2017

UPSTREAM: ext4: fix SEEK_HOLE

Currently, SEEK_HOLE implementation in ext4 may both return that there's
a hole at some offset although that offset already has data and skip
some holes during a search for the next hole. The first problem is
demostrated by:

xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "seek -h 0" file
wrote 57344/57344 bytes at offset 0
56 KiB, 14 ops; 0.0000 sec (2.054 GiB/sec and 538461.5385 ops/sec)
Whence	Result
HOLE	0

Where we can see that SEEK_HOLE wrongly returned offset 0 as containing
a hole although we have written data there. The second problem can be
demonstrated by:

xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
       -c "seek -h 0" file

wrote 57344/57344 bytes at offset 0
56 KiB, 14 ops; 0.0000 sec (1.978 GiB/sec and 518518.5185 ops/sec)
wrote 8192/8192 bytes at offset 131072
8 KiB, 2 ops; 0.0000 sec (2 GiB/sec and 500000.0000 ops/sec)
Whence	Result
HOLE	139264

Where we can see that hole at offsets 56k..128k has been ignored by the
SEEK_HOLE call.

The underlying problem is in the ext4_find_unwritten_pgoff() which is
just buggy. In some cases it fails to update returned offset when it
finds a hole (when no pages are found or when the first found page has
higher index than expected), in some cases conditions for detecting hole
are just missing (we fail to detect a situation where indices of
returned pages are not contiguous).

Fix ext4_find_unwritten_pgoff() to properly detect non-contiguous page
indices and also handle all cases where we got less pages then expected
in one place and handle it properly there.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I0e75fdd292c085ddeedd33b15bfb465335a64424
CC: stable@vger.kernel.org
Fixes: c8c0df241cc2719b1262e627f999638411934f60
CC: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 7d95eddf313c88b24f99d4ca9c2411a4b82fef33)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696613

[modify] https://crrev.com/24e5499254998483aff6b19b33ef6930b65a47d4/fs/ext4/file.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f80555ff7467a3df74473957c23dfa72e6d91a27

commit f80555ff7467a3df74473957c23dfa72e6d91a27
Author: Andy Leiserson <andy@leiserson.org>
Date: Thu Oct 12 03:44:33 2017

UPSTREAM: [PATCH] fix calculation of meta_bg descriptor backups

"group" is the group where the backup will be placed, and is
initialized to zero in the declaration. This meant that backups for
meta_bg descriptors were erroneously written to the backup block group
descriptors in groups 1 and (desc_per_block-1).

Reproduction information:
  mke2fs -Fq -t ext4 -b 1024 -O ^resize_inode /tmp/foo.img 16G
  truncate -s 24G /tmp/foo.img
  losetup /dev/loop0 /tmp/foo.img
  mount /dev/loop0 /mnt
  resize2fs /dev/loop0
  umount /dev/loop0
  dd if=/dev/zero of=/dev/loop0 bs=1024 count=2
  e2fsck -fy /dev/loop0
  losetup -d /dev/loop0

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Iab941588d0b9e6365268532160ce856a48349d9e
Signed-off-by: Andy Leiserson <andy@leiserson.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit 904dad4742d211b7a8910e92695c0fa957483836
 from v3.16.48)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696614

[modify] https://crrev.com/f80555ff7467a3df74473957c23dfa72e6d91a27/fs/ext4/resize.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/37a2d6410c36d4c94c38b8bb8cb610753cc9dc43

commit 37a2d6410c36d4c94c38b8bb8cb610753cc9dc43
Author: Daeho Jeong <daeho.jeong@samsung.com>
Date: Thu Oct 12 03:44:34 2017

UPSTREAM: ext4: fix xfstest generic/269 double revoked buffer bug with bigalloc

When you repeatly execute xfstest generic/269 with bigalloc_1k option
enabled using the below command:

"./kvm-xfstests -c bigalloc_1k -m nodelalloc -C 1000 generic/269"

you can easily see the below bug message.

"JBD2 unexpected failure: jbd2_journal_revoke: !buffer_revoked(bh);"

This means that an already revoked buffer is erroneously revoked again
and it is caused by doing revoke for the buffer at the wrong position
in ext4_free_blocks(). We need to re-position the buffer revoke
procedure for an unspecified buffer after checking the cluster boundary
for bigalloc option. If not, some part of the cluster can be doubly
revoked.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I4015d3f734d03fc02118f487e2ce2360e1c99dd9
Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
(cherry picked from commit 9c02ac97989d544c89f049e8add7149aaea01671)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696615

[modify] https://crrev.com/37a2d6410c36d4c94c38b8bb8cb610753cc9dc43/fs/ext4/mballoc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/102181ceeea3a5667fd6fa2e95b21c1b56f984a5

commit 102181ceeea3a5667fd6fa2e95b21c1b56f984a5
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 12 03:44:35 2017

BACKPORT: ext4: fix off-by-in in loop termination in ext4_find_unwritten_pgoff()

There is an off-by-one error in loop termination conditions in
ext4_find_unwritten_pgoff() since 'end' may index a page beyond end of
desired range if 'endoff' is page aligned. It doesn't have any visible
effects but still it is good to fix it.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ieb977ab3bb04f9b837aad2e5acbdcde0d09b9750
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 3f1d5bad3fae983da07be01cff2fde13293bb7b9)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: context from not having 09cbfeaf1a5a6]
 Conflicts:
	fs/ext4/file.c
Reviewed-on: https://chromium-review.googlesource.com/696616
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/102181ceeea3a5667fd6fa2e95b21c1b56f984a5/fs/ext4/file.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9d3fb8951ec61a753f093086e7fccdfba5aced8c

commit 9d3fb8951ec61a753f093086e7fccdfba5aced8c
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Thu Oct 12 03:44:36 2017

UPSTREAM: ext4: keep existing extra fields when inode expands

ext4_expand_extra_isize() should clear only space between old and new
size.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I86ccce18a76baef67b0af9ad252fd08f1e50f9a6
Fixes: 6dd4ee7cab7e # v2.6.23
Cc: stable@vger.kernel.org
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 887a9730614727c4fff7cb756711b190593fc1df)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696617

[modify] https://crrev.com/9d3fb8951ec61a753f093086e7fccdfba5aced8c/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dc3b35233aadf489e3685c69e1913cafce66f981

commit dc3b35233aadf489e3685c69e1913cafce66f981
Author: Eric Biggers <ebiggers@google.com>
Date: Thu Oct 12 03:44:37 2017

UPSTREAM: ext4: remove unused d_name argument from ext4_search_dir() et al.

Now that we are passing a struct ext4_filename, we do not need to pass
around the original struct qstr too.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ia00bb11d68d70d48e629786584eb10e8205423af
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
(cherry picked from commit d6b975504e7e71fc29fcd14530433e816d7f5aac)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696618

[modify] https://crrev.com/dc3b35233aadf489e3685c69e1913cafce66f981/fs/ext4/inline.c
[modify] https://crrev.com/dc3b35233aadf489e3685c69e1913cafce66f981/fs/ext4/ext4.h
[modify] https://crrev.com/dc3b35233aadf489e3685c69e1913cafce66f981/fs/ext4/namei.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b604a25488048fcc706106959578ef376239b705

commit b604a25488048fcc706106959578ef376239b705
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 12 03:44:39 2017

UPSTREAM: ext4: fix data corruption with EXT4_GET_BLOCKS_ZERO

When ext4_map_blocks() is called with EXT4_GET_BLOCKS_ZERO to zero-out
allocated blocks and these blocks are actually converted from unwritten
extent the following race can happen:

CPU0					CPU1

page fault				page fault
...					...
ext4_map_blocks()
  ext4_ext_map_blocks()
    ext4_ext_handle_unwritten_extents()
      ext4_ext_convert_to_initialized()
	- zero out converted extent
	ext4_zeroout_es()
	  - inserts extent as initialized in status tree

					ext4_map_blocks()
					  ext4_es_lookup_extent()
					    - finds initialized extent
					write data
  ext4_issue_zeroout()
    - zeroes out new extent overwriting data

This problem can be reproduced by generic/340 for the fallocated case
for the last block in the file.

Fix the problem by avoiding zeroing out the area we are mapping with
ext4_map_blocks() in ext4_ext_convert_to_initialized(). It is pointless
to zero out this area in the first place as the caller asked us to
convert the area to initialized because he is just going to write data
there before the transaction finishes. To achieve this we delete the
special case of zeroing out full extent as that will be handled by the
cases below zeroing only the part of the extent that needs it. We also
instruct ext4_split_extent() that the middle of extent being split
contains data so that ext4_split_extent_at() cannot zero out full extent
in case of ENOSPC.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ifa02069e316ba3f4372eba79f00373d9ccfd9212
CC: stable@vger.kernel.org
Fixes: 12735f881952c32b31bc4e433768f18489f79ec9
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 4f8caa60a5a13a78f26198618f21774bd6aa6498)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696619

[modify] https://crrev.com/b604a25488048fcc706106959578ef376239b705/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d0d06db784ed7bbfff24dcabc991f7d4f8d15542

commit d0d06db784ed7bbfff24dcabc991f7d4f8d15542
Author: Oleg Nesterov <oleg@redhat.com>
Date: Thu Oct 12 03:44:40 2017

UPSTREAM: fs/super.c: fix race between freeze_super() and thaw_super()

Change thaw_super() to check frozen != SB_FREEZE_COMPLETE rather than
frozen == SB_UNFROZEN, otherwise it can race with freeze_super() which
drops sb->s_umount after SB_FREEZE_WRITE to preserve the lock ordering.

In this case thaw_super() will wrongly call s_op->unfreeze_fs() before
it was actually frozen, and call sb_freeze_unlock() which leads to the
unbalanced percpu_up_write(). Unfortunately lockdep can't detect this,
so this triggers misc BUG_ON()'s in kernel/rcu/sync.c.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I54c212639cbfc791e5765cf4fd7a320cdaecf317
Reported-and-tested-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 89f39af129382a40d7cd1f6914617282cfeee28e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696620

[modify] https://crrev.com/d0d06db784ed7bbfff24dcabc991f7d4f8d15542/fs/super.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e3f8b7fb47fab2dbcc5b639033d8a5a4165ba33d

commit e3f8b7fb47fab2dbcc5b639033d8a5a4165ba33d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Thu Oct 12 03:44:41 2017

UPSTREAM: smarter propagate_mnt()

The current mainline has copies propagated to *all* nodes, then
tears down the copies we made for nodes that do not contain
counterparts of the desired mountpoint.  That sets the right
propagation graph for the copies (at teardown time we move
the slaves of removed node to a surviving peer or directly
to master), but we end up paying a fairly steep price in
useless allocations.  It's fairly easy to create a situation
where N calls of mount(2) create exactly N bindings, with
O(N^2) vfsmounts allocated and freed in process.

Fortunately, it is possible to avoid those allocations/freeings.
The trick is to create copies in the right order and find which
one would've eventually become a master with the current algorithm.
It turns out to be possible in O(nodes getting propagation) time
and with no extra allocations at all.

One part is that we need to make sure that eventual master will be
created before its slaves, so we need to walk the propagation
tree in a different order - by peer groups.  And iterate through
the peers before dealing with the next group.

Another thing is finding the (earlier) copy that will be a master
of one we are about to create; to do that we are (temporary) marking
the masters of mountpoints we are attaching the copies to.

Either we are in a peer of the last mountpoint we'd dealt with,
or we have the following situation: we are attaching to mountpoint M,
the last copy S_0 had been attached to M_0 and there are sequences
S_0...S_n, M_0...M_n such that S_{i+1} is a master of S_{i},
S_{i} mounted on M{i} and we need to create a slave of the first S_{k}
such that M is getting propagation from M_{k}.  It means that the master
of M_{k} will be among the sequence of masters of M.  On the
other hand, the nearest marked node in that sequence will either
be the master of M_{k} or the master of M_{k-1} (the latter -
in the case if M_{k-1} is a slave of something M gets propagation
from, but in a wrong peer group).

So we go through the sequence of masters of M until we find
a marked one (P).  Let N be the one before it.  Then we go through
the sequence of masters of S_0 until we find one (say, S) mounted
on a node D that has P as master and check if D is a peer of N.
If it is, S will be the master of new copy, if not - the master of S
will be.

That's it for the hard part; the rest is fairly simple.  Iterator
is in next_group(), handling of one prospective mountpoint is
propagate_one().

It seems to survive all tests and gives a noticably better performance
than the current mainline for setups that are seriously using shared
subtrees.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Id6b65624db417c2f0747080216fabb777805c8ff
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit f2ebb3a921c1ca1e2ddd9242e95a1989a50c4c68)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696621

[modify] https://crrev.com/e3f8b7fb47fab2dbcc5b639033d8a5a4165ba33d/fs/pnode.h
[modify] https://crrev.com/e3f8b7fb47fab2dbcc5b639033d8a5a4165ba33d/fs/namespace.c
[modify] https://crrev.com/e3f8b7fb47fab2dbcc5b639033d8a5a4165ba33d/fs/pnode.c
[modify] https://crrev.com/e3f8b7fb47fab2dbcc5b639033d8a5a4165ba33d/include/linux/mount.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6fb36756c161284b00c37ae267453920172c29dd

commit 6fb36756c161284b00c37ae267453920172c29dd
Author: Maxim Patlasov <mpatlasov@virtuozzo.com>
Date: Thu Oct 12 03:44:42 2017

UPSTREAM: fs/pnode.c: treat zero mnt_group_id-s as unequal

propagate_one(m) calculates "type" argument for copy_tree() like this:

>    if (m->mnt_group_id == last_dest->mnt_group_id) {
>        type = CL_MAKE_SHARED;
>    } else {
>        type = CL_SLAVE;
>        if (IS_MNT_SHARED(m))
>           type |= CL_MAKE_SHARED;
>   }

The "type" argument then governs clone_mnt() behavior with respect to flags
and mnt_master of new mount. When we iterate through a slave group, it is
possible that both current "m" and "last_dest" are not shared (although,
both are slaves, i.e. have non-NULL mnt_master-s). Then the comparison
above erroneously makes new mount shared and sets its mnt_master to
last_source->mnt_master. The patch fixes the problem by handling zero
mnt_group_id-s as though they are unequal.

The similar problem exists in the implementation of "else" clause above
when we have to ascend upward in the master/slave tree by calling:

>    last_source = last_source->mnt_master;
>    last_dest = last_source->mnt_parent;

proper number of times. The last step is governed by
"n->mnt_group_id != last_dest->mnt_group_id" condition that may lie if
both are zero. The patch fixes this case in the same way as the former one.

[AV: don't open-code an obvious helper...]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I74d7dbbc58de0e0a78be32d2922465ae467311d1
Signed-off-by: Maxim Patlasov <mpatlasov@virtuozzo.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 7ae8fd0351f912b075149a1e03a017be8b903b9a)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696622

[modify] https://crrev.com/6fb36756c161284b00c37ae267453920172c29dd/fs/pnode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8f5ebf51da882b806ebff8004fd93e8ca5532025

commit 8f5ebf51da882b806ebff8004fd93e8ca5532025
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Thu Oct 12 03:44:43 2017

UPSTREAM: propogate_mnt: Handle the first propogated copy being a slave

When the first propgated copy was a slave the following oops would result:
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> IP: [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
> PGD bacd4067 PUD bac66067 PMD 0
> Oops: 0000 [#1] SMP
> Modules linked in:
> CPU: 1 PID: 824 Comm: mount Not tainted 4.6.0-rc5userns+ #1523
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> task: ffff8800bb0a8000 ti: ffff8800bac3c000 task.ti: ffff8800bac3c000
> RIP: 0010:[<ffffffff811fba4e>]  [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
> RSP: 0018:ffff8800bac3fd38  EFLAGS: 00010283
> RAX: 0000000000000000 RBX: ffff8800bb77ec00 RCX: 0000000000000010
> RDX: 0000000000000000 RSI: ffff8800bb58c000 RDI: ffff8800bb58c480
> RBP: ffff8800bac3fd48 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000001ca1 R11: 0000000000001c9d R12: 0000000000000000
> R13: ffff8800ba713800 R14: ffff8800bac3fda0 R15: ffff8800bb77ec00
> FS:  00007f3c0cd9b7e0(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000010 CR3: 00000000bb79d000 CR4: 00000000000006e0
> Stack:
>  ffff8800bb77ec00 0000000000000000 ffff8800bac3fd88 ffffffff811fbf85
>  ffff8800bac3fd98 ffff8800bb77f080 ffff8800ba713800 ffff8800bb262b40
>  0000000000000000 0000000000000000 ffff8800bac3fdd8 ffffffff811f1da0
> Call Trace:
>  [<ffffffff811fbf85>] propagate_mnt+0x105/0x140
>  [<ffffffff811f1da0>] attach_recursive_mnt+0x120/0x1e0
>  [<ffffffff811f1ec3>] graft_tree+0x63/0x70
>  [<ffffffff811f1f6b>] do_add_mount+0x9b/0x100
>  [<ffffffff811f2c1a>] do_mount+0x2aa/0xdf0
>  [<ffffffff8117efbe>] ? strndup_user+0x4e/0x70
>  [<ffffffff811f3a45>] SyS_mount+0x75/0xc0
>  [<ffffffff8100242b>] do_syscall_64+0x4b/0xa0
>  [<ffffffff81988f3c>] entry_SYSCALL64_slow_path+0x25/0x25
> Code: 00 00 75 ec 48 89 0d 02 22 22 01 8b 89 10 01 00 00 48 89 05 fd 21 22 01 39 8e 10 01 00 00 0f 84 e0 00 00 00 48 8b 80 d8 00 00 00 <48> 8b 50 10 48 89 05 df 21 22 01 48 89 15 d0 21 22 01 8b 53 30
> RIP  [<ffffffff811fba4e>] propagate_one+0xbe/0x1c0
>  RSP <ffff8800bac3fd38>
> CR2: 0000000000000010
> ---[ end trace 2725ecd95164f217 ]---

This oops happens with the namespace_sem held and can be triggered by
non-root users.  An all around not pleasant experience.

To avoid this scenario when finding the appropriate source mount to
copy stop the walk up the mnt_master chain when the first source mount
is encountered.

Further rewrite the walk up the last_source mnt_master chain so that
it is clear what is going on.

The reason why the first source mount is special is that it it's
mnt_parent is not a mount in the dest_mnt propagation tree, and as
such termination conditions based up on the dest_mnt mount propgation
tree do not make sense.

To avoid other kinds of confusion last_dest is not changed when
computing last_source.  last_dest is only used once in propagate_one
and that is above the point of the code being modified, so changing
the global variable is meaningless and confusing.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ia20a4ec7624856ef6f350e370b27cf0381830277
Cc: stable@vger.kernel.org
fixes: f2ebb3a921c1ca1e2ddd9242e95a1989a50c4c68 ("smarter propagate_mnt()")
Reported-by: Tycho Andersen <tycho.andersen@canonical.com>
Reviewed-by: Seth Forshee <seth.forshee@canonical.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 5ec0811d30378ae104f250bfc9b3640242d81e3f)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696623

[modify] https://crrev.com/8f5ebf51da882b806ebff8004fd93e8ca5532025/fs/pnode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/31d6470fd4ec14e3643479c33cf9d44b5b65fac7

commit 31d6470fd4ec14e3643479c33cf9d44b5b65fac7
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Oct 12 03:44:44 2017

UPSTREAM: ext4: use private version of page_zero_new_buffers() for data=journal mode

commit b90197b655185a11640cce3a0a0bc5d8291b8ad2 upstream.

If there is a error while copying data from userspace into the page
cache during a write(2) system call, in data=journal mode, in
ext4_journalled_write_end() were using page_zero_new_buffers() from
fs/buffer.c.  Unfortunately, this sets the buffer dirty flag, which is
no good if journalling is enabled.  This is a long-standing bug that
goes back for years and years in ext3, but a combination of (a)
data=journal not being very common, (b) in many case it only results
in a warning message. and (c) only very rarely causes the kernel hang,
means that we only really noticed this as a problem when commit
998ef75ddb caused this failure to happen frequently enough to cause
generic/208 to fail when run in data=journal mode.

The fix is to have our own version of this function that doesn't call
mark_dirty_buffer(), since we will end up calling
ext4_handle_dirty_metadata() on the buffer head(s) in questions very
shortly afterwards in ext4_journalled_write_end().

Thanks to Dave Hansen and Linus Torvalds for helping to identify the
root cause of the problem.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I9309bff07aded1e0dc2c7272461aa422ad2cb71f
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit dabb07246427d46ece1a68a02e0e67fbb46e53fa
 from 3.16 stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696624

[modify] https://crrev.com/31d6470fd4ec14e3643479c33cf9d44b5b65fac7/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/757dcb929b86b4f8d0c822bfde15b695c0ca20f2

commit 757dcb929b86b4f8d0c822bfde15b695c0ca20f2
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 12 03:44:45 2017

UPSTREAM: ext4: fix data corruption in data=journal mode

commit 3b136499e906460919f0d21a49db1aaccf0ae963 upstream.

ext4_journalled_write_end() did not propely handle all the cases when
generic_perform_write() did not copy all the data into the target page
and could mark buffers with uninitialized contents as uptodate and dirty
leading to possible data corruption (which would be quickly fixed by
generic_perform_write() retrying the write but still). Fix the problem
by carefully handling the case when the page that is written to is not
uptodate.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I4cde4c18ea797ab84900412da68c6b9be6735347
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 324b4fb18d8b08633fa109e9a9d4aba44af2ddb8
 from 3.16 stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696625

[modify] https://crrev.com/757dcb929b86b4f8d0c822bfde15b695c0ca20f2/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fea2c7d74e68e7a3076546b1138c3ab1672b7bb2

commit fea2c7d74e68e7a3076546b1138c3ab1672b7bb2
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Oct 12 03:44:46 2017

UPSTREAM: ext4: fix inline data error paths

The write_end() function must always unlock the page and drop its ref
count, even on an error.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I30b048440743ee03b0940ba9ea220821b56b0e14
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696626

[modify] https://crrev.com/fea2c7d74e68e7a3076546b1138c3ab1672b7bb2/fs/ext4/inline.c
[modify] https://crrev.com/fea2c7d74e68e7a3076546b1138c3ab1672b7bb2/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5e5abf5a1fb197dad40d2c42fceb241eae117720

commit 5e5abf5a1fb197dad40d2c42fceb241eae117720
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 12 03:44:47 2017

BACKPORT: ext4: fix data corruption for mmap writes

mpage_submit_page() can race with another process growing i_size and
writing data via mmap to the written-back page. As mpage_submit_page()
samples i_size too early, it may happen that ext4_bio_write_page()
zeroes out too large tail of the page and thus corrupts user data.

Fix the problem by sampling i_size only after the page has been
write-protected in page tables by clear_page_dirty_for_io() call.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I7e081dcfd80d2cfb902963a1f232eae106cdf5dc
Reported-by: Michael Zimmer <michael@swarm64.com>
CC: stable@vger.kernel.org
Fixes: cb20d5188366f04d96d2e07b1240cc92170ade40
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit a056bdaae7a181f7dcc876cfab2f94538e508709)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: context from not having 09cbfeaf1a]
 Conflicts:
	fs/ext4/inode.c
Reviewed-on: https://chromium-review.googlesource.com/696627
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/5e5abf5a1fb197dad40d2c42fceb241eae117720/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/aee8964cbe8568ea15c8a202319b59b637a9bcfe

commit aee8964cbe8568ea15c8a202319b59b637a9bcfe
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 12 03:44:48 2017

UPSTREAM: ext4: fix fdatasync(2) after extent manipulation operations

commit 67a7d5f561f469ad2fa5154d2888258ab8e6df7c upstream.

Currently, extent manipulation operations such as hole punch, range
zeroing, or extent shifting do not record the fact that file data has
changed and thus fdatasync(2) has a work to do. As a result if we crash
e.g. after a punch hole and fdatasync, user can still possibly see the
punched out data after journal replay. Test generic/392 fails due to
these problems.

Fix the problem by properly marking that file data has changed in these
operations.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I97cad1806196acd21e841adee66d2a4384a0b238
Fixes: a4bb6b64e39abc0e41ca077725f2a72c868e7622
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
[bwh: Backported to 3.16: drop change in ext4_insert_range()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 51390ed9d18cb696767e8096d51a72fd866a36f1
 from 3.16 stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696628

[modify] https://crrev.com/aee8964cbe8568ea15c8a202319b59b637a9bcfe/fs/ext4/extents.c
[modify] https://crrev.com/aee8964cbe8568ea15c8a202319b59b637a9bcfe/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8fe059e72e2523a9eb5b6e9ddbc50f49b8fdbcb8

commit 8fe059e72e2523a9eb5b6e9ddbc50f49b8fdbcb8
Author: David Turner <novalis@novalis.org>
Date: Thu Oct 12 03:44:50 2017

UPSTREAM: ext4: Fix handling of extended tv_sec

In ext4, the bottom two bits of {a,c,m}time_extra are used to extend
the {a,c,m}time fields, deferring the year 2038 problem to the year
2446.

When decoding these extended fields, for times whose bottom 32 bits
would represent a negative number, sign extension causes the 64-bit
extended timestamp to be negative as well, which is not what's
intended.  This patch corrects that issue, so that the only negative
{a,c,m}times are those between 1901 and 1970 (as per 32-bit signed
timestamps).

Some older kernels might have written pre-1970 dates with 1,1 in the
extra bits.  This patch treats those incorrectly-encoded dates as
pre-1970, instead of post-2311, until kernel 4.20 is released.
Hopefully by then e2fsck will have fixed up the bad data.

Also add a comment explaining the encoding of ext4's extra {a,c,m}time
bits.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I4331643d256c413fcb70d9330edb9d693f9fef51
Signed-off-by: David Turner <novalis@novalis.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Mark Harris <mh8928@yahoo.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23732
Cc: stable@vger.kernel.org
(cherry picked from commit a4dad1ae24f850410c4e60f22823cba1289b8d52)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696629

[modify] https://crrev.com/8fe059e72e2523a9eb5b6e9ddbc50f49b8fdbcb8/fs/ext4/ext4.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3e3a21fc26fde5db7c891da3d05e34a3f3f07748

commit 3e3a21fc26fde5db7c891da3d05e34a3f3f07748
Author: Eryu Guan <guaneryu@gmail.com>
Date: Thu Oct 12 03:44:54 2017

UPSTREAM: ext4: be more strict when migrating to non-extent based file

Currently the check in ext4_ind_migrate() is not enough before doing the
real conversion:

a) delayed allocated extents could bypass the check on eh->eh_entries
   and eh->eh_depth

This can be demonstrated by this script

  xfs_io -fc "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/ext4/testfile
  chattr -e /mnt/ext4/testfile

where testfile has two extents but still be converted to non-extent
based file format.

b) only extent length is checked but not the offset, which would result
   in data lose (delalloc) or fs corruption (nodelalloc), because
   non-extent based file only supports at most (12 + 2^10 + 2^20 + 2^30)
   blocks

This can be demostrated by

  xfs_io -fc "pwrite 5T 4k" /mnt/ext4/testfile
  chattr -e /mnt/ext4/testfile
  sync

If delalloc is enabled, dmesg prints
  EXT4-fs warning (device dm-4): ext4_block_to_path:105: block 1342177280 > max in inode 53
  EXT4-fs (dm-4): Delayed block allocation failed for inode 53 at logical offset 1342177280 with max blocks 1 with error 5
  EXT4-fs (dm-4): This should not happen!! Data will be lost

If delalloc is disabled, e2fsck -nf shows corruption
  Inode 53, i_size is 5497558142976, should be 4096.  Fix? no

Fix the two issues by

a) forcing all delayed allocation blocks to be allocated before checking
   eh->eh_depth and eh->eh_entries
b) limiting the last logical block of the extent is within direct map

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I25d86f9680c983102e41ed76d10428efe4a3882e
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit d6f123a9297496ad0b6335fe881504c4b5b2a5e5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696633

[modify] https://crrev.com/3e3a21fc26fde5db7c891da3d05e34a3f3f07748/fs/ext4/migrate.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0bb763c71157e8ec445443f4ffd7718cf254ddcf

commit 0bb763c71157e8ec445443f4ffd7718cf254ddcf
Author: Eryu Guan <guaneryu@gmail.com>
Date: Thu Oct 12 03:44:55 2017

UPSTREAM: ext4: correctly migrate a file with a hole at the beginning

Currently ext4_ind_migrate() doesn't correctly handle a file which
contains a hole at the beginning of the file.  This caused the migration
to be done incorrectly, and then if there is a subsequent following
delayed allocation write to the "hole", this would reclaim the same data
blocks again and results in fs corruption.

  # assmuing 4k block size ext4, with delalloc enabled
  # skip the first block and write to the second block
  xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/ext4/testfile

  # converting to indirect-mapped file, which would move the data blocks
  # to the beginning of the file, but extent status cache still marks
  # that region as a hole
  chattr -e /mnt/ext4/testfile

  # delayed allocation writes to the "hole", reclaim the same data block
  # again, results in i_blocks corruption
  xfs_io -c "pwrite 0 4k" /mnt/ext4/testfile
  umount /mnt/ext4
  e2fsck -nf /dev/sda6
  ...
  Inode 53, i_blocks is 16, should be 8.  Fix? no
  ...

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Idb02b5890627e9d199616ff440705d7a839527fd
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit 8974fec7d72e3e02752fe0f27b4c3719c78d9a15)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696634

[modify] https://crrev.com/0bb763c71157e8ec445443f4ffd7718cf254ddcf/fs/ext4/migrate.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ada76af7002e4d3f22f004c6ac19e83645d3e268

commit ada76af7002e4d3f22f004c6ac19e83645d3e268
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Thu Oct 12 03:44:56 2017

UPSTREAM: ext4: verify extent header depth

Although the extent tree depth of 5 should enough be for the worst
case of 2*32 extents of length 1, the extent tree code does not
currently to merge nodes which are less than half-full with a sibling
node, or to shrink the tree depth if possible.  So it's possible, at
least in theory, for the tree depth to be greater than 5.  However,
even in the worst case, a tree depth of 32 is highly unlikely, and if
the file system is maliciously corrupted, an insanely large eh_depth
can cause memory allocation failures that will trigger kernel warnings
(here, eh_depth = 65280):

    JBD2: ext4.exe wants too many credits credits:195849 rsv_credits:0 max:256
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 50 at fs/jbd2/transaction.c:293 start_this_handle+0x569/0x580
    CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ #508
    Stack:
     604a8947 625badd8 0002fd09 00000000
     60078643 00000000 62623910 601bf9bc
     62623970 6002fc84 626239b0 900000125
    Call Trace:
     [<6001c2dc>] show_stack+0xdc/0x1a0
     [<601bf9bc>] dump_stack+0x2a/0x2e
     [<6002fc84>] __warn+0x114/0x140
     [<6002fdff>] warn_slowpath_null+0x1f/0x30
     [<60165829>] start_this_handle+0x569/0x580
     [<60165d4e>] jbd2__journal_start+0x11e/0x220
     [<60146690>] __ext4_journal_start_sb+0x60/0xa0
     [<60120a81>] ext4_truncate+0x131/0x3a0
     [<60123677>] ext4_setattr+0x757/0x840
     [<600d5d0f>] notify_change+0x16f/0x2a0
     [<600b2b16>] do_truncate+0x76/0xc0
     [<600c3e56>] path_openat+0x806/0x1300
     [<600c55c9>] do_filp_open+0x89/0xf0
     [<600b4074>] do_sys_open+0x134/0x1e0
     [<600b4140>] SyS_open+0x20/0x30
     [<6001ea68>] handle_syscall+0x88/0x90
     [<600295fd>] userspace+0x3fd/0x500
     [<6001ac55>] fork_handler+0x85/0x90

    ---[ end trace 08b0b88b6387a244 ]---

[ Commit message modified and the extent tree depath check changed
from 5 to 32 -- tytso ]

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I88cc71260e0d800c677b662900355d356c0a9a3c
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 7bc9491645118c9461bd21099c31755ff6783593)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696635

[modify] https://crrev.com/ada76af7002e4d3f22f004c6ac19e83645d3e268/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4dfc40c9e88eda1f0d7a1101ecd8a6f9266a33be

commit 4dfc40c9e88eda1f0d7a1101ecd8a6f9266a33be
Author: Eric Whitney <enwlinux@gmail.com>
Date: Thu Oct 12 03:44:57 2017

UPSTREAM: ext4: fix partial cluster initialization

The partial_cluster variable is not always initialized correctly when
hole punching on bigalloc file systems.  Although commit c06344939422
("ext4: fix partial cluster handling for bigalloc file systems")
addressed the case where the right edge of the punched region and the
next extent to its right were within the same leaf, it didn't handle
the case where the next extent to its right is in the next leaf.  This
causes xfstest generic/300 to fail.

Fix this by replacing the code in c0634493922 with a more general
solution that can continue the search for the first cluster to the
right of the punched region into the next leaf if present.  If found,
partial_cluster is initialized to this cluster's negative value.
There's no need to determine if that cluster is actually shared;  we
simply record it so its blocks won't be freed in the event it does
happen to be shared.

Also, minimize the burden on non-bigalloc file systems with some minor
code simplification.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I1328c1afc75f47bf0510915f5570d048895713a8
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit f4226d9ea400e7124120571b1e89504c79f2e953)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696636

[modify] https://crrev.com/4dfc40c9e88eda1f0d7a1101ecd8a6f9266a33be/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bbe2fefed784a469832439049aae72ad4827a90a

commit bbe2fefed784a469832439049aae72ad4827a90a
Author: Eric Whitney <enwlinux@gmail.com>
Date: Thu Oct 12 03:44:58 2017

UPSTREAM: ext4: fix end of leaf partial cluster handling

The fix in commit ad6599ab3ac9 ("ext4: fix premature freeing of
partial clusters split across leaf blocks"), intended to avoid
dereferencing an invalid extent pointer when determining whether a
partial cluster should be freed, wasn't quite good enough.  Assure that
at least one extent remains at the start of the leaf once the hole has
been punched.  Otherwise, the pointer to the extent to the right of the
hole will be invalid and a partial cluster will be incorrectly freed.

Set partial_cluster to 0 when we can tell we've hit the left edge of
the punched region within the leaf.  This prevents incorrect freeing
of a partial cluster when ext4_ext_rm_leaf is called one last time
during extent tree traversal after the punched region has been removed.

Adjust comments to reflect code changes and a correction.  Remove a bit
of dead code.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I5ad704d8faf74643439095a6bb2904510f8560a0
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 5bf43760654fa618fb8bb1612ee2d7ae164f7f94)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696637

[modify] https://crrev.com/bbe2fefed784a469832439049aae72ad4827a90a/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/42d0b2874f94e143fc34217b9ed95f5ec64ef272

commit 42d0b2874f94e143fc34217b9ed95f5ec64ef272
Author: Eric Whitney <enwlinux@gmail.com>
Date: Thu Oct 12 03:44:59 2017

UPSTREAM: ext4: miscellaneous partial cluster cleanups

Add some casts and rearrange a few statements for improved readability.
Some code can also be simplified and made more readable if we set
partial_cluster to 0 rather than to a negative value when we can tell
we've hit the left edge of the punched region.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I34408018d539542edf48c2af3c7d03ef1788aa28
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 345ee947482f1c787b31014008586b8f512af1bd)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696638

[modify] https://crrev.com/42d0b2874f94e143fc34217b9ed95f5ec64ef272/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/570fd02115a36c5d4066ced6d59824b88c954ae2

commit 570fd02115a36c5d4066ced6d59824b88c954ae2
Author: Eric Whitney <enwlinux@gmail.com>
Date: Thu Oct 12 03:45:01 2017

UPSTREAM: ext4: fix end of region partial cluster handling

ext4_ext_remove_space() can incorrectly free a partial_cluster if
EAGAIN is encountered while truncating or punching.  Extent removal
should be retried in this case.

It also fails to free a partial cluster when the punched region begins
at the start of a file on that unaligned cluster and where the entire
file has not been punched.  Remove the requirement that all blocks in
the file must have been freed in order to free the partial cluster.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Ia858b6e1925b2e1e37357ab6e5a9928ac60e0f25
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 0756b908a364c217bc2d8063783992ffe338b143)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696639

[modify] https://crrev.com/570fd02115a36c5d4066ced6d59824b88c954ae2/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3cb073761bb319797b3e88b7d1dbc97afdbbd786

commit 3cb073761bb319797b3e88b7d1dbc97afdbbd786
Author: David Moore <dmoorefo@gmail.com>
Date: Thu Oct 12 03:45:02 2017

UPSTREAM: ext4: BUG_ON assertion repeated for inode1, not done for inode2

During a source code review of fs/ext4/extents.c I noted identical
consecutive lines. An assertion is repeated for inode1 and never done
for inode2. This is not in keeping with the rest of the code in the
ext4_swap_extents function and appears to be a bug.

Assert that the inode2 mutex is not locked.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I1098aafb7b70b0f74aff3dfe2706970aaa554bce
Signed-off-by: David Moore <dmoorefo@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
(cherry picked from commit 8bc3b1e6e8fdc1c605c06c027d999b5cca434779)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696640

[modify] https://crrev.com/3cb073761bb319797b3e88b7d1dbc97afdbbd786/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2f55bbdd405cf4a664d4eb3a4deac25fe81593d7

commit 2f55bbdd405cf4a664d4eb3a4deac25fe81593d7
Author: Theodore Ts'o <tytso@mit.edu>
Date: Thu Oct 12 03:45:03 2017

UPSTREAM: ext4: fix race between truncate and __ext4_journalled_writepage()

The commit cf108bca465d: "ext4: Invert the locking order of page_lock
and transaction start" caused __ext4_journalled_writepage() to drop
the page lock before the page was written back, as part of changing
the locking order to jbd2_journal_start -> page_lock.  However, this
introduced a potential race if there was a truncate racing with the
data=journalled writeback mode.

Fix this by grabbing the page lock after starting the journal handle,
and then checking to see if page had gotten truncated out from under
us.

This fixes a number of different warnings or BUG_ON's when running
xfstests generic/086 in data=journalled mode, including:

jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7
c0, 164), jh->b_transaction (  (null), 0), jh->b_next_transaction (  (null), 0), jlist 0

	      	      	  - and -

kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200!
    ...
Call Trace:
 [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
 [<c02b2de5>] __ext4_journalled_invalidatepage+0x10f/0x117
 [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
 [<c027d883>] ? lock_buffer+0x36/0x36
 [<c02b2dfa>] ext4_journalled_invalidatepage+0xd/0x22
 [<c0229139>] do_invalidatepage+0x22/0x26
 [<c0229198>] truncate_inode_page+0x5b/0x85
 [<c022934b>] truncate_inode_pages_range+0x156/0x38c
 [<c0229592>] truncate_inode_pages+0x11/0x15
 [<c022962d>] truncate_pagecache+0x55/0x71
 [<c02b913b>] ext4_setattr+0x4a9/0x560
 [<c01ca542>] ? current_kernel_time+0x10/0x44
 [<c026c4d8>] notify_change+0x1c7/0x2be
 [<c0256a00>] do_truncate+0x65/0x85
 [<c0226f31>] ? file_ra_state_init+0x12/0x29

	      	      	  - and -

WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396
irty_metadata+0x14a/0x1ae()
    ...
Call Trace:
 [<c01b879f>] ? console_unlock+0x3a1/0x3ce
 [<c082cbb4>] dump_stack+0x48/0x60
 [<c0178b65>] warn_slowpath_common+0x89/0xa0
 [<c02ef2cf>] ? jbd2_journal_dirty_metadata+0x14a/0x1ae
 [<c0178bef>] warn_slowpath_null+0x14/0x18
 [<c02ef2cf>] jbd2_journal_dirty_metadata+0x14a/0x1ae
 [<c02d8615>] __ext4_handle_dirty_metadata+0xd4/0x19d
 [<c02b2f44>] write_end_fn+0x40/0x53
 [<c02b4a16>] ext4_walk_page_buffers+0x4e/0x6a
 [<c02b59e7>] ext4_writepage+0x354/0x3b8
 [<c02b2f04>] ? mpage_release_unused_pages+0xd4/0xd4
 [<c02b1b21>] ? wait_on_buffer+0x2c/0x2c
 [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
 [<c02b5a5b>] __writepage+0x10/0x2e
 [<c0225956>] write_cache_pages+0x22d/0x32c
 [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
 [<c02b6ee8>] ext4_writepages+0x102/0x607
 [<c019adfe>] ? sched_clock_local+0x10/0x10e
 [<c01a8a7c>] ? __lock_is_held+0x2e/0x44
 [<c01a8ad5>] ? lock_is_held+0x43/0x51
 [<c0226dff>] do_writepages+0x1c/0x29
 [<c0276bed>] __writeback_single_inode+0xc3/0x545
 [<c0277c07>] writeback_sb_inodes+0x21f/0x36d
    ...

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: Idaa7ef76a91dabbc7a4f3c0b8126db1eb0fe7d35
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
(cherry picked from commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696641

[modify] https://crrev.com/2f55bbdd405cf4a664d4eb3a4deac25fe81593d7/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e1f32e66f571571a51097ac84ad6d4a70ec745a5

commit e1f32e66f571571a51097ac84ad6d4a70ec745a5
Author: Lukas Czerner <lczerner@redhat.com>
Date: Thu Oct 12 03:45:04 2017

UPSTREAM: ext4: recalculate journal credits as inode depth changes

Currently in ext4_alloc_file_blocks() the number of credits is
calculated only once before we enter the allocation loop. However within
the allocation loop the extent tree depth can change, hence the number
of credits needed can increase potentially exceeding the number of credits
reserved in the handle which can cause journal failures.

Fix this by recalculating number of credits when the inode depth
changes. Note that even though ext4_alloc_file_blocks() is only
currently used by extent base inodes we will avoid recalculating number
of credits unnecessarily in the case of indirect based inodes.

BUG=chromium:766786
TEST=build/boot on samus, xfstest

Change-Id: I1e571cfbc8606eabeca0b4feb885354bca157294
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 4134f5c88dcd5b00e4a5f37c3842b2b831a61ee1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696642

[modify] https://crrev.com/e1f32e66f571571a51097ac84ad6d4a70ec745a5/fs/ext4/extents.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/934b28e8be9822f438dffd660ae4730af197def2

commit 934b28e8be9822f438dffd660ae4730af197def2
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:23 2017

UPSTREAM: dm thin: simplify pool_is_congested

The pool is congested if the pool is in PM_OUT_OF_DATA_SPACE mode.  This
is more explicit/clear/efficient than inferring whether or not the pool
is congested by checking if retry_on_resume_list is empty.

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: I10f5be7fed39eadabbb54dc11a0682e684e5e7f4
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
(cherry picked from commit 760fe67e539b2f1a95dbb4c9700140eccdb1c0c1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696545
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/934b28e8be9822f438dffd660ae4730af197def2/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/915e6cf2e3f5b3831d07dc4c104d20ba8506f079

commit 915e6cf2e3f5b3831d07dc4c104d20ba8506f079
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:24 2017

UPSTREAM: dm thin: use per thin device deferred bio lists

The thin-pool previously only had a single deferred_bios list that would
collect bios for all thin devices in the pool.  Split this per-pool
deferred_bios list out to per-thin deferred_bios_list -- doing so
enables increased parallelism when processing deferred bios.  And now
that each thin device has it's own deferred_bios_list we can sort all
bios in the list using logical sector.  The requeue code in error
handling path is also cleaner as a side-effect.

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: I11591a1691e6704c2c62a58302d59aa5505317d1
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
(cherry picked from commit c140e1c4e23bdaf0a5c00b6a8b6d18f259d39a00)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696546
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/915e6cf2e3f5b3831d07dc4c104d20ba8506f079/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e19e47d5e1fe1b59fd7dbc2f6eecb199954ad21e

commit e19e47d5e1fe1b59fd7dbc2f6eecb199954ad21e
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:26 2017

UPSTREAM: dm thin: sort the per thin deferred bios using an rb_tree

A thin-pool will allocate blocks using FIFO order for all thin devices
which share the thin-pool.  Because of this simplistic allocation the
thin-pool's space can become fragmented quite easily; especially when
multiple threads are requesting blocks in parallel.

Sort each thin device's deferred_bio_list based on logical sector to
help reduce fragmentation of the thin-pool's ondisk layout.

The following tables illustrate the realized gains/potential offered by
sorting each thin device's deferred_bio_list.  An "io size"-sized random
read of the device would result in "seeks/io" fragments being read, with
an average "distance/seek" between each fragment.

Data was written to a single thin device using multiple threads via
iozone (8 threads, 64K for both the block_size and io_size).

unsorted:

     io size   seeks/io distance/seek
  --------------------------------------
          4k    0.000   0b
         16k    0.013   11m
         64k    0.065   11m
        256k    0.274   10m
          1m    1.109   10m
          4m    4.411   10m
         16m    17.097  11m
         64m    60.055  13m
        256m    148.798 25m
          1g    809.929 21m

sorted:

     io size   seeks/io distance/seek
  --------------------------------------
          4k    0.000   0b
         16k    0.000   1g
         64k    0.001   1g
        256k    0.003   1g
          1m    0.011   1g
          4m    0.045   1g
         16m    0.181   1g
         64m    0.747   1011m
        256m    3.299   1g
          1g    14.373  1g

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: Ibfc9ec173e0c3c3c36cbf7c47c83837d9d058016
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
(cherry picked from commit 67324ea18812bc952ef96892fbd5817b9050413f)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696547
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/e19e47d5e1fe1b59fd7dbc2f6eecb199954ad21e/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fb787be0e08b993b9dbd485fecdeaaa61e5247ce

commit fb787be0e08b993b9dbd485fecdeaaa61e5247ce
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:27 2017

UPSTREAM: dm thin: irqsave must always be used with the pool->lock spinlock

Commit c140e1c4e23 ("dm thin: use per thin device deferred bio lists")
incorrectly stopped disabling irqs when taking the pool's spinlock.

Irqs must be disabled when taking the pool's spinlock otherwise a thread
could spin_lock(), then get interrupted to service thin_endio() in
interrupt context, which would then deadlock in spin_lock_irqsave().

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: I36fdb2d0f123373a035d67395e377bffb2ca50b1
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit 5e3283e2920a0bd8a806964d80274b8756e0dd7f)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696548
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/fb787be0e08b993b9dbd485fecdeaaa61e5247ce/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6c0139ec7e647907354a1d208bf69069ec9c8d1d

commit 6c0139ec7e647907354a1d208bf69069ec9c8d1d
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:28 2017

UPSTREAM: dm thin: fix rcu_read_lock being held in code that can sleep

Commit c140e1c4e23 ("dm thin: use per thin device deferred bio lists")
introduced the use of an rculist for all active thin devices.  The use
of rcu_read_lock() in process_deferred_bios() can result in a BUG if a
dm_bio_prison_cell must be allocated as a side-effect of bio_detain():

 BUG: sleeping function called from invalid context at mm/mempool.c:203
 in_atomic(): 1, irqs_disabled(): 0, pid: 6, name: kworker/u8:0
 3 locks held by kworker/u8:0/6:
   #0:  ("dm-" "thin"){.+.+..}, at: [<ffffffff8106be42>] process_one_work+0x192/0x550
   #1:  ((&pool->worker)){+.+...}, at: [<ffffffff8106be42>] process_one_work+0x192/0x550
   #2:  (rcu_read_lock){.+.+..}, at: [<ffffffff816360b5>] do_worker+0x5/0x4d0

We can't process deferred bios with the rcu lock held, since
dm_bio_prison_cell allocation may block if the bio-prison's cell mempool
is exhausted.

To fix:

- Introduce a refcount and completion field to each thin_c

- Add thin_get/put methods for adjusting the refcount.  If the refcount
  hits zero then the completion is triggered.

- Initialise refcount to 1 when creating thin_c

- When iterating the active_thins list we thin_get() whilst the rcu
  lock is held.

- After the rcu lock is dropped we process the deferred bios for that
  thin.

- When destroying a thin_c we thin_put() and then wait for the
  completion -- to avoid a race between the worker thread iterating
  from that thin_c and destroying the thin_c.

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: I6e71cbccad805b769fbc307f2c78981c219bf2e6
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit b10ebd34cccae1b431caf1be54919aede2be7cbe)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696549
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/6c0139ec7e647907354a1d208bf69069ec9c8d1d/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0812e82b54462a78050bf6bea8b1bd5f69efa196

commit 0812e82b54462a78050bf6bea8b1bd5f69efa196
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:29 2017

UPSTREAM: dm thin: switch to an atomic_t for tracking pending new block preparations

Previously we used separate boolean values to track quiescing and
copying actions.  By switching to an atomic_t we can support blocks that
need a partial copy and partial zero.

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: Ibb91b2a13ea310ddc03e433349e9180ab38e1936
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit 50f3c3efdd5773d90396be07a7ecaa58227ff906)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696552
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/0812e82b54462a78050bf6bea8b1bd5f69efa196/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b4249eabb2475d28f7d67bc731ccc7f2e4dbcceb

commit b4249eabb2475d28f7d67bc731ccc7f2e4dbcceb
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:30 2017

UPSTREAM: dm thin: relax external origin size constraints

Track the size of any external origin.  Previously the external origin's
size had to be a multiple of the thin-pool's block size, that is no
longer a requirement.  In addition, snapshots that are larger than the
external origin are now supported.

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: Ic036af7680aba6060f99e7b57b349de1d59aed87
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit e5aea7b49f2b1fd01f35ca7abeb76f5c56128a55)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696553
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/b4249eabb2475d28f7d67bc731ccc7f2e4dbcceb/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b125e525ac98b89dce308c93d1d5d44c246edef6

commit b125e525ac98b89dce308c93d1d5d44c246edef6
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:32 2017

UPSTREAM: dm thin: set minimum_io_size to pool's data block size

Before, if the block layer's limit stacking didn't establish an
optimal_io_size that was compatible with the thin-pool's data block size
we'd set optimal_io_size to the data block size and minimum_io_size to 0
(which the block layer adjusts to be physical_block_size).

Update pool_io_hints() to set both minimum_io_size and optimal_io_size
to the thin-pool's data block size.  This fixes an issue reported where
mkfs.xfs would create more XFS Allocation Groups on thinp volumes than
on a normal linear LV of comparable size, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1003227

BUG=chromium:766786
TEST=build/boot on samus, xfstest generic/405 passes

Change-Id: If472aa86daa1745d4a12dab72aab84eb4833a9ad
Reported-by: Chris Murphy <lists@colorremedies.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit fdfb4c8c1a9fc8dd8cf8eeb4e3ed83573b375285)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/696554
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/b125e525ac98b89dce308c93d1d5d44c246edef6/drivers/md/dm-thin.c

For kernel 3.10 - I did a different series -- I just pulled everything that was in the 3.10 stable branch back to our 3.10 kernel

this is the final CL:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/729962

Series is still quite long at ~95 patches

The series seems to fix 4 of 6 kernel crashes that I see with xfstests -g auto
and one other test starts to pass

also moving the target to M-64

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e591efff40de62b82fab9aa1f3d4759049bb09d6

commit e591efff40de62b82fab9aa1f3d4759049bb09d6
Author: Theodore Ts'o <tytso@mit.edu>
Date: Tue Oct 31 01:46:50 2017

UPSTREAM: ext4: call ext4_error_inode() if jbd2_journal_dirty_metadata() fails

commit ae1495b12df1897d4f42842a7aa7276d920f6290 upstream.

While it's true that errors can only happen if there is a bug in
jbd2_journal_dirty_metadata(), if a bug does happen, we need to halt
the kernel or remount the file system read-only in order to avoid
further data loss.  The ext4_journal_abort_handle() function doesn't
do any of this, and while it's likely that this call (since it doesn't
adjust refcounts) will likely result in the file system eventually
deadlocking since the current transaction will never be able to close,
it's much cleaner to call let ext4's error handling system deal with
this situation.

There's a separate bug here which is that if certain jbd2 errors
errors occur and file system is mounted errors=continue, the file
system will probably eventually end grind to a halt as described
above.  But things have been this way in a long time, and usually when
we have these sorts of errors it's pretty much a disaster --- and
that's why the jbd2 layer aggressively retries memory allocations,
which is the most likely cause of these jbd2 errors.

BUG=chromium:766786
TEST=build/boot on nyan_blaze

Change-Id: I7e3903b0f4d7130f6c0e1cf197a598258bf99889
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6b8588219a59ae34f99e20f17bc9756f831a9b2e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/729230
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/e591efff40de62b82fab9aa1f3d4759049bb09d6/fs/ext4/ext4_jbd2.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/62ec2d619fb82a59d8a4eaa417633c7d23e69605

commit 62ec2d619fb82a59d8a4eaa417633c7d23e69605
Author: Junho Ryu <jayr@google.com>
Date: Tue Oct 31 01:46:51 2017

UPSTREAM: ext4: fix use-after-free in ext4_mb_new_blocks

commit 4e8d2139802ce4f41936a687f06c560b12115247 upstream.

ext4_mb_put_pa should hold pa->pa_lock before accessing pa->pa_count.
While ext4_mb_use_preallocated checks pa->pa_deleted first and then
increments pa->count later, ext4_mb_put_pa decrements pa->pa_count
before holding pa->pa_lock and then sets pa->pa_deleted.

* Free sequence
ext4_mb_put_pa (1):		atomic_dec_and_test pa->pa_count
ext4_mb_put_pa (2):		lock pa->pa_lock
ext4_mb_put_pa (3):			check pa->pa_deleted
ext4_mb_put_pa (4):			set pa->pa_deleted=1
ext4_mb_put_pa (5):		unlock pa->pa_lock
ext4_mb_put_pa (6):		remove pa from a list
ext4_mb_pa_callback:		free pa

* Use sequence
ext4_mb_use_preallocated (1):	iterate over preallocation
ext4_mb_use_preallocated (2):	lock pa->pa_lock
ext4_mb_use_preallocated (3):		check pa->pa_deleted
ext4_mb_use_preallocated (4):		increase pa->pa_count
ext4_mb_use_preallocated (5):	unlock pa->pa_lock
ext4_mb_release_context:	access pa

* Use-after-free sequence
[initial status]		<pa->pa_deleted = 0, pa_count = 1>
ext4_mb_use_preallocated (1):	iterate over preallocation
ext4_mb_use_preallocated (2):	lock pa->pa_lock
ext4_mb_use_preallocated (3):		check pa->pa_deleted
ext4_mb_put_pa (1):		atomic_dec_and_test pa->pa_count
[pa_count decremented]		<pa->pa_deleted = 0, pa_count = 0>
ext4_mb_use_preallocated (4):		increase pa->pa_count
[pa_count incremented]		<pa->pa_deleted = 0, pa_count = 1>
ext4_mb_use_preallocated (5):	unlock pa->pa_lock
ext4_mb_put_pa (2):		lock pa->pa_lock
ext4_mb_put_pa (3):			check pa->pa_deleted
ext4_mb_put_pa (4):			set pa->pa_deleted=1
[race condition!]		<pa->pa_deleted = 1, pa_count = 1>
ext4_mb_put_pa (5):		unlock pa->pa_lock
ext4_mb_put_pa (6):		remove pa from a list
ext4_mb_pa_callback:		free pa
ext4_mb_release_context:	access pa

AddressSanitizer has detected use-after-free in ext4_mb_new_blocks
Bug report: http://goo.gl/rG1On3

BUG=chromium:766786
TEST=build/boot on nyan_blaze

Change-Id: Ib115995e9f4bb0914a89b50b22bc40827fddbe12
Signed-off-by: Junho Ryu <jayr@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e696abfcc89a087afef75ebca0848f37fb9877ae)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/729231
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/62ec2d619fb82a59d8a4eaa417633c7d23e69605/fs/ext4/mballoc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0d9dc0e3659a7210ccd0cf0e093300cd315d8a61

commit 0d9dc0e3659a7210ccd0cf0e093300cd315d8a61
Author: Eryu Guan <guaneryu@gmail.com>
Date: Tue Oct 31 06:20:40 2017

UPSTREAM: ext4: fix NULL pointer dereference in ext4_mark_inode_dirty()

commit 5e1021f2b6dff1a86a468a1424d59faae2bc63c1 upstream.

ext4_reserve_inode_write() in ext4_mark_inode_dirty() could fail on
error (e.g. EIO) and iloc.bh can be NULL in this case. But the error is
ignored in the following "if" condition and ext4_expand_extra_isize()
might be called with NULL iloc.bh set, which triggers NULL pointer
dereference.

This is uncovered by commit 8b4953e13f4c ("ext4: reserve code points for
the project quota feature"), which enlarges the ext4_inode size, and
run the following script on new kernel but with old mke2fs:

  #/bin/bash
  mnt=/mnt/ext4
  devname=ext4-error
  dev=/dev/mapper/$devname
  fsimg=/home/fs.img

  trap cleanup 0 1 2 3 9 15

  cleanup()
  {
          umount $mnt >/dev/null 2>&1
          dmsetup remove $devname
          losetup -d $backend_dev
          rm -f $fsimg
          exit 0
  }

  rm -f $fsimg
  fallocate -l 1g $fsimg
  backend_dev=`losetup -f --show $fsimg`
  devsize=`blockdev --getsz $backend_dev`

  good_tab="0 $devsize linear $backend_dev 0"
  error_tab="0 $devsize error $backend_dev 0"

  dmsetup create $devname --table "$good_tab"

  mkfs -t ext4 $dev
  mount -t ext4 -o errors=continue,strictatime $dev $mnt

  dmsetup load $devname --table "$error_tab" && dmsetup resume $devname
  echo 3 > /proc/sys/vm/drop_caches
  ls -l $mnt
  exit 0

[ Patch changed to simplify the function a tiny bit. -- Ted ]

BUG=chromium:766786
TEST=build/boot on nyan_blaze

Change-Id: Ia150f748592a6c3de8e73fd09514eb247665c12b
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 308f438aa483b50a316122af37e215085f073b86)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/729930
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/0d9dc0e3659a7210ccd0cf0e093300cd315d8a61/fs/ext4/inode.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e5d4e9dc8449e18bafe11d78ec23c6f68eaa09cc

commit e5d4e9dc8449e18bafe11d78ec23c6f68eaa09cc
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Tue Oct 31 06:20:41 2017

UPSTREAM: jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path

commit c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 upstream.

On umount path, jbd2_journal_destroy() writes latest transaction ID
(->j_tail_sequence) to be used at next mount.

The bug is that ->j_tail_sequence is not holding latest transaction ID
in some cases. So, at next mount, there is chance to conflict with
remaining (not overwritten yet) transactions.

	mount (id=10)
	write transaction (id=11)
	write transaction (id=12)
	umount (id=10) <= the bug doesn't write latest ID

	mount (id=10)
	write transaction (id=11)
	crash

	mount
	[recovery process]
		transaction (id=11)
		transaction (id=12) <= valid transaction ID, but old commit
                                       must not replay

Like above, this bug become the cause of recovery failure, or FS
corruption.

So why ->j_tail_sequence doesn't point latest ID?

Because if checkpoint transactions was reclaimed by memory pressure
(i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
(And another case is, __jbd2_journal_clean_checkpoint_list() is called
with empty transaction.)

So in above cases, ->j_tail_sequence is not pointing latest
transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
done too.

So, to fix this problem with minimum changes, this patch updates
->j_tail_sequence, and issue REQ_FLUSH.  (With more complex changes,
some optimizations would be possible to avoid unnecessary REQ_FLUSH
for example though.)

BTW,

	journal->j_tail_sequence =
		++journal->j_transaction_sequence;

Increment of ->j_transaction_sequence seems to be unnecessary, but
ext3 does this.

BUG=chromium:766786
TEST=build/boot on nyan_blaze

Change-Id: I8e19e1d12f13d4e687a2a81505945d4a028d91b1
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 7493d128722687a2f43c3cf6feef04f3b81e5bcb)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/729931
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/e5d4e9dc8449e18bafe11d78ec23c6f68eaa09cc/fs/jbd2/journal.c

Since it looks like  3.8 won't die for a while I'll do that too before closing this.

So 3.8 doesn't have any stable series -- I'll look at what was on 3.10 that will go back onto 3.8

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1af0976aaf10f6779035426efdf4aae482e547b9

commit 1af0976aaf10f6779035426efdf4aae482e547b9
Author: Maurizio Lombardi <mlombard@redhat.com>
Date: Tue Nov 14 18:11:22 2017

ext4: fix wrong assert in ext4_mb_normalize_request()

The variable "size" is expressed as number of blocks and not as
number of clusters, this could trigger a kernel panic when using
ext4 with the size of a cluster different from the size of a block.

BUG=chromium:766786
TEST=Check ext4/003 does not crash anymore, just fails.

Cc: stable@vger.kernel.org
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit b5b60778558cafad17bbcbf63e0310bd3c68eb17)
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>

Change-Id: Iad96693c5616ca4eaa284e107907cc7195548af4
Reviewed-on: https://chromium-review.googlesource.com/767580
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/1af0976aaf10f6779035426efdf4aae482e547b9/fs/ext4/mballoc.c

Is this bug related with crbug.com/738895 where "device losing enrollment due to stateful partition corruption"?

I hit issue where enrollment got lost. ChromeOS is guado-release/R64-10176.8.0.

localhost log # fgrep sda1 messages* | fgrep "error count"
2017-12-12T00:54:17.249001+00:00 NOTICE kernel: [  302.301439] EXT4-fs (sda1): error count since last fsck: 4866
2017-12-11T17:11:48.708407-08:00 NOTICE kernel: [  302.300780] EXT4-fs (sda1): error count since last fsck: 4866
2017-12-11T17:37:37.680110-08:00 NOTICE kernel: [  302.300637] EXT4-fs (sda1): error count since last fsck: 4866
2017-12-11T18:47:31.685057-08:00 NOTICE kernel: [  302.301666] EXT4-fs (sda1): error count since last fsck: 4866
2017-12-11T19:00:31.875050-08:00 NOTICE kernel: [  302.301453] EXT4-fs (sda1): error count since last fsck: 4866
2017-12-11T19:11:32.525136-08:00 NOTICE kernel: [  302.300647] EXT4-fs (sda1): error count since last fsck: 4866
2017-12-11T20:49:45.615139-08:00 NOTICE kernel: [  302.302242] EXT4-fs (sda1): error count since last fsck: 4866
2017-12-11T20:55:31.638704-08:00 NOTICE kernel: [  302.300586] EXT4-fs (sda1): error count since last fsck: 4866
localhost log # cat /etc/lsb-release 
CHROMEOS_RELEASE_APPID={8AA6D9AC-6EBC-4288-A615-171F56F66B4E}
CHROMEOS_BOARD_APPID={8AA6D9AC-6EBC-4288-A615-171F56F66B4E}
CHROMEOS_CANARY_APPID={90F229CE-83E2-4FAF-8479-E368A34938B1}
DEVICETYPE=CHROMEBOX
CHROMEOS_RELEASE_BUILDER_PATH=guado-release/R64-10176.8.0
GOOGLE_RELEASE=10176.8.0
CHROMEOS_DEVSERVER=
CHROMEOS_RELEASE_BOARD=guado
CHROMEOS_RELEASE_BUILD_NUMBER=10176
CHROMEOS_RELEASE_BRANCH_NUMBER=8
CHROMEOS_RELEASE_CHROME_MILESTONE=64
CHROMEOS_RELEASE_PATCH_NUMBER=0
CHROMEOS_RELEASE_TRACK=testimage-channel
CHROMEOS_RELEASE_DESCRIPTION=10176.8.0 (Official Build) dev-channel guado test
CHROMEOS_RELEASE_BUILD_TYPE=Official Build
CHROMEOS_RELEASE_NAME=Chrome OS
CHROMEOS_RELEASE_VERSION=10176.8.0
CHROMEOS_AUSERVER=https://tools.google.com/service/update2
localhost log # grep KINGSTON /var/log/messages 
2017-12-12T00:49:18.383760+00:00 INFO kernel: [    0.618131] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-12T00:49:18.383762+00:00 NOTICE kernel: [    0.618448] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T17:03:26.926256-08:00 INFO kernel: [    0.624293] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T17:03:26.926264-08:00 NOTICE kernel: [    0.624614] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T17:06:49.065422-08:00 INFO kernel: [    0.630258] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T17:06:49.065433-08:00 NOTICE kernel: [    0.630575] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T17:32:36.929094-08:00 INFO kernel: [    0.625262] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T17:32:36.929099-08:00 NOTICE kernel: [    0.625584] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T18:42:30.940212-08:00 INFO kernel: [    0.619159] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T18:42:30.940218-08:00 NOTICE kernel: [    0.619482] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T18:55:32.038730-08:00 INFO kernel: [    0.619063] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T18:55:32.038735-08:00 NOTICE kernel: [    0.619386] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T19:06:31.924604-08:00 INFO kernel: [    1.149659] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T19:06:31.924610-08:00 NOTICE kernel: [    1.149982] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T20:41:25.926344-08:00 INFO kernel: [    0.625139] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T20:41:25.926350-08:00 NOTICE kernel: [    0.625457] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T20:44:44.885613-08:00 INFO kernel: [    1.141653] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T20:44:44.885618-08:00 NOTICE kernel: [    1.141946] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
2017-12-11T20:50:31.933916-08:00 INFO kernel: [    0.625199] ata1.00: ATA-10: KINGSTON RBU-SNS4151S316GG2, S9FM02D5, max UDMA/133
2017-12-11T20:50:31.933921-08:00 NOTICE kernel: [    0.625523] scsi 0:0:0:0: Direct-Access     ATA      KINGSTON RBU-SNS S9FM PQ: 0 ANSI: 5
localhost log # 

Uploading debug file from Guado.

Deleted: host.22.lost.enrollment.tgz 20.7 MB

host.22.lost.enrollment.tgz 20.7 MB Download

#232. Not sure. From the log, your device has stateful fs errors since at least 12/04: 2017-12-04T15:27:12.459925-08:00 WARNING kernel: [    1.780965] EXT4-fs (sda1): warning: mounting fs with errors, running e2fsck is recommended

First event in eventlog.txt is only 2017-12-05 18:42:36, I don't know if the device has been powered down abruptly. Given your device is a SNS4151S316GG2, chromium:693439 is more suitable.

I think this is done