From patchwork Thu Sep 4 12:38:32 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 4845361 Return-Path: X-Original-To: patchwork-linux-nfs@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 D5B019F2EC for ; Thu, 4 Sep 2014 12:45:19 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B4E6B2026C for ; Thu, 4 Sep 2014 12:45:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7BCB620274 for ; Thu, 4 Sep 2014 12:45:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754593AbaIDMos (ORCPT ); Thu, 4 Sep 2014 08:44:48 -0400 Received: from mail-qg0-f41.google.com ([209.85.192.41]:35325 "EHLO mail-qg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751286AbaIDMjG (ORCPT ); Thu, 4 Sep 2014 08:39:06 -0400 Received: by mail-qg0-f41.google.com with SMTP id i50so9999723qgf.28 for ; Thu, 04 Sep 2014 05:39:05 -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=ON0I0b2ReesyoZNAF9zjs6zdZ9FNCdWUoUOLN+jaTdk=; b=QcV6ccox5/YUKZSM/ciLYo6B15gU8BWTy/N9o/V3ouaxu0UW6sdv9mbSP1ZuD/IcWI 0A7X+q1/USnPBaOQ7lBrYlO0UKMQQnP6P6Hvwl27NUSusPYAok3DYrQfNHNOeEvTO2Yf Dfj2KtHGZFih5ELpnZRYORYp0mMSnktAUY/D+8Uhf34CJGrop2rS6rST9rtjpIQduKR7 R1MBEfA5RqYxQlDTECGrx2ravbNHCBkiZUnH76tNXU1ODjK2Hb4sggRDlwjWkp08MjMv 7Kdagpjt0toSzu3SOQ2c+5y8GeMBEwKPrrPFVNut0Sig+f0RbauDmIDyUkJOiEwnkZQV k8NQ== X-Gm-Message-State: ALoCoQm/o0uuoCUSmf97Ny1tjdplH6koLOcQ6G+K7E7wML+dqWD2xJwcgKksnrP7eq3QrttVdnci X-Received: by 10.224.88.137 with SMTP id a9mr6818227qam.88.1409834345300; Thu, 04 Sep 2014 05:39:05 -0700 (PDT) Received: from tlielax.poochiereds.net ([2001:470:8:d63:3a60:77ff:fe93:a95d]) by mx.google.com with ESMTPSA id t5sm19186512qat.24.2014.09.04.05.39.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Sep 2014 05:39:03 -0700 (PDT) From: Jeff Layton To: linux-fsdevel@vger.kernel.org Cc: linux-nfs@vger.kernel.org, Christoph Hellwig , "J. Bruce Fields" , linux-kernel@vger.kernel.org Subject: [PATCH v2 06/17] locks: clean up vfs_setlease kerneldoc comments Date: Thu, 4 Sep 2014 08:38:32 -0400 Message-Id: <1409834323-7171-7-git-send-email-jlayton@primarydata.com> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1409834323-7171-1-git-send-email-jlayton@primarydata.com> References: <1409834323-7171-1-git-send-email-jlayton@primarydata.com> Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-8.5 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 get rid of some of the other comments about what's needed for a full implementation. Signed-off-by: Jeff Layton Reviewed-by: Christoph Hellwig --- fs/locks.c | 34 ++++++++++------------------------ 1 file changed, 10 insertions(+), 24 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 1289b74fffbf..81a4628f5594 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1708,30 +1708,16 @@ 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 -ENOLCK (and generate a scary-looking + * stack trace). */ int vfs_setlease(struct file *filp, long arg, struct file_lock **lease)