From: Greg Kroah-Hartman Date: Tue, 7 Jan 2020 13:55:34 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v4.14.163~25 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c8051b28481afb3caf036c5376b13e7dd717ca0c;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: nfsd4-fix-up-replay_matches_cache.patch pm-devfreq-check-null-governor-in-available_governors_show.patch xfs-don-t-check-for-ag-deadlock-for-realtime-files-in-bunmapi.patch --- diff --git a/queue-4.9/nfsd4-fix-up-replay_matches_cache.patch b/queue-4.9/nfsd4-fix-up-replay_matches_cache.patch new file mode 100644 index 00000000000..47d638ec671 --- /dev/null +++ b/queue-4.9/nfsd4-fix-up-replay_matches_cache.patch @@ -0,0 +1,52 @@ +From 6e73e92b155c868ff7fce9d108839668caf1d9be Mon Sep 17 00:00:00 2001 +From: Scott Mayhew +Date: Wed, 9 Oct 2019 15:11:37 -0400 +Subject: nfsd4: fix up replay_matches_cache() + +From: Scott Mayhew + +commit 6e73e92b155c868ff7fce9d108839668caf1d9be upstream. + +When running an nfs stress test, I see quite a few cached replies that +don't match up with the actual request. The first comment in +replay_matches_cache() makes sense, but the code doesn't seem to +match... fix it. + +This isn't exactly a bugfix, as the server isn't required to catch every +case of a false retry. So, we may as well do this, but if this is +fixing a problem then that suggests there's a client bug. + +Fixes: 53da6a53e1d4 ("nfsd4: catch some false session retries") +Signed-off-by: Scott Mayhew +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfsd/nfs4state.c | 15 ++++++++++----- + 1 file changed, 10 insertions(+), 5 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -3067,12 +3067,17 @@ static bool replay_matches_cache(struct + (bool)seq->cachethis) + return false; + /* +- * If there's an error than the reply can have fewer ops than +- * the call. But if we cached a reply with *more* ops than the +- * call you're sending us now, then this new call is clearly not +- * really a replay of the old one: ++ * If there's an error then the reply can have fewer ops than ++ * the call. + */ +- if (slot->sl_opcnt < argp->opcnt) ++ if (slot->sl_opcnt < argp->opcnt && !slot->sl_status) ++ return false; ++ /* ++ * But if we cached a reply with *more* ops than the call you're ++ * sending us now, then this new call is clearly not really a ++ * replay of the old one: ++ */ ++ if (slot->sl_opcnt > argp->opcnt) + return false; + /* This is the only check explicitly called by spec: */ + if (!same_creds(&rqstp->rq_cred, &slot->sl_cred)) diff --git a/queue-4.9/pm-devfreq-check-null-governor-in-available_governors_show.patch b/queue-4.9/pm-devfreq-check-null-governor-in-available_governors_show.patch new file mode 100644 index 00000000000..43c127981fc --- /dev/null +++ b/queue-4.9/pm-devfreq-check-null-governor-in-available_governors_show.patch @@ -0,0 +1,34 @@ +From d68adc8f85cd757bd33c8d7b2660ad6f16f7f3dc Mon Sep 17 00:00:00 2001 +From: Leonard Crestez +Date: Tue, 24 Sep 2019 10:26:53 +0300 +Subject: PM / devfreq: Check NULL governor in available_governors_show + +From: Leonard Crestez + +commit d68adc8f85cd757bd33c8d7b2660ad6f16f7f3dc upstream. + +The governor is initialized after sysfs attributes become visible so in +theory the governor field can be NULL here. + +Fixes: bcf23c79c4e46 ("PM / devfreq: Fix available_governor sysfs") +Signed-off-by: Leonard Crestez +Reviewed-by: Matthias Kaehlcke +Reviewed-by: Chanwoo Choi +Signed-off-by: Chanwoo Choi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/devfreq/devfreq.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/devfreq/devfreq.c ++++ b/drivers/devfreq/devfreq.c +@@ -982,7 +982,7 @@ static ssize_t available_governors_show( + * The devfreq with immutable governor (e.g., passive) shows + * only own governor. + */ +- if (df->governor->immutable) { ++ if (df->governor && df->governor->immutable) { + count = scnprintf(&buf[count], DEVFREQ_NAME_LEN, + "%s ", df->governor_name); + /* diff --git a/queue-4.9/series b/queue-4.9/series index e25616a2e55..8ad5d0ccc52 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -30,3 +30,6 @@ tracing-have-the-histogram-compare-functions-convert-to-u64-first.patch alsa-cs4236-fix-error-return-comparison-of-an-unsigned-integer.patch ftrace-avoid-potential-division-by-zero-in-function-profiler.patch arm64-revert-support-for-execute-only-user-mappings.patch +pm-devfreq-check-null-governor-in-available_governors_show.patch +nfsd4-fix-up-replay_matches_cache.patch +xfs-don-t-check-for-ag-deadlock-for-realtime-files-in-bunmapi.patch diff --git a/queue-4.9/xfs-don-t-check-for-ag-deadlock-for-realtime-files-in-bunmapi.patch b/queue-4.9/xfs-don-t-check-for-ag-deadlock-for-realtime-files-in-bunmapi.patch new file mode 100644 index 00000000000..bd9b8ca234b --- /dev/null +++ b/queue-4.9/xfs-don-t-check-for-ag-deadlock-for-realtime-files-in-bunmapi.patch @@ -0,0 +1,40 @@ +From 69ffe5960df16938bccfe1b65382af0b3de51265 Mon Sep 17 00:00:00 2001 +From: Omar Sandoval +Date: Tue, 26 Nov 2019 16:58:08 -0800 +Subject: xfs: don't check for AG deadlock for realtime files in bunmapi + +From: Omar Sandoval + +commit 69ffe5960df16938bccfe1b65382af0b3de51265 upstream. + +Commit 5b094d6dac04 ("xfs: fix multi-AG deadlock in xfs_bunmapi") added +a check in __xfs_bunmapi() to stop early if we would touch multiple AGs +in the wrong order. However, this check isn't applicable for realtime +files. In most cases, it just makes us do unnecessary commits. However, +without the fix from the previous commit ("xfs: fix realtime file data +space leak"), if the last and second-to-last extents also happen to have +different "AG numbers", then the break actually causes __xfs_bunmapi() +to return without making any progress, which sends +xfs_itruncate_extents_flags() into an infinite loop. + +Fixes: 5b094d6dac04 ("xfs: fix multi-AG deadlock in xfs_bunmapi") +Signed-off-by: Omar Sandoval +Reviewed-by: Darrick J. Wong +Signed-off-by: Darrick J. Wong +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/libxfs/xfs_bmap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/xfs/libxfs/xfs_bmap.c ++++ b/fs/xfs/libxfs/xfs_bmap.c +@@ -5688,7 +5688,7 @@ __xfs_bunmapi( + * Make sure we don't touch multiple AGF headers out of order + * in a single transaction, as that could cause AB-BA deadlocks. + */ +- if (!wasdel) { ++ if (!wasdel && !isrt) { + agno = XFS_FSB_TO_AGNO(mp, del.br_startblock); + if (prev_agno != NULLAGNUMBER && prev_agno > agno) + break;