On Wed, 2017-03-29 at 00:26 +0100, Germano Percossi wrote:
> All the other threads are queue with a delay, no reason
> why this one need to be so aggressive.
Is there any reason to queue with a delay? Is there a problem with
reconnecting immediately?
Sachin Prabhu
>
> Signed-off-by: Germano Percossi <germano.percossi@xxxxxxxxxx>
> ---
> fs/cifs/smb2pdu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 7446496..efe167c 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -258,7 +258,7 @@ smb2_reconnect(__le16 smb2_command, struct
> cifs_tcon *tcon)
> goto out;
>
> if (smb2_command != SMB2_INTERNAL_CMD)
> - queue_delayed_work(cifsiod_wq, &server->reconnect,
> 0);
> + queue_delayed_work(cifsiod_wq, &server->reconnect, 2
> * HZ);
>
> atomic_inc(&tconInfoReconnectCount);
> out:
> @@ -2231,7 +2231,7 @@ SMB2_echo(struct TCP_Server_Info *server)
>
> if (server->tcpStatus == CifsNeedNegotiate) {
> /* No need to send echo on newly established
> connections */
> - queue_delayed_work(cifsiod_wq, &server->reconnect,
> 0);
> + queue_delayed_work(cifsiod_wq, &server->reconnect, 2
> * HZ);
> return rc;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
