Patch "CIFS: reconnect thread reschedule itself" has been added to the 4.10-stable tree

From 18ea43113f5b74a97dd4be9bddbac10d68b1a6ce Mon Sep 17 00:00:00 2001

This is a note to let you know that I've just added the patch titled

CIFS: reconnect thread reschedule itself

to the 4.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
cifs-reconnect-thread-reschedule-itself.patch
and it can be found in the queue-4.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From 18ea43113f5b74a97dd4be9bddbac10d68b1a6ce Mon Sep 17 00:00:00 2001
From: Germano Percossi <[email protected]>
Date: Fri, 7 Apr 2017 12:29:36 +0100
Subject: CIFS: reconnect thread reschedule itself

From: Germano Percossi <[email protected]>

commit 18ea43113f5b74a97dd4be9bddbac10d68b1a6ce upstream.

In case of error, smb2_reconnect_server reschedule itself with a delay, to avoid being too aggressive.

Signed-off-by Germano Percossi <[email protected]>

Reviewed-by Pavel Shilovsky <[email protected]>

Signed-off-by Steve French <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/smb2pdu.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

fs/cifs/smb2pdu.c +9 -1

@@ -1987,6 +1987,9 @@ void smb2_reconnect_server(struct work_s
 	struct cifs_tcon *tcon, *tcon2;
 	struct list_head tmp_list;
 	int tcon_exist = false;
+	int rc;
+	int resched = false;
+
 
 	/* Prevent simultaneous reconnects that can corrupt tcon->rlist list */
 	mutex_lock(&server->reconnect_mutex);

@@ -2014,13 +2017,18 @@ void smb2_reconnect_server(struct work_s
 	spin_unlock(&cifs_tcp_ses_lock);
 
 	list_for_each_entry_safe(tcon, tcon2, &tmp_list, rlist) {
-		if (!smb2_reconnect(SMB2_INTERNAL_CMD, tcon))
+		rc = smb2_reconnect(SMB2_INTERNAL_CMD, tcon);
+		if (!rc)
 			cifs_reopen_persistent_handles(tcon);
+		else
+			resched = true;
 		list_del_init(&tcon->rlist);
 		cifs_put_tcon(tcon);
 	}
 
 	cifs_dbg(FYI, "Reconnecting tcons finished\n");
+	if (resched)
+		queue_delayed_work(cifsiod_wq, &server->reconnect, 2 * HZ);
 	mutex_unlock(&server->reconnect_mutex);
 
 	/* now we can safely release srv struct */

Patches currently in stable-queue which might be from [email protected] are

queue-4.10/cifs-reconnect-thread-reschedule-itself.patch queue-4.10/cifs-store-results-of-cifs_reopen_file-to-avoid-infinite-wait.patch

Hi Greg,

With respect to the 3 patches I received notifications about, I noticed the following:

a0918f1ce6 "CIFS: remove bad_network_name flag": you tried to apply it
on 4.10, 4.9 and 4.4 but it failed. I sent the fixed backport.
1fa839b498 "CIFS: store results of cifs_reopen_file..": it has been

    put in the queue for 3.18, 4.4, 4.9 and 4.10

18ea43113f "CIFS: reconnect thread reschedule itself": it has been
put in the queue for 4.9 and 4.10

Is there any reason why 1fa839b498 goes into 4 stable releases, while the others in in, respectively, 3 and 2 releases?

Quoted 8 lines · Germano Percossi

Hi Greg,

With respect to the 3 patches I received notifications about, I noticed the following:

a0918f1ce6 "CIFS: remove bad_network_name flag": you tried to apply it
on 4.10, 4.9 and 4.4 but it failed. I sent the fixed backport.
1fa839b498 "CIFS: store results of cifs_reopen_file..": it has been

Quoted 6 lines

    put in the queue for 3.18, 4.4, 4.9 and 4.10

18ea43113f "CIFS: reconnect thread reschedule itself": it has been
put in the queue for 4.9 and 4.10

Is there any reason why 1fa839b498 goes into 4 stable releases, while the others in in, respectively, 3 and 2 releases?

Perhaps they do not apply to those trees? That's the reason I wouldn't add them there. If you think they do belong there, I would be glad to accept a backported version of the patches.

thanks,

greg k-h

The reason why I asked it's because I did not receive any "Failed" notification, so I assumed you did not even try.

I sent the backport for a0918f1ce6 because I was notified of the failure.

I'll send a backport for all the remaining patches (wherever it makes sense).

Quoted 2 lines · Germano Percossi

The reason why I asked it's because I did not receive any "Failed" notification, so I assumed you did not even try.

I tried, but for patches without any specific "Fixes:" tag, I have to just guess that if the patch does not apply, then it was not wanted to go that far back.

Hi,

Quoted 8 lines · Greg KH

Quoted 2 lines · Germano Percossi

The reason why I asked it's because I did not receive any "Failed" notification, so I assumed you did not even try.

I tried, but for patches without any specific "Fixes:" tag, I have to just guess that if the patch does not apply, then it was not wanted to go that far back.

You were right in your assumption about 18ea43113f: it could be ported but it is not so important for 3.18 and 4.4 because we are not using persistent handles there.

For what concerns a0918f1ce6 "remove bad network.." on 3.18 I just ran git cherry-pick a0918f1ce6
on stable/linux-3.18.y without any problem.
Unless you use other commands with fuzz level lower than 2 it should apply as is.

Quoted 16 lines · Germano Percossi

Hi,

Quoted 8 lines · Greg KH

Quoted 2 lines · Germano Percossi

The reason why I asked it's because I did not receive any "Failed" notification, so I assumed you did not even try.

I tried, but for patches without any specific "Fixes:" tag, I have to just guess that if the patch does not apply, then it was not wanted to go that far back.

You were right in your assumption about 18ea43113f: it could be ported but it is not so important for 3.18 and 4.4 because we are not using persistent handles there.

Quoted 5 lines

For what concerns a0918f1ce6 "remove bad network.." on 3.18 I just ran git cherry-pick a0918f1ce6
on stable/linux-3.18.y without any problem.
Unless you use other commands with fuzz level lower than 2 it should apply as is.

Odd, it does apply, thanks. I'll apply it for the next 3.18-stable release after the current -rc one is released in a few days.

Quoted 17 lines · Greg KH

Quoted 16 lines · Germano Percossi

Hi,

Quoted 8 lines · Greg KH

Quoted 2 lines · Germano Percossi

The reason why I asked it's because I did not receive any "Failed" notification, so I assumed you did not even try.

I tried, but for patches without any specific "Fixes:" tag, I have to just guess that if the patch does not apply, then it was not wanted to go that far back.

You were right in your assumption about 18ea43113f: it could be ported but it is not so important for 3.18 and 4.4 because we are not using persistent handles there.

Quoted 8 lines

Quoted 5 lines

For what concerns a0918f1ce6 "remove bad network.." on 3.18 I just ran git cherry-pick a0918f1ce6
on stable/linux-3.18.y without any problem.
Unless you use other commands with fuzz level lower than 2 it should apply as is.

Odd, it does apply, thanks. I'll apply it for the next 3.18-stable release after the current -rc one is released in a few days.

Hm, but it isn't in 4.4-stable, you want it there too, right? It doesn't apply cleanly there:

Applying cifs-remove-bad_network_name-flag.patch to linux-4.4.y Applying patch cifs-remove-bad_network_name-flag.patch patching file fs/cifs/cifsglob.h
Hunk #1 succeeded at 906 (offset -42 lines).
patching file fs/cifs/smb2pdu.c
Hunk #1 FAILED at 1171.
Hunk #2 succeeded at 1036 with fuzz 2 (offset -241 lines). 1 out of 2 hunks FAILED -- rejects in file fs/cifs/smb2pdu.c