From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14B1DC3276E for ; Fri, 13 Dec 2019 20:47:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 347DB24689 for ; Fri, 13 Dec 2019 20:47:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="ZHnQ8l1+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 347DB24689 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5BC1D8E001B; Fri, 13 Dec 2019 15:47:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5455E8E0001; Fri, 13 Dec 2019 15:47:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E6398E001B; Fri, 13 Dec 2019 15:47:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 258978E0001 for ; Fri, 13 Dec 2019 15:47:40 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id BF1B33D13 for ; Fri, 13 Dec 2019 20:47:39 +0000 (UTC) X-FDA: 76261304238.22.magic01_89a29d30410e X-HE-Tag: magic01_89a29d30410e X-Filterd-Recvd-Size: 5692 Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Dec 2019 20:47:38 +0000 (UTC) Received: by mail-io1-f68.google.com with SMTP id f82so975499ioa.9 for ; Fri, 13 Dec 2019 12:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6sB8y2iaNHCxNWX2heldJxu0UPqZdo++w30Yr9hAFf8=; b=ZHnQ8l1+CLl9GeJBhbz+xV21W7J0kQjB5/9uQjhe/OvyD8lBuZ1CNOzFMfo2nOB2Bc VEXVZA8Y+KHPRJyKE1r68eqEw1x322Src1DB5H2EAnwkNCrz9m1XsgviniW9jWnlEGoX j1nIwVrTqt4XaIMNZRjr4Rukbd4I01XB/19uSWfvvyJqk7f1KAi5EzGXMMmw5mr86eAn 4GDaEjfj8+Lh23ArwqQ4XscnpU9uVyiYywAjJ6sVDNIhegAkvzf29fhYkxsPP/Ss7xGE GbBCKhgyY0RPAr4z9OWbvPS+6fIVg+OE7CTBMCunyTWegGnwnChoK2r1G5we5/H/8UZ5 pdXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6sB8y2iaNHCxNWX2heldJxu0UPqZdo++w30Yr9hAFf8=; b=Z2+utd6S3ouf0YEOnHYkHEew2C0GZ5vlo+WJRd4tFk46guFaOQrKYMgTa477l9libc ICPRw9k/WSq2BLltEkbmUzfBrMJGy5Q5oH3nJ8yKRY1joS+9wBnU40TbWpNuLVweU/01 qN9glwBcAw0CyBpyRMJYOv2lYUb9Ygo3ORjCsFy6mTgKbj4tB5HmdBzN2AVK27FIB6Uc iNjSl2Ju2rwd1xZd00R8GRi9y+rn8xdBXjHC2QU0z+MNE8vHS+VW17dPPhsj8gmlAaTM N+a2gj4ZHgid4P3Lol7EeqbkknfNvRXuFHU6BhleNuGI10rz8xRvZ70qGyoi1+pVRkwH YjJQ== X-Gm-Message-State: APjAAAWPVoKETT2dx2im7FTgu3g9Dr/SwxDVGBD00P51p8GPYCXHVUMF 4La54WYyjdKgo0KrAaEOxitESg== X-Google-Smtp-Source: APXvYqxtZDedWPUq8ULNgcbZ/UKPCJ/p44H78xxlx+Vcyu3li8+yxy6GUJEv149yD89bTP48e+HSkw== X-Received: by 2002:a02:3e83:: with SMTP id s125mr1335024jas.104.1576270057981; Fri, 13 Dec 2019 12:47:37 -0800 (PST) Received: from [192.168.1.159] ([65.144.74.34]) by smtp.gmail.com with ESMTPSA id n3sm3093281ilm.74.2019.12.13.12.47.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Dec 2019 12:47:37 -0800 (PST) Subject: Re: [PATCH 4/5] iomap: add struct iomap_data To: "Darrick J. Wong" Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, willy@infradead.org, clm@fb.com, torvalds@linux-foundation.org, david@fromorbit.com References: <20191212190133.18473-1-axboe@kernel.dk> <20191212190133.18473-5-axboe@kernel.dk> <20191213203242.GB99868@magnolia> From: Jens Axboe Message-ID: <90f26792-3751-c755-c0b9-a85b816e5340@kernel.dk> Date: Fri, 13 Dec 2019 13:47:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191213203242.GB99868@magnolia> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 12/13/19 1:32 PM, Darrick J. Wong wrote: > On Thu, Dec 12, 2019 at 12:01:32PM -0700, Jens Axboe wrote: >> We pass a lot of arguments to iomap_apply(), and subsequently to the >> actors that it calls. In preparation for adding one more argument, >> switch them to using a struct iomap_data instead. The actor gets a const >> version of that, they are not supposed to change anything in it. >> >> Signed-off-by: Jens Axboe > > Looks good, only a couple of questions... Thanks! >> fs/dax.c | 25 +++-- >> fs/iomap/apply.c | 26 +++--- >> fs/iomap/buffered-io.c | 202 +++++++++++++++++++++++++---------------- >> fs/iomap/direct-io.c | 57 +++++++----- >> fs/iomap/fiemap.c | 48 ++++++---- >> fs/iomap/seek.c | 64 ++++++++----- >> fs/iomap/swapfile.c | 27 +++--- >> include/linux/iomap.h | 15 ++- >> 8 files changed, 278 insertions(+), 186 deletions(-) >> >> diff --git a/fs/dax.c b/fs/dax.c >> index 1f1f0201cad1..d1c32dbbdf24 100644 >> --- a/fs/dax.c >> +++ b/fs/dax.c >> @@ -1090,13 +1090,16 @@ int __dax_zero_page_range(struct block_device *bdev, >> EXPORT_SYMBOL_GPL(__dax_zero_page_range); >> >> static loff_t >> -dax_iomap_actor(struct inode *inode, loff_t pos, loff_t length, void *data, >> - struct iomap *iomap, struct iomap *srcmap) >> +dax_iomap_actor(const struct iomap_data *data, struct iomap *iomap, > > I wonder, is 'struct iomap_ctx' a better name for the context structure? Yeah I think you are right, does seem like a better fit. I'll rename it for the next version. >> @@ -43,17 +44,18 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, >> * expose transient stale data. If the reserve fails, we can safely >> * back out at this point as there is nothing to undo. >> */ >> - ret = ops->iomap_begin(inode, pos, length, flags, &iomap, &srcmap); >> + ret = ops->iomap_begin(data->inode, data->pos, data->len, data->flags, >> + &iomap, &srcmap); > > ...and second, what do people think about about passing "const struct > iomap_ctx *ctx" to iomap_begin and iomap_end to reduce the argument > counts there too? > > (That's definitely a separate patch though, and I might just do that on > my own if nobody beats me to it...) To be honest, I just did what I needed, but I do think it's worth pursuing in general. The argument clutter is real. -- Jens Axboe