linux-toradex.git/fs/gfs2, branch v4.4.151

gfs2: Fix fallocate chunk size

2018-05-30T05:49:13+00:00

[ Upstream commit 174d1232ebc84fcde8f5889d1171c9c7e74a10a7 ]

The chunk size of allocations in __gfs2_fallocate is calculated
incorrectly.  The size can collapse, causing __gfs2_fallocate to
allocate one block at a time, which is very inefficient.  This needs
fixing in two places:

In gfs2_quota_lock_check, always set ap->allowed to UINT_MAX to indicate
that there is no quota limit.  This fixes callers that rely on
ap->allowed to be set even when quotas are off.

In __gfs2_fallocate, reset max_blks to UINT_MAX in each iteration of the
loop to make sure that allocation limits from one resource group won't
spill over into another resource group.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

GFS2: Take inode off order_write list when setting jdata flag

2017-12-20T09:04:59+00:00

[ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ]

This patch fixes a deadlock caused when the jdata flag is set for
inodes that are already on the ordered write list. Since it is
on the ordered write list, log_flush calls gfs2_ordered_write which
calls filemap_fdatawrite. But since the inode had the jdata flag
set, that calls gfs2_jdata_writepages, which tries to start a new
transaction. A new transaction cannot be started because it tries
to acquire the log_flush rwsem which is already locked by the log
flush operation.

The bottom line is: We cannot switch an inode from ordered to jdata
until we eliminate any ordered data pages (via log flush) or any
log_flush operation afterward will create the circular dependency
above. So we need to flush the log before setting the diskflags to
switch the file mode, then we need to remove the inode from the
ordered writes list.

Before this patch, the log flush was done for jdata->ordered, but
that's wrong. If we're going from jdata to ordered, we don't need
to call gfs2_log_flush because the call to filemap_fdatawrite will
do it for us:

   filemap_fdatawrite() -> __filemap_fdatawrite_range()
      __filemap_fdatawrite_range() -> do_writepages()
         do_writepages() -> gfs2_jdata_writepages()
            gfs2_jdata_writepages() -> gfs2_log_flush()

This patch modifies function do_gfs2_set_flags so that if a file
has its jdata flag set, and it's already on the ordered write list,
the log will be flushed and it will be removed from the list
before setting the flag.

Signed-off-by: Bob Peterson 
Signed-off-by: Andreas Gruenbacher 
Acked-by: Abhijith Das 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next

2017-10-08T08:14:16+00:00

[ Upstream commit 14d37564fa3dc4e5d4c6828afcd26ac14e6796c5 ]

This patch fixes a place where function gfs2_glock_iter_next can
reference an invalid error pointer.

Signed-off-by: Dan Carpenter 
Signed-off-by: Bob Peterson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

gfs2: Fix debugfs glocks dump

2017-10-05T07:41:47+00:00

commit 10201655b085df8e000822e496e5d4016a167a36 upstream.

The switch to rhashtables (commit 88ffbf3e03) broke the debugfs glock
dump (/sys/kernel/debug/gfs2//glocks) for dumps bigger than a
single buffer: the right function for restarting an rhashtable iteration
from the beginning of the hash table is rhashtable_walk_enter;
rhashtable_walk_stop + rhashtable_walk_start will just resume from the
current position.

The upstream commit doesn't directly apply to 4.4.y because 4.4.y
doesn't have rhashtable_walk_enter and the following mainline commits:

  92ecd73a887c4a2b94daf5fc35179d75d1c4ef95  
    gfs2: Deduplicate gfs2_{glocks,glstats}_open
  cc37a62785a584f4875788689f3fd1fa6e4eb291  
    gfs2: Replace rhashtable_walk_init with rhashtable_walk_enter

Other than rhashtable_walk_enter, rhashtable_walk_init can fail.  To
handle the failure case in gfs2_glock_seq_stop, we check if
rhashtable_walk_init has initialized iter->walker; if it has not, we
must not call rhashtable_walk_stop or rhashtable_walk_exit.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman

gfs2: Fix glock rhashtable rcu bug

2017-07-15T09:57:46+00:00

commit 961ae1d83d055a4b9ebbfb4cc8ca62ec1a7a3b74 upstream.

Before commit 88ffbf3e03 "GFS2: Use resizable hash table for glocks",
glocks were freed via call_rcu to allow reading the glock hashtable
locklessly using rcu.  This was then changed to free glocks immediately,
which made reading the glock hashtable unsafe.  Bring back the original
code for freeing glocks via call_rcu.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman

gfs2: avoid uninitialized variable warning

2017-04-30T03:49:28+00:00

commit 67893f12e5374bbcaaffbc6e570acbc2714ea884 upstream.

We get a bogus warning about a potential uninitialized variable
use in gfs2, because the compiler does not figure out that we
never use the leaf number if get_leaf_nr() returns an error:

fs/gfs2/dir.c: In function 'get_first_leaf':
fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
fs/gfs2/dir.c: In function 'dir_split_leaf':
fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]

Changing the 'if (!error)' to 'if (!IS_ERR_VALUE(error))' is
sufficient to let gcc understand that this is exactly the same
condition as in IS_ERR() so it can optimize the code path enough
to understand it.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman

gfs2: Avoid alignment hole in struct lm_lockname

2017-03-26T10:13:19+00:00

commit 28ea06c46fbcab63fd9a55531387b7928a18a590 upstream.

Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
the entire struct lm_lockname instead of its individual fields.  On some
architectures, struct lm_lockname contains a hole of uninitialized
memory due to alignment rules, which now leads to incorrect hash values.
Get rid of that hole.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman

gfs2: Add missing rcu locking for glock lookup

2017-03-12T05:37:29+00:00

commit f38e5fb95a1f8feda88531eedc98f69b24748712 upstream.

We must hold the rcu read lock across looking up glocks and trying to
bump their refcount to prevent the glocks from being freed in between.

Signed-off-by: Andrew Price 
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman

posix_acl: Clear SGID bit when setting file permissions

2016-10-31T10:13:58+00:00

commit 073931017b49d9458aa351605b43a7e34598caef upstream.

When file permissions are modified via chmod(2) and the user is not in
the owning group or capable of CAP_FSETID, the setgid bit is cleared in
inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
permissions as well as the new ACL, but doesn't clear the setgid bit in
a similar way; this allows to bypass the check in chmod(2).  Fix that.

References: CVE-2016-7097
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jeff Layton 
Signed-off-by: Jan Kara 
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus-3' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2015-11-14T02:02:30+00:00

Pull vfs xattr cleanups from Al Viro.

* 'for-linus-3' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  f2fs: xattr simplifications
  squashfs: xattr simplifications
  9p: xattr simplifications
  xattr handlers: Pass handler to operations instead of flags
  jffs2: Add missing capability check for listing trusted xattrs
  hfsplus: Remove unused xattr handler list operations
  ubifs: Remove unused security xattr handler
  vfs: Fix the posix_acl_xattr_list return value
  vfs: Check attribute names in posix acl xattr handers