Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1908242ybp; Wed, 9 Oct 2019 22:45:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRSMBNsBEw5VAA1WoMJ4Y7XNoJYW/z/LbVhi2KZXfrhIvOgADStJLLx8YfGAtbxzCtvWju X-Received: by 2002:a17:906:6b99:: with SMTP id l25mr6261706ejr.233.1570686314387; Wed, 09 Oct 2019 22:45:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570686314; cv=none; d=google.com; s=arc-20160816; b=lGmLfeyqUj+L4SJo6vDli16dTnATKmQqoZb6JimPacbM8KAz+HlDXy+eZGijpVRrpv tUPwqY1vVT0xyqb9TzMSKIRLAA9LPtSqa0c788qre5ypUzEXdZYs8a+zAGXFV+0jy9BX FnfDJZdVJs2c8qeZsGrfBADFobZ4qUdP1fs6j+jywvMjn4u1T3VuSYcc6Al2q3PnkzHT 8C8S0JNSu/il79/m2dUPdWIa4J/cQRUoZiUjWfEaPRNJGetbSXfSyRHX69NUC5ZzxyKL sQax335FhVVToYUgHmCb+njG5IfZNq8gVP5/yh8fQ5kS47mOc1dk+XU3mxzLVPiqmfo7 dkFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=d/oe2s886bN8qUzvhOLB+CA2L54j/Xxt6d1BIgZPIoA=; b=OpDZ736kNgzIdl1ajOgWR8k69Zz6+BKXKNsWIFwyG437tavs3wATrgcVJIIW8fr7m1 PTXzY6bslXpOFYZOWAW6lVhPdcf3cEsFN68l/u5TweLvsxB2aXy8l3RMuSjHCu2PZvrg N1bFVKRDLaA773Ju/wCO+pUPCB7eiD2D76y4VFurpehSqvV39ZRFzhSiqWkC3yNBdCQl Ht6J18MKuRqUo+wwIUDsxYlW4QwpC9eC4F/nx46bx0G1BdR4mXOvSkdpwP2qUwZ5JoQW BzXifHQy7yQmu+mrasxv1eu2bQF99qnAt6g1QKAhX4qkRty5XF4DSeVfufhLryJ8SzO5 vrVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mbobrowski-org.20150623.gappssmtp.com header.s=20150623 header.b=ZRpjEgoy; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 re18si2596408ejb.96.2019.10.09.22.44.50; Wed, 09 Oct 2019 22:45:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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=@mbobrowski-org.20150623.gappssmtp.com header.s=20150623 header.b=ZRpjEgoy; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732842AbfJJFo0 (ORCPT + 99 others); Thu, 10 Oct 2019 01:44:26 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:43326 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732800AbfJJFoZ (ORCPT ); Thu, 10 Oct 2019 01:44:25 -0400 Received: by mail-pl1-f193.google.com with SMTP id f21so2214214plj.10 for ; Wed, 09 Oct 2019 22:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mbobrowski-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=d/oe2s886bN8qUzvhOLB+CA2L54j/Xxt6d1BIgZPIoA=; b=ZRpjEgoyCHF9AX4rOp1AfD51SpFfwb9VH9ahLOQASNF5SAYpXOHmUbpR+gZ3LrB+tn E4W1SVv5rsnVMmqxdE6QeWFVma16JzdgJ2kkK/eiG4Nzj5q0KV9wQRhsEg9v37b2JtH6 QZ2JEfvQZG0JD/VyQFlt+v5Racvf0rCwJz114qO9BKSSnSof/fafgvN4qIgesLUQjI9j zd2AImQzXzNAjDcthlKyxTbZQiWRUIGRqjvLA9/NrISGGOSZxdR1lOSjTmp5KB8F33dG eum7VL5V5Hp4s+ITgOOav2FB1GrmNGEMslz62w6e6c19mQoV13/zQGKXL/18N1CE+PHg bRhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=d/oe2s886bN8qUzvhOLB+CA2L54j/Xxt6d1BIgZPIoA=; b=KkYqre4dyRCqHsJaE0Zea8mdTFuNXFzan4i1sjXRZpcl3PNHW8MchG6TZQyQGpSzD5 jGBW1koLge+/EJ4vY6GqYmL/rv0HZ6UyZD0zW2EjKDI9/Uh/UCFLWKkFU3lEZGoBA+rz eGESYpB3PjlkgQRc7YhHtGhwL2vdn6YS1trYySd88PTXT/He3paYSBCfZwzz27esWbBn NSOGR3ZwHqv30C1NjUyx67gKSEQa2EfoIn4PePiiJMNwbFrCJ0LC/7qDThv2QrmGEyrN TpozeSwwCjhx9j1a++EiXEcelibZlHOd5XqTVmQCetvzM/GeAI75fYn1UpfNkSZGRMm0 jqSQ== X-Gm-Message-State: APjAAAXpKh0LOM1fIgAHy1hVfltlk7x1wTq0UmuYiBFgJr/phOFLmVdD 6JCtGoneBxFWfIcAHO2DVFAwjnVoAUmA X-Received: by 2002:a17:902:8e81:: with SMTP id bg1mr7463619plb.137.1570686265003; Wed, 09 Oct 2019 22:44:25 -0700 (PDT) Received: from bobrowski ([110.232.114.101]) by smtp.gmail.com with ESMTPSA id g7sm5680732pfm.176.2019.10.09.22.44.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2019 22:44:24 -0700 (PDT) Date: Thu, 10 Oct 2019 16:44:18 +1100 From: Matthew Bobrowski To: Jan Kara Cc: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, hch@infradead.org, david@fromorbit.com, darrick.wong@oracle.com Subject: Re: [PATCH v4 5/8] ext4: move inode extension/truncate code out from ->iomap_end() callback Message-ID: <20191010054418.GD19064@bobrowski> References: <20191008112512.GH5078@quack2.suse.cz> <20191009101848.GG2125@poseidon.bobrowski.net> <20191009125132.GC5050@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191009125132.GC5050@quack2.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Oct 09, 2019 at 02:51:32PM +0200, Jan Kara wrote: > On Wed 09-10-19 21:18:50, Matthew Bobrowski wrote: > > > Just small nits below: > > > > > > > +static int ext4_handle_inode_extension(struct inode *inode, loff_t offset, > > > > + ssize_t written, size_t count) > > > > +{ > > > > + int ret = 0; > > > > > > I think both the function and callsites may be slightly simpler if you let > > > the function return 'written' or error (not 0 or error). But I'll leave > > > that decision upto you. > > > > Hm, don't we actually need to return 0 for success cases so that > > iomap_dio_complete() behaves correctly i.e. increments iocb->ki_pos, > > etc? > > Correct, iomap_dio_complete() expects 0 on success. So if we keep calling > ext4_handle_inode_extension() from ->end_io handler, we'd need some > specialcasing there and I agree that changing ext4_handle_inode_extension() > return convention isn't then very beneficial. If we stop calling > ext4_handle_inode_extension() from ->end_io handler (patch 8/8 discussion > pending), then the change would be a clear win. Agreed. Well, I think we've got some movement in the right direction in 8/8, so it looks like changing up the return values is what we'll go ahead with. ----