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

Btrfs: adjust outstanding_extents counter properly when dio write is split

2017-08-07T01:59:47+00:00

[ Upstream commit c2931667c83ded6504b3857e99cc45b21fa496fb ]

Currently how btrfs dio deals with split dio write is not good
enough if dio write is split into several segments due to the
lack of contiguous space, a large dio write like 'dd bs=1G count=1'
can end up with incorrect outstanding_extents counter and endio
would complain loudly with an assertion.

This fixes the problem by compensating the outstanding_extents
counter in inode if a large dio write gets split.

Reported-by: Anand Jain 
Tested-by: Anand Jain 
Signed-off-by: Liu Bo 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Btrfs: fix lockdep warning about log_mutex

2017-08-07T01:59:47+00:00

[ Upstream commit 781feef7e6befafd4d9787d1f7ada1f9ccd504e4 ]

While checking INODE_REF/INODE_EXTREF for a corner case, we may acquire a
different inode's log_mutex with holding the current inode's log_mutex, and
lockdep has complained this with a possilble deadlock warning.

Fix this by using mutex_lock_nested() when processing the other inode's
log_mutex.

Reviewed-by: Filipe Manana 
Signed-off-by: Liu Bo 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Btrfs: use down_read_nested to make lockdep silent

2017-08-07T01:59:47+00:00

[ Upstream commit e321f8a801d7b4c40da8005257b05b9c2b51b072 ]

If @block_group is not @used_bg, it'll try to get @used_bg's lock without
droping @block_group 's lock and lockdep has throwed a scary deadlock warning
about it.
Fix it by using down_read_nested.

Signed-off-by: Liu Bo 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

pstore: Use dynamic spinlock initializer

2017-08-07T01:59:43+00:00

commit e9a330c4289f2ba1ca4bf98c2b430ab165a8931b upstream.

The per-prz spinlock should be using the dynamic initializer so that
lockdep can correctly track it. Without this, under lockdep, we get a
warning at boot that the lock is in non-static memory.

Fixes: 109704492ef6 ("pstore: Make spinlock per zone instead of global")
Fixes: 76d5692a5803 ("pstore: Correctly initialize spinlock and flags")
Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

pstore: Correctly initialize spinlock and flags

2017-08-07T01:59:43+00:00

commit 76d5692a58031696e282384cbd893832bc92bd76 upstream.

The ram backend wasn't always initializing its spinlock correctly. Since
it was coming from kzalloc memory, though, it was harmless on
architectures that initialize unlocked spinlocks to 0 (at least x86 and
ARM). This also fixes a possibly ignored flag setting too.

When running under CONFIG_DEBUG_SPINLOCK, the following Oops was visible:

[    0.760836] persistent_ram: found existing buffer, size 29988, start 29988
[    0.765112] persistent_ram: found existing buffer, size 30105, start 30105
[    0.769435] persistent_ram: found existing buffer, size 118542, start 118542
[    0.785960] persistent_ram: found existing buffer, size 0, start 0
[    0.786098] persistent_ram: found existing buffer, size 0, start 0
[    0.786131] pstore: using zlib compression
[    0.790716] BUG: spinlock bad magic on CPU#0, swapper/0/1
[    0.790729]  lock: 0xffffffc0d1ca9bb0, .magic: 00000000, .owner: /-1, .owner_cpu: 0
[    0.790742] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc2+ #913
[    0.790747] Hardware name: Google Kevin (DT)
[    0.790750] Call trace:
[    0.790768] [] dump_backtrace+0x0/0x2bc
[    0.790780] [] show_stack+0x20/0x28
[    0.790794] [] dump_stack+0xa4/0xcc
[    0.790809] [] spin_dump+0xe0/0xf0
[    0.790821] [] spin_bug+0x30/0x3c
[    0.790834] [] do_raw_spin_lock+0x50/0x1b8
[    0.790846] [] _raw_spin_lock_irqsave+0x54/0x6c
[    0.790862] [] buffer_size_add+0x48/0xcc
[    0.790875] [] persistent_ram_write+0x60/0x11c
[    0.790888] [] ramoops_pstore_write_buf+0xd4/0x2a4
[    0.790900] [] pstore_console_write+0xf0/0x134
[    0.790912] [] console_unlock+0x48c/0x5e8
[    0.790923] [] register_console+0x3b0/0x4d4
[    0.790935] [] pstore_register+0x1a8/0x234
[    0.790947] [] ramoops_probe+0x6b8/0x7d4
[    0.790961] [] platform_drv_probe+0x7c/0xd0
[    0.790972] [] driver_probe_device+0x1b4/0x3bc
[    0.790982] [] __device_attach_driver+0xc8/0xf4
[    0.790996] [] bus_for_each_drv+0xb4/0xe4
[    0.791006] [] __device_attach+0xd0/0x158
[    0.791016] [] device_initial_probe+0x24/0x30
[    0.791026] [] bus_probe_device+0x50/0xe4
[    0.791038] [] device_add+0x3a4/0x76c
[    0.791051] [] of_device_add+0x74/0x84
[    0.791062] [] of_platform_device_create_pdata+0xc0/0x100
[    0.791073] [] of_platform_device_create+0x34/0x40
[    0.791086] [] of_platform_default_populate_init+0x58/0x78
[    0.791097] [] do_one_initcall+0x88/0x160
[    0.791109] [] kernel_init_freeable+0x264/0x31c
[    0.791123] [] kernel_init+0x18/0x11c
[    0.791133] [] ret_from_fork+0x10/0x50
[    0.793717] console [pstore-1] enabled
[    0.797845] pstore: Registered ramoops as persistent store backend
[    0.804647] ramoops: attached 0x100000@0xf7edc000, ecc: 0/0

Fixes: 663deb47880f ("pstore: Allow prz to control need for locking")
Fixes: 109704492ef6 ("pstore: Make spinlock per zone instead of global")
Reported-by: Brian Norris 
Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

pstore: Allow prz to control need for locking

2017-08-07T01:59:43+00:00

commit 663deb47880f2283809669563c5a52ac7c6aef1a upstream.

In preparation of not locking at all for certain buffers depending on if
there's contention, make locking optional depending on the initialization
of the prz.

Signed-off-by: Joel Fernandes 
[kees: moved locking flag into prz instead of via caller arguments]
Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

dentry name snapshots

2017-08-07T01:59:43+00:00

commit 49d31c2f389acfe83417083e1208422b4091cd9e upstream.

take_dentry_name_snapshot() takes a safe snapshot of dentry name;
if the name is a short one, it gets copied into caller-supplied
structure, otherwise an extra reference to external name is grabbed
(those are never modified).  In either case the pointer to stable
string is stored into the same structure.

dentry must be held by the caller of take_dentry_name_snapshot(),
but may be freely dropped afterwards - the snapshot will stay
until destroyed by release_dentry_name_snapshot().

Intended use:
	struct name_snapshot s;

	take_dentry_name_snapshot(&s, dentry);
	...
	access s.name
	...
	release_dentry_name_snapshot(&s);

Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name
to pass down with event.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

NFSv4.1: Fix a race where CB_NOTIFY_LOCK fails to wake a waiter

2017-08-07T01:59:40+00:00

commit b7dbcc0e433f0f61acb89ed9861ec996be4f2b38 upstream.

nfs4_retry_setlk() sets the task's state to TASK_INTERRUPTIBLE within the
same region protected by the wait_queue's lock after checking for a
notification from CB_NOTIFY_LOCK callback.  However, after releasing that
lock, a wakeup for that task may race in before the call to
freezable_schedule_timeout_interruptible() and set TASK_WAKING, then
freezable_schedule_timeout_interruptible() will set the state back to
TASK_INTERRUPTIBLE before the task will sleep.  The result is that the task
will sleep for the entire duration of the timeout.

Since we've already set TASK_INTERRUPTIBLE in the locked section, just use
freezable_schedule_timout() instead.

Fixes: a1d617d8f134 ("nfs: allow blocking locks to be awoken by lock callbacks")
Signed-off-by: Benjamin Coddington 
Reviewed-by: Jeff Layton 
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

NFS: invalidate file size when taking a lock.

2017-08-07T01:59:40+00:00

commit 442ce0499c0535f8972b68fa1fda357357a5c953 upstream.

Prior to commit ca0daa277aca ("NFS: Cache aggressively when file is open
for writing"), NFS would revalidate, or invalidate, the file size when
taking a lock.  Since that commit it only invalidates the file content.

If the file size is changed on the server while wait for the lock, the
client will have an incorrect understanding of the file size and could
corrupt data.  This particularly happens when writing beyond the
(supposed) end of file and can be easily be demonstrated with
posix_fallocate().

If an application opens an empty file, waits for a write lock, and then
calls posix_fallocate(), glibc will determine that the underlying
filesystem doesn't support fallocate (assuming version 4.1 or earlier)
and will write out a '0' byte at the end of each 4K page in the region
being fallocated that is after the end of the file.
NFS will (usually) detect that these writes are beyond EOF and will
expand them to cover the whole page, and then will merge the pages.
Consequently, NFS will write out large blocks of zeroes beyond where it
thought EOF was.  If EOF had moved, the pre-existing part of the file
will be over-written.  Locking should have protected against this,
but it doesn't.

This patch restores the use of nfs_zap_caches() which invalidated the
cached attributes.  When posix_fallocate() asks for the file size, the
request will go to the server and get a correct answer.

Fixes: ca0daa277aca ("NFS: Cache aggressively when file is open for writing")
Signed-off-by: NeilBrown 
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

jfs: Don't clear SGID when inheriting ACLs

2017-08-07T01:59:39+00:00

commit 9bcf66c72d726322441ec82962994e69157613e4 upstream.

When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.

Fix the problem by moving posix_acl_update_mode() out of
__jfs_set_acl() into jfs_set_acl(). That way the function will not be
called when inheriting ACLs which is what we want as it prevents SGID
bit clearing and the mode has been properly set by posix_acl_create()
anyway.

Fixes: 073931017b49d9458aa351605b43a7e34598caef
CC: jfs-discussion@lists.sourceforge.net
Signed-off-by: Jan Kara 
Signed-off-by: Dave Kleikamp 
Signed-off-by: Greg Kroah-Hartman