Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2977573imu; Sun, 9 Dec 2018 14:08:12 -0800 (PST) X-Google-Smtp-Source: AFSGD/VLSnL1yxNSD1eV8pSoF6jIvbRuOa4yltGF/LthMMmRxEooJoYc2uUtAsM0oEIH+8vPFKsd X-Received: by 2002:a65:6094:: with SMTP id t20mr8723505pgu.285.1544393292697; Sun, 09 Dec 2018 14:08:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544393292; cv=none; d=google.com; s=arc-20160816; b=xLLkneiOmYOH9dcIaGs8Tf3iNby5uQEUrkF2yKzcWuDMSHGBuvth4WN/3tqXyYTLAu Qs0rU6FWK+D73SbgJ2ne66Yx5WHJvNMXk5n7ro/k6lx+URBU18/Yl54/42d+aho6kePC MlD7PGVz/2YPoThUOETumEXikMBBmJ0VyxNrnNZh879KuF0JJkaQKKtzXKXnesb+nO92 dnNfNc6g3ANV9JMqG4SYgJr2xwV/bcnyGEzgXFYgb5H0nnsOTROFDGUi2cT5nMc4bydy DnoPkXFHiU7q9q6L8N95kwdIpmfm3qCQPCsWPVdUmJcsxAo0BiMgvNQGkKEakrLZj+01 mqVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=HdGf/mTl6FznxSV3T7nWD+TwMVv3Whn4nwjxEjjMx+E=; b=QpLG3dfbp4X9XP1xCoK9C/UqJiygyRk54+ZtA2K8iwDZ8lVJTyllmvCokdBSJ8pLZ2 ZWcbTQiiHGZB8LC2tLLQ5w1GBBtrCE138o5efk66g7ypoNMT7bB47FJFIZPPgO/QlNRo ogruPNok9ltXjPJjykKfElNp8iSBFdleRj3Saw/1aLtRtswtqw+V3CLb6gOrpGpgplsN JPRIEqppOZEHO1TI/rAgY+mlt2NCp3dd24EL0sP3Mb3HZqoCKq/tV3yzMtpIj8dcN4st q27dKi1HdDB5s/i9uG+F5H4sfKZb6/ZA4F41iLarxXVNBfCkXRI6cqw5UWRFSEn+wBsk aD7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w2si8135354pgh.565.2018.12.09.14.07.57; Sun, 09 Dec 2018 14:08:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727754AbeLIWG3 (ORCPT + 99 others); Sun, 9 Dec 2018 17:06:29 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:37072 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727511AbeLIWG1 (ORCPT ); Sun, 9 Dec 2018 17:06:27 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW738-0002iq-GV; Sun, 09 Dec 2018 21:55:43 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72f-0003Sz-9V; Sun, 09 Dec 2018 21:55:13 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Steve French" , "Ronnie Sahlberg" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 183/328] smb3: check for and properly advertise directory lease support In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Steve French commit f801568332321e2b1e7a8bd26c3e4913a312a2ec upstream. Although servers will typically ignore unsupported features, we should advertise the support for directory leases (as Windows e.g. does) in the negotiate protocol capabilities we pass to the server, and should check for the server capability (CAP_DIRECTORY_LEASING) before sending a lease request for an open of a directory. This will prevent us from accidentally sending directory leases to SMB2.1 or SMB2 server for example. Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg [bwh: Backported to 3.16: - Drop changes to smb3any_values, smbdefault_values, smb311_values - Adjust context] Signed-off-by: Ben Hutchings --- --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -1433,7 +1433,7 @@ struct smb_version_values smb21_values = struct smb_version_values smb30_values = { .version_string = SMB30_VERSION_STRING, .protocol_id = SMB30_PROT_ID, - .req_capabilities = SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING | SMB2_GLOBAL_CAP_LARGE_MTU, + .req_capabilities = SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING | SMB2_GLOBAL_CAP_LARGE_MTU | SMB2_GLOBAL_CAP_DIRECTORY_LEASING, .large_lock_type = 0, .exclusive_lock_type = SMB2_LOCKFLAG_EXCLUSIVE_LOCK, .shared_lock_type = SMB2_LOCKFLAG_SHARED_LOCK, @@ -1453,7 +1453,7 @@ struct smb_version_values smb30_values = struct smb_version_values smb302_values = { .version_string = SMB302_VERSION_STRING, .protocol_id = SMB302_PROT_ID, - .req_capabilities = SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING | SMB2_GLOBAL_CAP_LARGE_MTU, + .req_capabilities = SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING | SMB2_GLOBAL_CAP_LARGE_MTU | SMB2_GLOBAL_CAP_DIRECTORY_LEASING, .large_lock_type = 0, .exclusive_lock_type = SMB2_LOCKFLAG_EXCLUSIVE_LOCK, .shared_lock_type = SMB2_LOCKFLAG_SHARED_LOCK, --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -1211,6 +1211,9 @@ SMB2_open(const unsigned int xid, struct if (!(server->capabilities & SMB2_GLOBAL_CAP_LEASING) || *oplock == SMB2_OPLOCK_LEVEL_NONE) req->RequestedOplockLevel = *oplock; + else if (!(server->capabilities & SMB2_GLOBAL_CAP_DIRECTORY_LEASING) && + (oparms->create_options & CREATE_NOT_FILE)) + req->RequestedOplockLevel = *oplock; /* no srv lease support */ else { rc = add_lease_context(server, iov, &num_iovecs, oparms->fid->lease_key, oplock);