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

xfs: Properly retry failed dquot items in case of error during buffer writeback

2018-02-03T16:05:40+00:00

[ Upstream commit 373b0589dc8d58bc09c9a28d03611ae4fb216057 ]

Once the inode item writeback errors is already fixed, it's time to fix the same
problem in dquot code.

Although there were no reports of users hitting this bug in dquot code (at least
none I've seen), the bug is there and I was already planning to fix it when the
correct approach to fix the inodes part was decided.

This patch aims to fix the same problem in dquot code, regarding failed buffers
being unable to be resubmitted once they are flush locked.

Tested with the recently test-case sent to fstests list by Hou Tao.

Reviewed-by: Brian Foster 
Signed-off-by: Carlos Maiolino 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xfs: ubsan fixes

2018-02-03T16:05:40+00:00

[ Upstream commit 22a6c83777ac7c17d6c63891beeeac24cf5da450 ]

Fix some complaints from the UBSAN about signed integer addition overflows.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Brian Foster 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

quota: Check for register_shrinker() failure.

2018-02-03T16:05:39+00:00

[ Upstream commit 88bc0ede8d35edc969350852894dc864a2dc1859 ]

register_shrinker() might return -ENOMEM error since Linux 3.12.
Call panic() as with other failure checks in this function if
register_shrinker() failed.

Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work")
Signed-off-by: Tetsuo Handa 
Cc: Jan Kara 
Cc: Michal Hocko 
Reviewed-by: Michal Hocko 
Signed-off-by: Jan Kara 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xfs: fortify xfs_alloc_buftarg error handling

2018-02-03T16:05:39+00:00

[ Upstream commit d210a9874b8f6166579408131cb74495caff1958 ]

percpu_counter_init failure path doesn't clean up &btp->bt_lru list.
Call list_lru_destroy in that error path. Similarly register_shrinker
error path is not handled.

While it is unlikely to trigger these error path, it is not impossible
especially the later might fail with large NUMAs.  Let's handle the
failure to make the code more robust.

Noticed-by: Tetsuo Handa 
Signed-off-by: Michal Hocko 
Acked-by: Dave Chinner 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

lockd: fix "list_add double add" caused by legacy signal interface

2018-02-03T16:05:38+00:00

[ Upstream commit 81833de1a46edce9ca20cfe079872ac1c20ef359 ]

restart_grace() uses hardcoded init_net.
It can cause to "list_add double add" in following scenario:

1) nfsd and lockd was started in several net namespaces
2) nfsd in init_net was stopped (lockd was not stopped because
 it have users from another net namespaces)
3) lockd got signal, called restart_grace() -> set_grace_period()
 and enabled lock_manager in hardcoded init_net.
4) nfsd in init_net is started again,
 its lockd_up() calls set_grace_period() and tries to add
 lock_manager into init_net 2nd time.

Jeff Layton suggest:
"Make it safe to call locks_start_grace multiple times on the same
lock_manager. If it's already on the global grace_list, then don't try
to add it again.  (But we don't intentionally add twice, so for now we
WARN about that case.)

With this change, we also need to ensure that the nfsd4 lock manager
initializes the list before we call locks_start_grace. While we're at
it, move the rest of the nfsd_net initialization into
nfs4_state_create_net. I see no reason to have it spread over two
functions like it is today."

Suggested patch was updated to generate warning in described situation.

Suggested-by: Jeff Layton 
Signed-off-by: Vasily Averin 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nfsd: check for use of the closed special stateid

2018-02-03T16:05:38+00:00

[ Upstream commit ae254dac721d44c0bfebe2795df87459e2e88219 ]

Prevent the use of the closed (invalid) special stateid by clients.

Signed-off-by: Andrew Elble 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

grace: replace BUG_ON by WARN_ONCE in exit_net hook

2018-02-03T16:05:38+00:00

[ Upstream commit b872285751c1af010e12d02bce7069e2061a58ca ]

Signed-off-by: Vasily Averin 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nfsd: Ensure we check stateid validity in the seqid operation checks

2018-02-03T16:05:38+00:00

[ Upstream commit 9271d7e509c1bfc0b9a418caec29ec8d1ac38270 ]

After taking the stateid st_mutex, we want to know that the stateid
still represents valid state before performing any non-idempotent
actions.

Signed-off-by: Trond Myklebust 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)

2018-02-03T16:05:38+00:00

[ Upstream commit fb500a7cfee7f2f447d2bbf30cb59629feab6ac1 ]

Signed-off-by: Trond Myklebust 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xfs: always free inline data before resetting inode fork during ifree

2018-02-03T16:05:38+00:00

[ Upstream commit 98c4f78dcdd8cec112d1cbc5e9a792ee6e5ab7a6 ]

In xfs_ifree, we reset the data/attr forks to extents format without
bothering to free any inline data buffer that might still be around
after all the blocks have been truncated off the file.  Prior to commit
43518812d2 ("xfs: remove support for inlining data/extents into the
inode fork") nobody noticed because the leftover inline data after
truncation was small enough to fit inside the inline buffer inside the
fork itself.

However, now that we've removed the inline buffer, we /always/ have to
free the inline data buffer or else we leak them like crazy.  This test
was found by turning on kmemleak for generic/001 or generic/388.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman