<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pm24.git/fs/ext4/namei.c, branch v4.7</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://git.kobert.dev/pm24.git/atom?h=v4.7</id>
<link rel='self' href='https://git.kobert.dev/pm24.git/atom?h=v4.7'/>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/'/>
<updated>2016-05-24T19:55:26Z</updated>
<entry>
<title>Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4</title>
<updated>2016-05-24T19:55:26Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-05-24T19:55:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=0e01df100b6bf22a1de61b66657502a6454153c5'/>
<id>urn:sha1:0e01df100b6bf22a1de61b66657502a6454153c5</id>
<content type='text'>
Pull ext4 updates from Ted Ts'o:
 "Fix a number of bugs, most notably a potential stale data exposure
  after a crash and a potential BUG_ON crash if a file has the data
  journalling flag enabled while it has dirty delayed allocation blocks
  that haven't been written yet.  Also fix a potential crash in the new
  project quota code and a maliciously corrupted file system.

  In addition, fix some DAX-specific bugs, including when there is a
  transient ENOSPC situation and races between writes via direct I/O and
  an mmap'ed segment that could lead to lost I/O.

  Finally the usual set of miscellaneous cleanups"

* tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (23 commits)
  ext4: pre-zero allocated blocks for DAX IO
  ext4: refactor direct IO code
  ext4: fix race in transient ENOSPC detection
  ext4: handle transient ENOSPC properly for DAX
  dax: call get_blocks() with create == 1 for write faults to unwritten extents
  ext4: remove unmeetable inconsisteny check from ext4_find_extent()
  jbd2: remove excess descriptions for handle_s
  ext4: remove unnecessary bio get/put
  ext4: silence UBSAN in ext4_mb_init()
  ext4: address UBSAN warning in mb_find_order_for_block()
  ext4: fix oops on corrupted filesystem
  ext4: fix check of dqget() return value in ext4_ioctl_setproject()
  ext4: clean up error handling when orphan list is corrupted
  ext4: fix hang when processing corrupted orphaned inode list
  ext4: remove trailing \n from ext4_warning/ext4_error calls
  ext4: fix races between changing inode journal mode and ext4_writepages
  ext4: handle unwritten or delalloc buffers before enabling data journaling
  ext4: fix jbd2 handle extension in ext4_ext_truncate_extend_restart()
  ext4: do not ask jbd2 to write data for delalloc buffers
  jbd2: add support for avoiding data writes during transaction commits
  ...
</content>
</entry>
<entry>
<title>ext4: fix oops on corrupted filesystem</title>
<updated>2016-05-05T15:10:15Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2016-05-05T15:10:15Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=74177f55b70e2f2be770dd28684dd6d17106a4ba'/>
<id>urn:sha1:74177f55b70e2f2be770dd28684dd6d17106a4ba</id>
<content type='text'>
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(&amp;EXT4_I(inode)-&gt;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-&gt;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:
 [&lt;6005769c&gt;] ? vprintk_emit+0x2dc/0x5c0
 [&lt;602ede24&gt;] ? printk+0x0/0x94
 [&lt;600190bc&gt;] show_stack+0xdc/0x1a0
 [&lt;602ede24&gt;] ? printk+0x0/0x94
 [&lt;602ede24&gt;] ? printk+0x0/0x94
 [&lt;602f02eb&gt;] dump_stack+0x2a/0x2c
 [&lt;6002c12c&gt;] warn_slowpath_common+0x9c/0xf0
 [&lt;601b4d6b&gt;] ? __list_del_entry+0x6b/0x100
 [&lt;6002c254&gt;] warn_slowpath_fmt+0x94/0xa0
 [&lt;602f4d09&gt;] ? __mutex_lock_slowpath+0x239/0x3a0
 [&lt;6002c1c0&gt;] ? warn_slowpath_fmt+0x0/0xa0
 [&lt;60023ebf&gt;] ? set_signals+0x3f/0x50
 [&lt;600a205a&gt;] ? kmem_cache_free+0x10a/0x180
 [&lt;602f4e88&gt;] ? mutex_lock+0x18/0x30
 [&lt;601b4d6b&gt;] __list_del_entry+0x6b/0x100
 [&lt;601177ec&gt;] ext4_orphan_del+0x22c/0x2f0
 [&lt;6012f27c&gt;] ? __ext4_journal_start_sb+0x2c/0xa0
 [&lt;6010b973&gt;] ? ext4_truncate+0x383/0x390
 [&lt;6010bc8b&gt;] ext4_write_begin+0x30b/0x4b0
 [&lt;6001bb50&gt;] ? copy_from_user+0x0/0xb0
 [&lt;601aa840&gt;] ? iov_iter_fault_in_readable+0xa0/0xc0
 [&lt;60072c4f&gt;] generic_perform_write+0xaf/0x1e0
 [&lt;600c4166&gt;] ? file_update_time+0x46/0x110
 [&lt;60072f0f&gt;] __generic_file_write_iter+0x18f/0x1b0
 [&lt;6010030f&gt;] ext4_file_write_iter+0x15f/0x470
 [&lt;60094e10&gt;] ? unlink_file_vma+0x0/0x70
 [&lt;6009b180&gt;] ? unlink_anon_vmas+0x0/0x260
 [&lt;6008f169&gt;] ? free_pgtables+0xb9/0x100
 [&lt;600a6030&gt;] __vfs_write+0xb0/0x130
 [&lt;600a61d5&gt;] vfs_write+0xa5/0x170
 [&lt;600a63d6&gt;] SyS_write+0x56/0xe0
 [&lt;6029fcb0&gt;] ? __libc_waitpid+0x0/0xa0
 [&lt;6001b698&gt;] handle_syscall+0x68/0x90
 [&lt;6002633d&gt;] userspace+0x4fd/0x600
 [&lt;6002274f&gt;] ? save_registers+0x1f/0x40
 [&lt;60028bd7&gt;] ? arch_prctl+0x177/0x1b0
 [&lt;60017bd5&gt;] fork_handler+0x85/0x90

Fix the problem by using list_del_init() as we always should with
i_orphan list.

CC: stable@vger.kernel.org
Reported-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: remove trailing \n from ext4_warning/ext4_error calls</title>
<updated>2016-04-27T05:11:21Z</updated>
<author>
<name>Jakub Wilk</name>
<email>jwilk@jwilk.net</email>
</author>
<published>2016-04-27T05:11:21Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=8d2ae1cbe8a984d7a755755fb53955de2f60a2f9'/>
<id>urn:sha1:8d2ae1cbe8a984d7a755755fb53955de2f60a2f9</id>
<content type='text'>
Messages passed to ext4_warning() or ext4_error() don't need trailing
newlines, because these function add the newlines themselves.

Signed-off-by: Jakub Wilk &lt;jwilk@jwilk.net&gt;
</content>
</entry>
<entry>
<title>ext4: allow readdir()'s of large empty directories to be interrupted</title>
<updated>2016-04-24T02:50:07Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2016-04-24T02:50:07Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=1f60fbe7274918adb8db2f616e321890730ab7e3'/>
<id>urn:sha1:1f60fbe7274918adb8db2f616e321890730ab7e3</id>
<content type='text'>
If a directory has a large number of empty blocks, iterating over all
of them can take a long time, leading to scheduler warnings and users
getting irritated when they can't kill a process in the middle of one
of these long-running readdir operations.  Fix this by adding checks to
ext4_readdir() and ext4_htree_fill_tree().

This was reverted earlier due to a typo in the original commit where I
experimented with using signal_pending() instead of
fatal_signal_pending().  The test was in the wrong place if we were
going to return signal_pending() since we would end up returning
duplicant entries.  See 9f2394c9be47 for a more detailed explanation.

Added fix as suggested by Linus to check for signal_pending() in
in the filldir() functions.

Reported-by: Benjamin LaHaise &lt;bcrl@kvack.org&gt;
Google-Bug-Id: 27880676
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>Revert "ext4: allow readdir()'s of large empty directories to be interrupted"</title>
<updated>2016-04-10T23:52:24Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-04-10T23:52:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=9f2394c9be47a754bae9e4b6d382bdd4d77d0a11'/>
<id>urn:sha1:9f2394c9be47a754bae9e4b6d382bdd4d77d0a11</id>
<content type='text'>
This reverts commit 1028b55bafb7611dda1d8fed2aeca16a436b7dff.

It's broken: it makes ext4 return an error at an invalid point, causing
the readdir wrappers to write the the position of the last successful
directory entry into the position field, which means that the next
readdir will now return that last successful entry _again_.

You can only return fatal errors (that terminate the readdir directory
walk) from within the filesystem readdir functions, the "normal" errors
(that happen when the readdir buffer fills up, for example) happen in
the iterorator where we know the position of the actual failing entry.

I do have a very different patch that does the "signal_pending()"
handling inside the iterator function where it is allowable, but while
that one passes all the sanity checks, I screwed up something like four
times while emailing it out, so I'm not going to commit it today.

So my track record is not good enough, and the stars will have to align
better before that one gets committed.  And it would be good to get some
review too, of course, since celestial alignments are always an iffy
debugging model.

IOW, let's just revert the commit that caused the problem for now.

Reported-by: Greg Thelen &lt;gthelen@google.com&gt;
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>don't bother with -&gt;d_inode-&gt;i_sb - it's always equal to -&gt;d_sb</title>
<updated>2016-04-10T21:11:51Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2016-04-10T05:33:30Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=fc64005c93090c052637f63578d810b037abb1a1'/>
<id>urn:sha1:fc64005c93090c052637f63578d810b037abb1a1</id>
<content type='text'>
... and neither can ever be NULL

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ext4: allow readdir()'s of large empty directories to be interrupted</title>
<updated>2016-03-31T02:36:24Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2016-03-31T02:36:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=1028b55bafb7611dda1d8fed2aeca16a436b7dff'/>
<id>urn:sha1:1028b55bafb7611dda1d8fed2aeca16a436b7dff</id>
<content type='text'>
If a directory has a large number of empty blocks, iterating over all
of them can take a long time, leading to scheduler warnings and users
getting irritated when they can't kill a process in the middle of one
of these long-running readdir operations.  Fix this by adding checks to
ext4_readdir() and ext4_htree_fill_tree().

Reported-by: Benjamin LaHaise &lt;bcrl@kvack.org&gt;
Google-Bug-Id: 27880676
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4 crypto: move context consistency check to ext4_file_open()</title>
<updated>2016-02-08T05:54:26Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2016-02-08T05:54:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=ff978b09f973db0d0597704eba350a994d7729e6'/>
<id>urn:sha1:ff978b09f973db0d0597704eba350a994d7729e6</id>
<content type='text'>
In the case where the per-file key for the directory is cached, but
root does not have access to the key needed to derive the per-file key
for the files in the directory, we allow the lookup to succeed, so
that lstat(2) and unlink(2) can suceed.  However, if a program tries
to open the file, it will get an ENOKEY error.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4 crypto: revalidate dentry after adding or removing the key</title>
<updated>2016-02-08T00:35:05Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2016-02-08T00:35:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=28b4c263961c47da84ed8b5be0b5116bad1133eb'/>
<id>urn:sha1:28b4c263961c47da84ed8b5be0b5116bad1133eb</id>
<content type='text'>
Add a validation check for dentries for encrypted directory to make
sure we're not caching stale data after a key has been added or removed.

Also check to make sure that status of the encryption key is updated
when readdir(2) is executed.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;

</content>
</entry>
<entry>
<title>wrappers for -&gt;i_mutex access</title>
<updated>2016-01-22T23:04:28Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2016-01-22T20:40:57Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=5955102c9984fa081b2d570cfac75c97eecf8f3b'/>
<id>urn:sha1:5955102c9984fa081b2d570cfac75c97eecf8f3b</id>
<content type='text'>
parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
inode_foo(inode) being mutex_foo(&amp;inode-&gt;i_mutex).

Please, use those for access to -&gt;i_mutex; over the coming cycle
-&gt;i_mutex will become rwsem, with -&gt;lookup() done with it held
only shared.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
</feed>
