linux-stable.git/fs, branch v3.2.76

ocfs2: fix BUG when calculate new backup super

2016-01-22T21:40:08+00:00

commit 5c9ee4cbf2a945271f25b89b137f2c03bbc3be33 upstream.

When resizing, it firstly extends the last gd.  Once it should backup
super in the gd, it calculates new backup super and update the
corresponding value.

But it currently doesn't consider the situation that the backup super is
already done.  And in this case, it still sets the bit in gd bitmap and
then decrease from bg_free_bits_count, which leads to a corrupted gd and
trigger the BUG in ocfs2_block_group_set_bits:

    BUG_ON(le16_to_cpu(bg->bg_free_bits_count) < num_bits);

So check whether the backup super is done and then do the updates.

Signed-off-by: Joseph Qi 
Reviewed-by: Jiufei Xue 
Reviewed-by: Yiwen Jiang 
Cc: Mark Fasheh 
Cc: Joel Becker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

9p: ->evict_inode() should kick out ->i_data, not ->i_mapping

2015-12-30T02:26:00+00:00

commit 4ad78628445d26e5e9487b2e8f23274ad7b0f5d3 upstream.

For block devices the pagecache is associated with the inode
on bdevfs, not with the aliasing ones on the mountable filesystems.
The latter have its own ->i_data empty and ->i_mapping pointing
to the (unique per major/minor) bdevfs inode.  That guarantees
cache coherence between all block device inodes with the same
device number.

Eviction of an alias inode has no business trying to evict the
pages belonging to bdevfs one; moreover, ->i_mapping is only
safe to access when the thing is opened.  At the time of
->evict_inode() the victim is definitely *not* opened.  We are
about to kill the address space embedded into struct inode
(inode->i_data) and that's what we need to empty of any pages.

9p instance tries to empty inode->i_mapping instead, which is
both unsafe and bogus - if we have several device nodes with
the same device number in different places, closing one of them
should not try to empty the (shared) page cache.

Fortunately, other instances in the tree are OK; they are
evicting from &inode->i_data instead, as 9p one should.

Reported-by: "Suzuki K. Poulose" 
Tested-by: "Suzuki K. Poulose" 
Signed-off-by: Al Viro 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

nfs: if we have no valid attrs, then don't declare the attribute cache valid

2015-12-30T02:25:58+00:00

commit c812012f9ca7cf89c9e1a1cd512e6c3b5be04b85 upstream.

If we pass in an empty nfs_fattr struct to nfs_update_inode, it will
(correctly) not update any of the attributes, but it then clears the
NFS_INO_INVALID_ATTR flag, which indicates that the attributes are
up to date. Don't clear the flag if the fattr struct has no valid
attrs to apply.

Reviewed-by: Steve French 
Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

jbd2: Fix unreclaimed pages after truncate in data=journal mode

2015-12-30T02:25:58+00:00

commit bc23f0c8d7ccd8d924c4e70ce311288cb3e61ea8 upstream.

Ted and Namjae have reported that truncated pages don't get timely
reclaimed after being truncated in data=journal mode. The following test
triggers the issue easily:

for (i = 0; i < 1000; i++) {
	pwrite(fd, buf, 1024*1024, 0);
	fsync(fd);
	fsync(fd);
	ftruncate(fd, 0);
}

The reason is that journal_unmap_buffer() finds that truncated buffers
are not journalled (jh->b_transaction == NULL), they are part of
checkpoint list of a transaction (jh->b_cp_transaction != NULL) and have
been already written out (!buffer_dirty(bh)). We clean such buffers but
we leave them in the checkpoint list. Since checkpoint transaction holds
a reference to the journal head, these buffers cannot be released until
the checkpoint transaction is cleaned up. And at that point we don't
call release_buffer_page() anymore so pages detached from mapping are
lingering in the system waiting for reclaim to find them and free them.

Fix the problem by removing buffers from transaction checkpoint lists
when journal_unmap_buffer() finds out they don't have to be there
anymore.

Reported-and-tested-by: Namjae Jeon 
Fixes: de1b794130b130e77ffa975bb58cb843744f9ae5
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Ben Hutchings

ext4: Fix handling of extended tv_sec

2015-12-30T02:25:58+00:00

commit a4dad1ae24f850410c4e60f22823cba1289b8d52 upstream.

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.

Signed-off-by: David Turner 
Signed-off-by: Theodore Ts'o 
Reported-by: Mark Harris 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23732
Signed-off-by: Ben Hutchings

vfs: Avoid softlockups with sendfile(2)

2015-12-30T02:25:58+00:00

commit c2489e07c0a71a56fb2c84bc0ee66cddfca7d068 upstream.

The following test program from Dmitry can cause softlockups or RCU
stalls as it copies 1GB from tmpfs into eventfd and we don't have any
scheduling point at that path in sendfile(2) implementation:

        int r1 = eventfd(0, 0);
        int r2 = memfd_create("", 0);
        unsigned long n = 1<<30;
        fallocate(r2, 0, 0, n);
        sendfile(r1, r2, 0, n);

Add cond_resched() into __splice_from_pipe() to fix the problem.

CC: Dmitry Vyukov 
Signed-off-by: Jan Kara 
Signed-off-by: Al Viro 
Signed-off-by: Ben Hutchings

vfs: Make sendfile(2) killable even better

2015-12-30T02:25:58+00:00

commit c725bfce7968009756ed2836a8cd7ba4dc163011 upstream.

Commit 296291cdd162 (mm: make sendfile(2) killable) fixed an issue where
sendfile(2) was doing a lot of tiny writes into a filesystem and thus
was unkillable for a long time. However sendfile(2) can be (mis)used to
issue lots of writes into arbitrary file descriptor such as evenfd or
similar special file descriptors which never hit the standard filesystem
write path and thus are still unkillable. E.g. the following example
from Dmitry burns CPU for ~16s on my test system without possibility to
be killed:

        int r1 = eventfd(0, 0);
        int r2 = memfd_create("", 0);
        unsigned long n = 1<<30;
        fallocate(r2, 0, 0, n);
        sendfile(r1, r2, 0, n);

There are actually quite a few tests for pending signals in sendfile
code however we data to write is always available none of them seems to
trigger. So fix the problem by adding a test for pending signal into
splice_from_pipe_next() also before the loop waiting for pipe buffers to
be available. This should fix all the lockup issues with sendfile of the
do-ton-of-tiny-writes nature.

Reported-by: Dmitry Vyukov 
Signed-off-by: Jan Kara 
Signed-off-by: Al Viro 
Signed-off-by: Ben Hutchings

fix sysvfs symlinks

2015-12-30T02:25:57+00:00

commit 0ebf7f10d67a70e120f365018f1c5fce9ddc567d upstream.

The thing got broken back in 2002 - sysvfs does *not* have inline
symlinks; even short ones have bodies stored in the first block
of file.  sysv_symlink() handles that correctly; unfortunately,
attempting to look an existing symlink up will end up confusing
them for inline symlinks, and interpret the block number containing
the body as the body itself.

Nobody has noticed until now, which says something about the level
of testing sysvfs gets ;-/

Signed-off-by: Al Viro 
[bwh: Backported to 3.2:
 - Adjust context
 - Also delete unused sysv_fast_symlink_inode_operations]
Signed-off-by: Ben Hutchings

mac: validate mac_partition is within sector

2015-12-30T02:25:56+00:00

commit 02e2a5bfebe99edcf9d694575a75032d53fe1b73 upstream.

If md->signature == MAC_DRIVER_MAGIC and md->block_size == 1023, a single
512 byte sector would be read (secsize / 512). However the partition
structure would be located past the end of the buffer (secsize % 512).

Signed-off-by: Kees Cook 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

FS-Cache: Add missing initialization of ret in cachefiles_write_page()

2015-12-30T02:25:56+00:00

commit cf89752645e47d86ba8a4157f4b121fcb33434c5 upstream.

fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’:
fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in
this function

If the jump to label "error" is taken, "ret" will indeed be
uninitialized, and random stack data may be printed by the debug code.

Fixes: 102f4d900c9c8f5e ("FS-Cache: Handle a write to the page immediately beyond the EOF marker")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: David Howells 
Signed-off-by: Al Viro 
Signed-off-by: Ben Hutchings