Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp4963174img; Tue, 26 Mar 2019 22:19:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqwgF8cpO9Q+zwJgacu9mqVI9jhWII7hhCZpUmosPr8pLfeXKdBP0U2TgJIaodxQyBz0zkP5 X-Received: by 2002:a63:234c:: with SMTP id u12mr33238027pgm.282.1553663996448; Tue, 26 Mar 2019 22:19:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553663996; cv=none; d=google.com; s=arc-20160816; b=igyIykFBJKgrOo1S2ZQkMaIMpPpQnvwqsJaK896fweHcTJZb3Vnq5/g3+bH37KTaEI KNO5G37nm4j/1nfn+s+wMJaXNPhrF2i9qXaLD9t0qkaOvd5bjqmVpl1Dp9JymAhLyQoF mZK+nCQNhntN0TZzV3mz5P41BxnNaCTMPsAqO0uvd1r6gm62Wffz3PTdJTlOdsp8X11J Njqdq/UloMUZfsKfTdxY1u/4Wpi5jK7YH5Y1d/A7GXhdCeN1LKPSTP/nxIblNoI0w0t1 dTNsfuhWPVZ0Va2oL9J32xcx+wg2l8SpEB2Rg4uoOkf0IqWJI1clCLf9upMJW7uMVHUu cszA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Iz22Myouv8iQMYGK0rTnTeswOBYDThi/TC7bfTdyCxs=; b=lI7MDp4imASBBN6Hxm3uebUmed/b1jjUQ++A/KrvXl5dkXgRge4u3RBOfdAeODWFhW I22pffNS+rmu5DMGWvAh0jqruYfa7fVYDU4Wr1qy6SDrXYSmCQhOYTlAlJwkEE751WID REKr0pX0Y4Y9B22YFPU3VhQ6Nhe++dblerRN2FnogzrDJ8Z1h7FnPmSXhXzEvl+z1Ciz k6TfSHaJSOH5k81T2gFFDRzCiaOqRSszOSGlX3So47qBQpLrid4+yVpEPr0S2XabqsX9 DKX5JD8TlKdy/nFfcEOI3m3eQVwixBqe1A96L66LLQf22a4JQXs3B+2ygS4xufztedqm OaGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=PnF40OmR; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b20si18131006pls.193.2019.03.26.22.19.41; Tue, 26 Mar 2019 22:19:56 -0700 (PDT) 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; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=PnF40OmR; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732853AbfC0FSu (ORCPT + 99 others); Wed, 27 Mar 2019 01:18:50 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:59071 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725768AbfC0FSt (ORCPT ); Wed, 27 Mar 2019 01:18:49 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5537622125; Wed, 27 Mar 2019 01:18:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 27 Mar 2019 01:18:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=Iz22Myouv8iQMYGK0rTnTeswOBYDThi/TC7bfTdyCxs=; b=PnF40OmR fRI+VmRi6ki9Vgee37u/fxh8YzD1IbxyYEcFHl8hj0T1zTmerTGBoA8/qVsBgYWO hrylaGz207Luw5WcjZJsMlRLN1848/yQ55cMQwb+pqh1tdfb/PhDAA2A0reWlGRu ROlYhOW4mNRBTeEvbxIPSUkiq5Wt5LC5BNYc76YaqG2xbuCuqyQNah/2OlpeQilt dJFI4XzONWhCZBrU0z2kesN9IBKKdllxAqgJ0g4ssCT0TjnYGQBS3YNuhCJoE6Rg MjzT2O+jrZ1Ds2nulymO8+TssqI+OSXaNe3XF8/xYbZyckEKeQlViFkbp+raBBhk GRinhcyCM5G+cg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedugdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgjfhgggfestdekredtredttdenucfhrhhomhepfdfvohgsihhn ucevrdcujfgrrhguihhnghdfuceothhosghinheskhgvrhhnvghlrdhorhhgqeenucfkph epuddvgedrudeiledrudefledrudelvdenucfrrghrrghmpehmrghilhhfrhhomhepthho sghinheskhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgephe X-ME-Proxy: Received: from eros.localdomain (124-169-139-192.dyn.iinet.net.au [124.169.139.192]) by mail.messagingengine.com (Postfix) with ESMTPA id BA09EE40FF; Wed, 27 Mar 2019 01:18:44 -0400 (EDT) From: "Tobin C. Harding" To: Al Viro Cc: "Tobin C. Harding" , Jonathan Corbet , Mauro Carvalho Chehab , Neil Brown , Randy Dunlap , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 06/24] fs: Update function docstring for simple_write_end() Date: Wed, 27 Mar 2019 16:16:59 +1100 Message-Id: <20190327051717.23225-7-tobin@kernel.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190327051717.23225-1-tobin@kernel.org> References: <20190327051717.23225-1-tobin@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Shinx emits a warning due to an extra function parameter in the current function docstring for simple_write_end(). While we are fixing this warning we might as well clean up the whole function docstring for this function. The current member descriptions are readable in text and also ok in HTML. When vfs.txt is converted to use RST format these member descriptions could be improved with a reference to struct address_space_operations docs in that file. Update and cleanup docstring for simple_write_end() Signed-off-by: Tobin C. Harding --- fs/libfs.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/fs/libfs.c b/fs/libfs.c index 0fb590d79f30..36af25b9b2a3 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -448,9 +448,8 @@ int simple_write_begin(struct file *file, struct address_space *mapping, EXPORT_SYMBOL(simple_write_begin); /** - * simple_write_end - .write_end helper for non-block-device FSes - * @available: See .write_end of address_space_operations - * @file: " + * simple_write_end() - .write_end helper for non-block-device FSes + * @file: See .write_end of &struct address_space_operations * @mapping: " * @pos: " * @len: " @@ -458,17 +457,21 @@ EXPORT_SYMBOL(simple_write_begin); * @page: " * @fsdata: " * - * simple_write_end does the minimum needed for updating a page after writing is - * done. It has the same API signature as the .write_end of - * address_space_operations vector. So it can just be set onto .write_end for - * FSes that don't need any other processing. i_mutex is assumed to be held. - * Block based filesystems should use generic_write_end(). - * NOTE: Even though i_size might get updated by this function, mark_inode_dirty - * is not called, so a filesystem that actually does store data in .write_inode - * should extend on what's done here with a call to mark_inode_dirty() in the - * case that i_size has changed. + * Does the minimum needed for updating a page after writing is done. + * It has the same API signature as the .write_end member of &struct + * address_space_operations vector. So it can just be set onto + * .write_end for FSes that don't need any other processing. Block + * based filesystems should use generic_write_end(). + * + * NOTE: Even though i_size might get updated by this function, + * mark_inode_dirty() is not called, so a filesystem that actually does + * store data in .write_inode should extend on what's done here with a + * call to mark_inode_dirty() in the case that i_size has changed. * * Use *ONLY* with simple_readpage() + * + * Context: Caller must hold i_mutex + * Return: @copied argument unmodified. */ int simple_write_end(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned copied, -- 2.21.0