From patchwork Sat Aug 23 14:41:12 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 4769651 Return-Path: X-Original-To: patchwork-cifs-client@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 676AA9F344 for ; Sat, 23 Aug 2014 14:42:05 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8127F2018A for ; Sat, 23 Aug 2014 14:42:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 96F59201BB for ; Sat, 23 Aug 2014 14:42:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751141AbaHWOmA (ORCPT ); Sat, 23 Aug 2014 10:42:00 -0400 Received: from mail-qa0-f41.google.com ([209.85.216.41]:45110 "EHLO mail-qa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbaHWOlf (ORCPT ); Sat, 23 Aug 2014 10:41:35 -0400 Received: by mail-qa0-f41.google.com with SMTP id j7so10909372qaq.14 for ; Sat, 23 Aug 2014 07:41:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references; bh=MgKXZmHnQTubXLQtfrLh/NcYBK91Iwdq/RXuNW8WHno=; b=eVSHUS0e2ltKKt0qkM1JfiNE5UvqTRrlTVVgz+79hI+5XLoqM+pK0no8AnPp+owv+Z Xrxk2Gg8586yskgu5jZF9d7Aqz8gRR3T/htyh7PiFM1xggH22oFO63Q5RBu6k1/SJXqQ P0nY65ZJEhG6YNK/+/NYTJRnq+DJRS9mQWUaqOzwMqgeHPCJI17pW7ZpaV/3fIUwkEmc JIlcyz7RdXXI8Av6noPEYm0JbCJ5ZF3wKM727A59RI4V6Zhcua7XQWAbTu5rIyNL2XIP 3+xUBzjlqUdXbkvXUFzqFwqXG5K3jQ0KXTw28Cs8k5SEUhFKiNZe04vFRZQkieaATN64 ix7g== X-Gm-Message-State: ALoCoQkYLcj7DmsMcbIEVw4fHqDHyQvnaMqOeKaG5ih6rONUvF4eE06AQbs5JELuAT/cPAClnuNe X-Received: by 10.140.47.129 with SMTP id m1mr16661204qga.95.1408804893672; Sat, 23 Aug 2014 07:41:33 -0700 (PDT) Received: from tlielax.poochiereds.net ([2001:470:8:d63:3a60:77ff:fe93:a95d]) by mx.google.com with ESMTPSA id o3sm64529771qab.21.2014.08.23.07.41.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Aug 2014 07:41:32 -0700 (PDT) From: Jeff Layton To: linux-fsdevel@vger.kernel.org Cc: bfields@fieldses.org, hch@infradead.org, cluster-devel@redhat.com, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org Subject: [PATCH 04/10] locks: clean up vfs_setlease kerneldoc comments Date: Sat, 23 Aug 2014 10:41:12 -0400 Message-Id: <1408804878-1331-5-git-send-email-jlayton@primarydata.com> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1408804878-1331-1-git-send-email-jlayton@primarydata.com> References: <1408804878-1331-1-git-send-email-jlayton@primarydata.com> Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some of the latter paragraphs seem ambiguous and just plain wrong. In particular the break_lease comment makes no sense. We call break_lease (and break_deleg) from all sorts of vfs-layer functions, so there is clearly such a method. Also, we are close to being able to allow for "real" filesystem setlease methods so remove the final comment about it not being a full implementation yet. Signed-off-by: Jeff Layton --- fs/locks.c | 41 +++++++++++++++++------------------------ 1 file changed, 17 insertions(+), 24 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index bedb817a5cc4..597e71a1e90f 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1705,30 +1705,23 @@ static int __vfs_setlease(struct file *filp, long arg, struct file_lock **lease) } /** - * vfs_setlease - sets a lease on an open file - * @filp: file pointer - * @arg: type of lease to obtain - * @lease: file_lock to use - * - * Call this to establish a lease on the file. - * The (*lease)->fl_lmops->lm_break operation must be set; if not, - * break_lease will oops! - * - * This will call the filesystem's setlease file method, if - * defined. Note that there is no getlease method; instead, the - * filesystem setlease method should call back to setlease() to - * add a lease to the inode's lease list, where fcntl_getlease() can - * find it. Since fcntl_getlease() only reports whether the current - * task holds a lease, a cluster filesystem need only do this for - * leases held by processes on this node. - * - * There is also no break_lease method; filesystems that - * handle their own leases should break leases themselves from the - * filesystem's open, create, and (on truncate) setattr methods. - * - * Warning: the only current setlease methods exist only to disable - * leases in certain cases. More vfs changes may be required to - * allow a full filesystem lease implementation. + * vfs_setlease - sets a lease on an open file + * @filp: file pointer + * @arg: type of lease to obtain + * @lease: file_lock to use when adding a lease + * + * Call this to establish a lease on the file. The "lease" argument is not + * used for F_UNLCK requests and may be NULL. For commands that set or alter + * an existing lease, the (*lease)->fl_lmops->lm_break operation must be set; + * if not, this function will return -EINVAL (and generate a scary-looking + * stack trace). + * + * This will call the filesystem's setlease file method, if defined. Note that + * there is no getlease method; instead, the filesystem setlease method should + * call back to generic_setlease() to add a lease to the inode's lease list, + * where fcntl_getlease() can find it. Since fcntl_getlease() only reports + * whether the current task holds a lease, a cluster filesystem need only do + * this for leases held by processes on this node. */ int vfs_setlease(struct file *filp, long arg, struct file_lock **lease)