<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/fs/ext4, branch linux-3.17.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ext4: prevent bugon on race between write/fcntl</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Dmitry Monakhov</name>
<email>dmonakhov@openvz.org</email>
</author>
<published>2014-10-30T14:53:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a6896378d1b8c4c2b5267cd09e052e3e6b604ddd'/>
<id>a6896378d1b8c4c2b5267cd09e052e3e6b604ddd</id>
<content type='text'>
commit a41537e69b4aa43f0fea02498c2595a81267383b upstream.

O_DIRECT flags can be toggeled via fcntl(F_SETFL). But this value checked
twice inside ext4_file_write_iter() and __generic_file_write() which
result in BUG_ON inside ext4_direct_IO.

Let's initialize iocb-&gt;private unconditionally.

TESTCASE: xfstest:generic/036  https://patchwork.ozlabs.org/patch/402445/

#TYPICAL STACK TRACE:
kernel BUG at fs/ext4/inode.c:2960!
invalid opcode: 0000 [#1] SMP
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
CPU: 6 PID: 5505 Comm: aio-dio-fcntl-r Not tainted 3.17.0-rc2-00176-gff5c017 #161
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
task: ffff88080e95a7c0 ti: ffff88080f908000 task.ti: ffff88080f908000
RIP: 0010:[&lt;ffffffff811fabf2&gt;]  [&lt;ffffffff811fabf2&gt;] ext4_direct_IO+0x162/0x3d0
RSP: 0018:ffff88080f90bb58  EFLAGS: 00010246
RAX: 0000000000000400 RBX: ffff88080fdb2a28 RCX: 00000000a802c818
RDX: 0000040000080000 RSI: ffff88080d8aeb80 RDI: 0000000000000001
RBP: ffff88080f90bbc8 R08: 0000000000000000 R09: 0000000000001581
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88080d8aeb80
R13: ffff88080f90bbf8 R14: ffff88080fdb28c8 R15: ffff88080fdb2a28
FS:  00007f23b2055700(0000) GS:ffff880818400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f23b2045000 CR3: 000000080cedf000 CR4: 00000000000407e0
Stack:
 ffff88080f90bb98 0000000000000000 7ffffffffffffffe ffff88080fdb2c30
 0000000000000200 0000000000000200 0000000000000001 0000000000000200
 ffff88080f90bbc8 ffff88080fdb2c30 ffff88080f90be08 0000000000000200
Call Trace:
 [&lt;ffffffff8112ca9d&gt;] generic_file_direct_write+0xed/0x180
 [&lt;ffffffff8112f2b2&gt;] __generic_file_write_iter+0x222/0x370
 [&lt;ffffffff811f495b&gt;] ext4_file_write_iter+0x34b/0x400
 [&lt;ffffffff811bd709&gt;] ? aio_run_iocb+0x239/0x410
 [&lt;ffffffff811bd709&gt;] ? aio_run_iocb+0x239/0x410
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810abd94&gt;] ? __lock_acquire+0x274/0x700
 [&lt;ffffffff811f4610&gt;] ? ext4_unwritten_wait+0xb0/0xb0
 [&lt;ffffffff811bd756&gt;] aio_run_iocb+0x286/0x410
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810ac359&gt;] ? lock_release_holdtime+0x29/0x190
 [&lt;ffffffff811bc05b&gt;] ? lookup_ioctx+0x4b/0xf0
 [&lt;ffffffff811bde3b&gt;] do_io_submit+0x55b/0x740
 [&lt;ffffffff811bdcaa&gt;] ? do_io_submit+0x3ca/0x740
 [&lt;ffffffff811be030&gt;] SyS_io_submit+0x10/0x20
 [&lt;ffffffff815ce192&gt;] system_call_fastpath+0x16/0x1b
Code: 01 48 8b 80 f0 01 00 00 48 8b 18 49 8b 45 10 0f 85 f1 01 00 00 48 03 45 c8 48 3b 43 48 0f 8f e3 01 00 00 49 83 7c
24 18 00 75 04 &lt;0f&gt; 0b eb fe f0 ff 83 ec 01 00 00 49 8b 44 24 18 8b 00 85 c0 89
RIP  [&lt;ffffffff811fabf2&gt;] ext4_direct_IO+0x162/0x3d0
 RSP &lt;ffff88080f90bb58&gt;

Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a41537e69b4aa43f0fea02498c2595a81267383b upstream.

O_DIRECT flags can be toggeled via fcntl(F_SETFL). But this value checked
twice inside ext4_file_write_iter() and __generic_file_write() which
result in BUG_ON inside ext4_direct_IO.

Let's initialize iocb-&gt;private unconditionally.

TESTCASE: xfstest:generic/036  https://patchwork.ozlabs.org/patch/402445/

#TYPICAL STACK TRACE:
kernel BUG at fs/ext4/inode.c:2960!
invalid opcode: 0000 [#1] SMP
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
CPU: 6 PID: 5505 Comm: aio-dio-fcntl-r Not tainted 3.17.0-rc2-00176-gff5c017 #161
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
task: ffff88080e95a7c0 ti: ffff88080f908000 task.ti: ffff88080f908000
RIP: 0010:[&lt;ffffffff811fabf2&gt;]  [&lt;ffffffff811fabf2&gt;] ext4_direct_IO+0x162/0x3d0
RSP: 0018:ffff88080f90bb58  EFLAGS: 00010246
RAX: 0000000000000400 RBX: ffff88080fdb2a28 RCX: 00000000a802c818
RDX: 0000040000080000 RSI: ffff88080d8aeb80 RDI: 0000000000000001
RBP: ffff88080f90bbc8 R08: 0000000000000000 R09: 0000000000001581
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88080d8aeb80
R13: ffff88080f90bbf8 R14: ffff88080fdb28c8 R15: ffff88080fdb2a28
FS:  00007f23b2055700(0000) GS:ffff880818400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f23b2045000 CR3: 000000080cedf000 CR4: 00000000000407e0
Stack:
 ffff88080f90bb98 0000000000000000 7ffffffffffffffe ffff88080fdb2c30
 0000000000000200 0000000000000200 0000000000000001 0000000000000200
 ffff88080f90bbc8 ffff88080fdb2c30 ffff88080f90be08 0000000000000200
Call Trace:
 [&lt;ffffffff8112ca9d&gt;] generic_file_direct_write+0xed/0x180
 [&lt;ffffffff8112f2b2&gt;] __generic_file_write_iter+0x222/0x370
 [&lt;ffffffff811f495b&gt;] ext4_file_write_iter+0x34b/0x400
 [&lt;ffffffff811bd709&gt;] ? aio_run_iocb+0x239/0x410
 [&lt;ffffffff811bd709&gt;] ? aio_run_iocb+0x239/0x410
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810abd94&gt;] ? __lock_acquire+0x274/0x700
 [&lt;ffffffff811f4610&gt;] ? ext4_unwritten_wait+0xb0/0xb0
 [&lt;ffffffff811bd756&gt;] aio_run_iocb+0x286/0x410
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810ac359&gt;] ? lock_release_holdtime+0x29/0x190
 [&lt;ffffffff811bc05b&gt;] ? lookup_ioctx+0x4b/0xf0
 [&lt;ffffffff811bde3b&gt;] do_io_submit+0x55b/0x740
 [&lt;ffffffff811bdcaa&gt;] ? do_io_submit+0x3ca/0x740
 [&lt;ffffffff811be030&gt;] SyS_io_submit+0x10/0x20
 [&lt;ffffffff815ce192&gt;] system_call_fastpath+0x16/0x1b
Code: 01 48 8b 80 f0 01 00 00 48 8b 18 49 8b 45 10 0f 85 f1 01 00 00 48 03 45 c8 48 3b 43 48 0f 8f e3 01 00 00 49 83 7c
24 18 00 75 04 &lt;0f&gt; 0b eb fe f0 ff 83 ec 01 00 00 49 8b 44 24 18 8b 00 85 c0 89
RIP  [&lt;ffffffff811fabf2&gt;] ext4_direct_IO+0x162/0x3d0
 RSP &lt;ffff88080f90bb58&gt;

Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: enable journal checksum when metadata checksum feature enabled</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2014-10-30T14:53:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3d7e281b07d4dc9ef18c5bd984e1ba41d8bbd05a'/>
<id>3d7e281b07d4dc9ef18c5bd984e1ba41d8bbd05a</id>
<content type='text'>
commit 98c1a7593fa355fda7f5a5940c8bf5326ca964ba upstream.

If metadata checksumming is turned on for the FS, we need to tell the
journal to use checksumming too.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 98c1a7593fa355fda7f5a5940c8bf5326ca964ba upstream.

If metadata checksumming is turned on for the FS, we need to tell the
journal to use checksumming too.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: fix overflow when updating superblock backups after resize</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2014-10-30T14:52:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c8907b5f04fc1c1d9d1a03238eeb2d7f2b47756c'/>
<id>c8907b5f04fc1c1d9d1a03238eeb2d7f2b47756c</id>
<content type='text'>
commit 9378c6768e4fca48971e7b6a9075bc006eda981d upstream.

When there are no meta block groups update_backups() will compute the
backup block in 32-bit arithmetics thus possibly overflowing the block
number and corrupting the filesystem. OTOH filesystems without meta
block groups larger than 16 TB should be rare. Fix the problem by doing
the counting in 64-bit arithmetics.

Coverity-id: 741252
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Lukas Czerner &lt;lczerner@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9378c6768e4fca48971e7b6a9075bc006eda981d upstream.

When there are no meta block groups update_backups() will compute the
backup block in 32-bit arithmetics thus possibly overflowing the block
number and corrupting the filesystem. OTOH filesystems without meta
block groups larger than 16 TB should be rare. Fix the problem by doing
the counting in 64-bit arithmetics.

Coverity-id: 741252
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Lukas Czerner &lt;lczerner@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: fix oops when loading block bitmap failed</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2014-10-30T14:53:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=34ce60ba58276889897b573e2d1a78e5c2af68e7'/>
<id>34ce60ba58276889897b573e2d1a78e5c2af68e7</id>
<content type='text'>
commit 599a9b77ab289d85c2d5c8607624efbe1f552b0f upstream.

When we fail to load block bitmap in __ext4_new_inode() we will
dereference NULL pointer in ext4_journal_get_write_access(). So check
for error from ext4_read_block_bitmap().

Coverity-id: 989065
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 599a9b77ab289d85c2d5c8607624efbe1f552b0f upstream.

When we fail to load block bitmap in __ext4_new_inode() we will
dereference NULL pointer in ext4_journal_get_write_access(). So check
for error from ext4_read_block_bitmap().

Coverity-id: 989065
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: check s_chksum_driver when looking for bg csum presence</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2014-10-14T06:35:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1e2a3067af88c6829630b64a91a56eee114b9f52'/>
<id>1e2a3067af88c6829630b64a91a56eee114b9f52</id>
<content type='text'>
commit 813d32f91333e4c33d5a19b67167c4bae42dae75 upstream.

Convert the ext4_has_group_desc_csum predicate to look for a checksum
driver instead of the metadata_csum flag and change the bg checksum
calculation function to look for GDT_CSUM before taking the crc16
path.

Without this patch, if we mount with ^uninit_bg,^metadata_csum and
later metadata_csum gets turned on by accident, the block group
checksum functions will incorrectly assume that checksumming is
enabled (metadata_csum) but that crc16 should be used
(!s_chksum_driver).  This is totally wrong, so fix the predicate
and the checksum formula selection.

(Granted, if the metadata_csum feature bit gets enabled on a live FS
then something underhanded is going on, but we could at least avoid
writing garbage into the on-disk fields.)

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 813d32f91333e4c33d5a19b67167c4bae42dae75 upstream.

Convert the ext4_has_group_desc_csum predicate to look for a checksum
driver instead of the metadata_csum flag and change the bg checksum
calculation function to look for GDT_CSUM before taking the crc16
path.

Without this patch, if we mount with ^uninit_bg,^metadata_csum and
later metadata_csum gets turned on by accident, the block group
checksum functions will incorrectly assume that checksumming is
enabled (metadata_csum) but that crc16 should be used
(!s_chksum_driver).  This is totally wrong, so fix the predicate
and the checksum formula selection.

(Granted, if the metadata_csum feature bit gets enabled on a live FS
then something underhanded is going on, but we could at least avoid
writing garbage into the on-disk fields.)

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: move error report out of atomic context in ext4_init_block_bitmap()</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Dmitry Monakhov</name>
<email>dmonakhov@openvz.org</email>
</author>
<published>2014-10-13T07:42:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dcd14a65c2cfdf2adbd8b13a60ae894dbe3ec291'/>
<id>dcd14a65c2cfdf2adbd8b13a60ae894dbe3ec291</id>
<content type='text'>
commit aef4885ae14f1df75b58395c5314d71f613d26d9 upstream.

Error report likely result in IO so it is bad idea to do it from
atomic context.

This patch should fix following issue:

BUG: sleeping function called from invalid context at include/linux/buffer_head.h:349
in_atomic(): 1, irqs_disabled(): 0, pid: 137, name: kworker/u128:1
5 locks held by kworker/u128:1/137:
 #0:  ("writeback"){......}, at: [&lt;ffffffff81085618&gt;] process_one_work+0x228/0x4d0
 #1:  ((&amp;(&amp;wb-&gt;dwork)-&gt;work)){......}, at: [&lt;ffffffff81085618&gt;] process_one_work+0x228/0x4d0
 #2:  (jbd2_handle){......}, at: [&lt;ffffffff81242622&gt;] start_this_handle+0x712/0x7b0
 #3:  (&amp;ei-&gt;i_data_sem){......}, at: [&lt;ffffffff811fa387&gt;] ext4_map_blocks+0x297/0x430
 #4:  (&amp;(&amp;bgl-&gt;locks[i].lock)-&gt;rlock){......}, at: [&lt;ffffffff811f3180&gt;] ext4_read_block_bitmap_nowait+0x5d0/0x630
CPU: 3 PID: 137 Comm: kworker/u128:1 Not tainted 3.17.0-rc2-00184-g82752e4 #165
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
Workqueue: writeback bdi_writeback_workfn (flush-1:0)
 0000000000000411 ffff880813777288 ffffffff815c7fdc ffff880813777288
 ffff880813a8bba0 ffff8808137772a8 ffffffff8108fb30 ffff880803e01e38
 ffff880803e01e38 ffff8808137772c8 ffffffff811a8d53 ffff88080ecc6000
Call Trace:
 [&lt;ffffffff815c7fdc&gt;] dump_stack+0x51/0x6d
 [&lt;ffffffff8108fb30&gt;] __might_sleep+0xf0/0x100
 [&lt;ffffffff811a8d53&gt;] __sync_dirty_buffer+0x43/0xe0
 [&lt;ffffffff811a8e03&gt;] sync_dirty_buffer+0x13/0x20
 [&lt;ffffffff8120f581&gt;] ext4_commit_super+0x1d1/0x230
 [&lt;ffffffff8120fa03&gt;] save_error_info+0x23/0x30
 [&lt;ffffffff8120fd06&gt;] __ext4_error+0xb6/0xd0
 [&lt;ffffffff8120f260&gt;] ? ext4_group_desc_csum+0x140/0x190
 [&lt;ffffffff811f2d8c&gt;] ext4_read_block_bitmap_nowait+0x1dc/0x630
 [&lt;ffffffff8122e23a&gt;] ext4_mb_init_cache+0x21a/0x8f0
 [&lt;ffffffff8113ae95&gt;] ? lru_cache_add+0x55/0x60
 [&lt;ffffffff8112e16c&gt;] ? add_to_page_cache_lru+0x6c/0x80
 [&lt;ffffffff8122eaa0&gt;] ext4_mb_init_group+0x190/0x280
 [&lt;ffffffff8122ec51&gt;] ext4_mb_good_group+0xc1/0x190
 [&lt;ffffffff8123309a&gt;] ext4_mb_regular_allocator+0x17a/0x410
 [&lt;ffffffff8122c821&gt;] ? ext4_mb_use_preallocated+0x31/0x380
 [&lt;ffffffff81233535&gt;] ? ext4_mb_new_blocks+0x205/0x8e0
 [&lt;ffffffff8116ed5c&gt;] ? kmem_cache_alloc+0xfc/0x180
 [&lt;ffffffff812335b0&gt;] ext4_mb_new_blocks+0x280/0x8e0
 [&lt;ffffffff8116f2c4&gt;] ? __kmalloc+0x144/0x1c0
 [&lt;ffffffff81221797&gt;] ? ext4_find_extent+0x97/0x320
 [&lt;ffffffff812257f4&gt;] ext4_ext_map_blocks+0xbc4/0x1050
 [&lt;ffffffff811fa387&gt;] ? ext4_map_blocks+0x297/0x430
 [&lt;ffffffff811fa3ab&gt;] ext4_map_blocks+0x2bb/0x430
 [&lt;ffffffff81200e43&gt;] ? ext4_init_io_end+0x23/0x50
 [&lt;ffffffff811feb44&gt;] ext4_writepages+0x564/0xaf0
 [&lt;ffffffff815cde3b&gt;] ? _raw_spin_unlock+0x2b/0x40
 [&lt;ffffffff810ac7bd&gt;] ? lock_release_non_nested+0x2fd/0x3c0
 [&lt;ffffffff811a009e&gt;] ? writeback_sb_inodes+0x10e/0x490
 [&lt;ffffffff811a009e&gt;] ? writeback_sb_inodes+0x10e/0x490
 [&lt;ffffffff811377e3&gt;] do_writepages+0x23/0x40
 [&lt;ffffffff8119c8ce&gt;] __writeback_single_inode+0x9e/0x280
 [&lt;ffffffff811a026b&gt;] writeback_sb_inodes+0x2db/0x490
 [&lt;ffffffff811a0664&gt;] wb_writeback+0x174/0x2d0
 [&lt;ffffffff810ac359&gt;] ? lock_release_holdtime+0x29/0x190
 [&lt;ffffffff811a0863&gt;] wb_do_writeback+0xa3/0x200
 [&lt;ffffffff811a0a40&gt;] bdi_writeback_workfn+0x80/0x230
 [&lt;ffffffff81085618&gt;] ? process_one_work+0x228/0x4d0
 [&lt;ffffffff810856cd&gt;] process_one_work+0x2dd/0x4d0
 [&lt;ffffffff81085618&gt;] ? process_one_work+0x228/0x4d0
 [&lt;ffffffff81085c1d&gt;] worker_thread+0x35d/0x460
 [&lt;ffffffff810858c0&gt;] ? process_one_work+0x4d0/0x4d0
 [&lt;ffffffff810858c0&gt;] ? process_one_work+0x4d0/0x4d0
 [&lt;ffffffff8108a885&gt;] kthread+0xf5/0x100
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff8108a790&gt;] ? __init_kthread_worker+0x70/0x70
 [&lt;ffffffff815ce2ac&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff8108a790&gt;] ? __init_kthread_work

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit aef4885ae14f1df75b58395c5314d71f613d26d9 upstream.

Error report likely result in IO so it is bad idea to do it from
atomic context.

This patch should fix following issue:

BUG: sleeping function called from invalid context at include/linux/buffer_head.h:349
in_atomic(): 1, irqs_disabled(): 0, pid: 137, name: kworker/u128:1
5 locks held by kworker/u128:1/137:
 #0:  ("writeback"){......}, at: [&lt;ffffffff81085618&gt;] process_one_work+0x228/0x4d0
 #1:  ((&amp;(&amp;wb-&gt;dwork)-&gt;work)){......}, at: [&lt;ffffffff81085618&gt;] process_one_work+0x228/0x4d0
 #2:  (jbd2_handle){......}, at: [&lt;ffffffff81242622&gt;] start_this_handle+0x712/0x7b0
 #3:  (&amp;ei-&gt;i_data_sem){......}, at: [&lt;ffffffff811fa387&gt;] ext4_map_blocks+0x297/0x430
 #4:  (&amp;(&amp;bgl-&gt;locks[i].lock)-&gt;rlock){......}, at: [&lt;ffffffff811f3180&gt;] ext4_read_block_bitmap_nowait+0x5d0/0x630
CPU: 3 PID: 137 Comm: kworker/u128:1 Not tainted 3.17.0-rc2-00184-g82752e4 #165
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
Workqueue: writeback bdi_writeback_workfn (flush-1:0)
 0000000000000411 ffff880813777288 ffffffff815c7fdc ffff880813777288
 ffff880813a8bba0 ffff8808137772a8 ffffffff8108fb30 ffff880803e01e38
 ffff880803e01e38 ffff8808137772c8 ffffffff811a8d53 ffff88080ecc6000
Call Trace:
 [&lt;ffffffff815c7fdc&gt;] dump_stack+0x51/0x6d
 [&lt;ffffffff8108fb30&gt;] __might_sleep+0xf0/0x100
 [&lt;ffffffff811a8d53&gt;] __sync_dirty_buffer+0x43/0xe0
 [&lt;ffffffff811a8e03&gt;] sync_dirty_buffer+0x13/0x20
 [&lt;ffffffff8120f581&gt;] ext4_commit_super+0x1d1/0x230
 [&lt;ffffffff8120fa03&gt;] save_error_info+0x23/0x30
 [&lt;ffffffff8120fd06&gt;] __ext4_error+0xb6/0xd0
 [&lt;ffffffff8120f260&gt;] ? ext4_group_desc_csum+0x140/0x190
 [&lt;ffffffff811f2d8c&gt;] ext4_read_block_bitmap_nowait+0x1dc/0x630
 [&lt;ffffffff8122e23a&gt;] ext4_mb_init_cache+0x21a/0x8f0
 [&lt;ffffffff8113ae95&gt;] ? lru_cache_add+0x55/0x60
 [&lt;ffffffff8112e16c&gt;] ? add_to_page_cache_lru+0x6c/0x80
 [&lt;ffffffff8122eaa0&gt;] ext4_mb_init_group+0x190/0x280
 [&lt;ffffffff8122ec51&gt;] ext4_mb_good_group+0xc1/0x190
 [&lt;ffffffff8123309a&gt;] ext4_mb_regular_allocator+0x17a/0x410
 [&lt;ffffffff8122c821&gt;] ? ext4_mb_use_preallocated+0x31/0x380
 [&lt;ffffffff81233535&gt;] ? ext4_mb_new_blocks+0x205/0x8e0
 [&lt;ffffffff8116ed5c&gt;] ? kmem_cache_alloc+0xfc/0x180
 [&lt;ffffffff812335b0&gt;] ext4_mb_new_blocks+0x280/0x8e0
 [&lt;ffffffff8116f2c4&gt;] ? __kmalloc+0x144/0x1c0
 [&lt;ffffffff81221797&gt;] ? ext4_find_extent+0x97/0x320
 [&lt;ffffffff812257f4&gt;] ext4_ext_map_blocks+0xbc4/0x1050
 [&lt;ffffffff811fa387&gt;] ? ext4_map_blocks+0x297/0x430
 [&lt;ffffffff811fa3ab&gt;] ext4_map_blocks+0x2bb/0x430
 [&lt;ffffffff81200e43&gt;] ? ext4_init_io_end+0x23/0x50
 [&lt;ffffffff811feb44&gt;] ext4_writepages+0x564/0xaf0
 [&lt;ffffffff815cde3b&gt;] ? _raw_spin_unlock+0x2b/0x40
 [&lt;ffffffff810ac7bd&gt;] ? lock_release_non_nested+0x2fd/0x3c0
 [&lt;ffffffff811a009e&gt;] ? writeback_sb_inodes+0x10e/0x490
 [&lt;ffffffff811a009e&gt;] ? writeback_sb_inodes+0x10e/0x490
 [&lt;ffffffff811377e3&gt;] do_writepages+0x23/0x40
 [&lt;ffffffff8119c8ce&gt;] __writeback_single_inode+0x9e/0x280
 [&lt;ffffffff811a026b&gt;] writeback_sb_inodes+0x2db/0x490
 [&lt;ffffffff811a0664&gt;] wb_writeback+0x174/0x2d0
 [&lt;ffffffff810ac359&gt;] ? lock_release_holdtime+0x29/0x190
 [&lt;ffffffff811a0863&gt;] wb_do_writeback+0xa3/0x200
 [&lt;ffffffff811a0a40&gt;] bdi_writeback_workfn+0x80/0x230
 [&lt;ffffffff81085618&gt;] ? process_one_work+0x228/0x4d0
 [&lt;ffffffff810856cd&gt;] process_one_work+0x2dd/0x4d0
 [&lt;ffffffff81085618&gt;] ? process_one_work+0x228/0x4d0
 [&lt;ffffffff81085c1d&gt;] worker_thread+0x35d/0x460
 [&lt;ffffffff810858c0&gt;] ? process_one_work+0x4d0/0x4d0
 [&lt;ffffffff810858c0&gt;] ? process_one_work+0x4d0/0x4d0
 [&lt;ffffffff8108a885&gt;] kthread+0xf5/0x100
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff8108a790&gt;] ? __init_kthread_worker+0x70/0x70
 [&lt;ffffffff815ce2ac&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff8108a790&gt;] ? __init_kthread_work

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: Replace open coded mdata csum feature to helper function</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Dmitry Monakhov</name>
<email>dmonakhov@openvz.org</email>
</author>
<published>2014-10-13T07:36:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2b3b37b28739a07d9daf8a5e8d2415cbc4df1022'/>
<id>2b3b37b28739a07d9daf8a5e8d2415cbc4df1022</id>
<content type='text'>
commit 9aa5d32ba269bec0e7eaba2697a986a7b0bc8528 upstream.

Besides the fact that this replacement improves code readability
it also protects from errors caused direct EXT4_S(sb)-&gt;s_es manipulation
which may result attempt to use uninitialized  csum machinery.

#Testcase_BEGIN
IMG=/dev/ram0
MNT=/mnt
mkfs.ext4 $IMG
mount $IMG $MNT
#Enable feature directly on disk, on mounted fs
tune2fs -O metadata_csum  $IMG
# Provoke metadata update, likey result in OOPS
touch $MNT/test
umount $MNT
#Testcase_END

# Replacement script
@@
expression E;
@@
- EXT4_HAS_RO_COMPAT_FEATURE(E, EXT4_FEATURE_RO_COMPAT_METADATA_CSUM)
+ ext4_has_metadata_csum(E)

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

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9aa5d32ba269bec0e7eaba2697a986a7b0bc8528 upstream.

Besides the fact that this replacement improves code readability
it also protects from errors caused direct EXT4_S(sb)-&gt;s_es manipulation
which may result attempt to use uninitialized  csum machinery.

#Testcase_BEGIN
IMG=/dev/ram0
MNT=/mnt
mkfs.ext4 $IMG
mount $IMG $MNT
#Enable feature directly on disk, on mounted fs
tune2fs -O metadata_csum  $IMG
# Provoke metadata update, likey result in OOPS
touch $MNT/test
umount $MNT
#Testcase_END

# Replacement script
@@
expression E;
@@
- EXT4_HAS_RO_COMPAT_FEATURE(E, EXT4_FEATURE_RO_COMPAT_METADATA_CSUM)
+ ext4_has_metadata_csum(E)

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

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: fix reservation overflow in ext4_da_write_begin</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Eric Sandeen</name>
<email>sandeen@redhat.com</email>
</author>
<published>2014-10-11T23:51:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a1d6b55a49da98f92ffecb44909d5847dcac506d'/>
<id>a1d6b55a49da98f92ffecb44909d5847dcac506d</id>
<content type='text'>
commit 0ff8947fc5f700172b37cbca811a38eb9cb81e08 upstream.

Delalloc write journal reservations only reserve 1 credit,
to update the inode if necessary.  However, it may happen
once in a filesystem's lifetime that a file will cross
the 2G threshold, and require the LARGE_FILE feature to
be set in the superblock as well, if it was not set already.

This overruns the transaction reservation, and can be
demonstrated simply on any ext4 filesystem without the LARGE_FILE
feature already set:

dd if=/dev/zero of=testfile bs=1 seek=2147483646 count=1 \
	conv=notrunc of=testfile
sync
dd if=/dev/zero of=testfile bs=1 seek=2147483647 count=1 \
	conv=notrunc of=testfile

leads to:

EXT4-fs: ext4_do_update_inode:4296: aborting transaction: error 28 in __ext4_handle_dirty_super
EXT4-fs error (device loop0) in ext4_do_update_inode:4301: error 28
EXT4-fs error (device loop0) in ext4_reserve_inode_write:4757: Readonly filesystem
EXT4-fs error (device loop0) in ext4_dirty_inode:4876: error 28
EXT4-fs error (device loop0) in ext4_da_write_end:2685: error 28

Adjust the number of credits based on whether the flag is
already set, and whether the current write may extend past the
LARGE_FILE limit.

Signed-off-by: Eric Sandeen &lt;sandeen@redhat.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Andreas Dilger &lt;adilger@dilger.ca&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0ff8947fc5f700172b37cbca811a38eb9cb81e08 upstream.

Delalloc write journal reservations only reserve 1 credit,
to update the inode if necessary.  However, it may happen
once in a filesystem's lifetime that a file will cross
the 2G threshold, and require the LARGE_FILE feature to
be set in the superblock as well, if it was not set already.

This overruns the transaction reservation, and can be
demonstrated simply on any ext4 filesystem without the LARGE_FILE
feature already set:

dd if=/dev/zero of=testfile bs=1 seek=2147483646 count=1 \
	conv=notrunc of=testfile
sync
dd if=/dev/zero of=testfile bs=1 seek=2147483647 count=1 \
	conv=notrunc of=testfile

leads to:

EXT4-fs: ext4_do_update_inode:4296: aborting transaction: error 28 in __ext4_handle_dirty_super
EXT4-fs error (device loop0) in ext4_do_update_inode:4301: error 28
EXT4-fs error (device loop0) in ext4_reserve_inode_write:4757: Readonly filesystem
EXT4-fs error (device loop0) in ext4_dirty_inode:4876: error 28
EXT4-fs error (device loop0) in ext4_da_write_end:2685: error 28

Adjust the number of credits based on whether the flag is
already set, and whether the current write may extend past the
LARGE_FILE limit.

Signed-off-by: Eric Sandeen &lt;sandeen@redhat.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Andreas Dilger &lt;adilger@dilger.ca&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: don't orphan or truncate the boot loader inode</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-10-06T02:47:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5be56bf0f1040b9b05cc3fc1ed0e9e4816385c74'/>
<id>5be56bf0f1040b9b05cc3fc1ed0e9e4816385c74</id>
<content type='text'>
commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.

The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5.  In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.

Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure.  This means the
in-memory orphan list is corrupted, leading to a kernel oops.

In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.

Reported-by: Sami Liedes &lt;sami.liedes@iki.fi&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.

The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5.  In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.

Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure.  This means the
in-memory orphan list is corrupted, leading to a kernel oops.

In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.

Reported-by: Sami Liedes &lt;sami.liedes@iki.fi&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: add ext4_iget_normal() which is to be used for dir tree lookups</title>
<updated>2014-11-14T18:10:30+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-10-06T02:56:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=207c775cb6c23f2ae887a058f0563344773f77ae'/>
<id>207c775cb6c23f2ae887a058f0563344773f77ae</id>
<content type='text'>
commit f4bb2981024fc91b23b4d09a8817c415396dbabb upstream.

If there is a corrupted file system which has directory entries that
point at reserved, metadata inodes, prohibit them from being used by
treating them the same way we treat Boot Loader inodes --- that is,
mark them to be bad inodes.  This prohibits them from being opened,
deleted, or modified via chmod, chown, utimes, etc.

In particular, this prevents a corrupted file system which has a
directory entry which points at the journal inode from being deleted
and its blocks released, after which point Much Hilarity Ensues.

Reported-by: Sami Liedes &lt;sami.liedes@iki.fi&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f4bb2981024fc91b23b4d09a8817c415396dbabb upstream.

If there is a corrupted file system which has directory entries that
point at reserved, metadata inodes, prohibit them from being used by
treating them the same way we treat Boot Loader inodes --- that is,
mark them to be bad inodes.  This prohibits them from being opened,
deleted, or modified via chmod, chown, utimes, etc.

In particular, this prevents a corrupted file system which has a
directory entry which points at the journal inode from being deleted
and its blocks released, after which point Much Hilarity Ensues.

Reported-by: Sami Liedes &lt;sami.liedes@iki.fi&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
