linux-toradex.git/fs, branch v4.1.21

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

2016-03-23T14:20:24+00:00

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.

Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Mingming Cao 
Signed-off-by: Sasha Levin

ext4: fix races between buffered IO and collapse / insert range

2016-03-23T14:20:24+00:00

Current code implementing FALLOC_FL_COLLAPSE_RANGE and
FALLOC_FL_INSERT_RANGE is prone to races with buffered writes and page
faults. If buffered write or write via mmap manages to squeeze between
filemap_write_and_wait_range() and truncate_pagecache() in the fallocate
implementations, the written data is simply discarded by
truncate_pagecache() although it should have been shifted.

Fix the problem by moving filemap_write_and_wait_range() call inside
i_mutex and i_mmap_sem. That way we are protected against races with
both buffered writes and page faults.

Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Mingming Cao 
Signed-off-by: Sasha Levin

ext4: move unlocked dio protection from ext4_alloc_file_blocks()

2016-03-23T14:20:24+00:00

Currently ext4_alloc_file_blocks() was handling protection against
unlocked DIO. However we now need to sometimes call it under i_mmap_sem
and sometimes not and DIO protection ranks above it (although strictly
speaking this cannot currently create any deadlocks). Also
ext4_zero_range() was actually getting & releasing unlocked DIO
protection twice in some cases. Luckily it didn't introduce any real bug
but it was a land mine waiting to be stepped on.  So move DIO protection
out from ext4_alloc_file_blocks() into the two callsites.

Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Mingming Cao 
Signed-off-by: Sasha Levin

ext4: fix races between page faults and hole punching

2016-03-23T14:20:24+00:00

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.

Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Mingming Cao 
Signed-off-by: Sasha Levin

jffs2: reduce the breakage on recovery from halfway failed rename()

2016-03-22T15:10:30+00:00

[ Upstream commit f93812846f31381d35c04c6c577d724254355e7f ]

d_instantiate(new_dentry, old_inode) is absolutely wrong thing to
do - it will oops if new_dentry used to be positive, for starters.
What we need is d_invalidate() the target and be done with that.

Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

ncpfs: fix a braino in OOM handling in ncp_fill_cache()

2016-03-22T15:10:30+00:00

[ Upstream commit 803c00123a8012b3a283c0530910653973ef6d8f ]

Failing to allocate an inode for child means that cache for *parent* is
incompletely populated.  So it's parent directory inode ('dir') that
needs NCPI_DIR_CACHE flag removed, *not* the child inode ('inode', which
is what we'd failed to allocate in the first place).

Fucked-up-in: commit 5e993e25 ("ncpfs: get rid of d_validate() nonsense")
Fucked-up-by: Al Viro 
Cc: stable@vger.kernel.org # v3.19
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

ovl: copy new uid/gid into overlayfs runtime inode

2016-03-22T15:10:27+00:00

[ Upstream commit b81de061fa59f17d2730aabb1b84419ef3913810 ]

Overlayfs must update uid/gid after chown, otherwise functions
like inode_owner_or_capable() will check user against stale uid.
Catched by xfstests generic/087, it chowns file and calls utimes.

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

ovl: ignore lower entries when checking purity of non-directory entries

2016-03-22T15:10:27+00:00

[ Upstream commit 45d11738969633ec07ca35d75d486bf2d8918df6 ]

After rename file dentry still holds reference to lower dentry from
previous location. This doesn't matter for data access because data comes
from upper dentry. But this stale lower dentry taints dentry at new
location and turns it into non-pure upper. Such file leaves visible
whiteout entry after remove in directory which shouldn't have whiteouts at
all.

Overlayfs already tracks pureness of file location in oe->opaque.  This
patch just uses that for detecting actual path type.

Comment from Vivek Goyal's patch:

Here are the details of the problem. Do following.

$ mkdir upper lower work merged upper/dir/
$ touch lower/test
$ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=
work merged
$ mv merged/test merged/dir/
$ rm merged/dir/test
$ ls -l merged/dir/
/usr/bin/ls: cannot access merged/dir/test: No such file or directory
total 0
c????????? ? ? ? ?            ? test

Basic problem seems to be that once a file has been unlinked, a whiteout
has been left behind which was not needed and hence it becomes visible.

Whiteout is visible because parent dir is of not type MERGE, hence
od->is_real is set during ovl_dir_open(). And that means ovl_iterate()
passes on iterate handling directly to underlying fs. Underlying fs does
not know/filter whiteouts so it becomes visible to user.

Why did we leave a whiteout to begin with when we should not have.
ovl_do_remove() checks for OVL_TYPE_PURE_UPPER() and does not leave
whiteout if file is pure upper. In this case file is not found to be pure
upper hence whiteout is left.

So why file was not PURE_UPPER in this case? I think because dentry is
still carrying some leftover state which was valid before rename. For
example, od->numlower was set to 1 as it was a lower file. After rename,
this state is not valid anymore as there is no such file in lower.

Signed-off-by: Konstantin Khlebnikov 
Reported-by: Viktor Stanchev 
Suggested-by: Vivek Goyal 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=109611
Acked-by: Vivek Goyal 
Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

ovl: fix getcwd() failure after unsuccessful rmdir

2016-03-22T15:10:26+00:00

[ Upstream commit ce9113bbcbf45a57c082d6603b9a9f342be3ef74 ]

ovl_remove_upper() should do d_drop() only after it successfully
removes the dir, otherwise a subsequent getcwd() system call will
fail, breaking userspace programs.

This is to fix: https://bugzilla.kernel.org/show_bug.cgi?id=110491

Signed-off-by: Rui Wang 
Reviewed-by: Konstantin Khlebnikov 
Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

use ->d_seq to get coherency between ->d_inode and ->d_flags

2016-03-09T18:15:20+00:00

[ Upstream commit a528aca7f359f4b0b1d72ae406097e491a5ba9ea ]

Games with ordering and barriers are way too brittle.  Just
bump ->d_seq before and after updating ->d_inode and ->d_flags
type bits, so that verifying ->d_seq would guarantee they are
coherent.

Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin