Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4927755ybv; Wed, 26 Feb 2020 05:29:25 -0800 (PST) X-Google-Smtp-Source: APXvYqxySiZtqT1kKfTw5TTzSxCFLAiNGmvBb48LJKyVVxCXJn5Qem1ozPFSQMBN3JAyMHIKwBgW X-Received: by 2002:a05:6830:124b:: with SMTP id s11mr2920032otp.333.1582723765295; Wed, 26 Feb 2020 05:29:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582723765; cv=none; d=google.com; s=arc-20160816; b=MVOwNjvg7Fwd9wRtF9e5yZfVA3WYQ4pp3zJ3nGFqfGkBXt0lQV7SYERRKW+Tl8T4bR lMNAaBPzrj6YvR9FkF1csthMt84jKykVA7KOQqmDiyfsTSVOB4QtZxtClEDbIhizLzEI 4dQPxGnQEPIoUzRs1U81NWY/Asd5jwFjfMTl8U4HLePNEPkfkpRJe3wEpOc84QZI5no4 XHRZHM2wSCEAw1kU7WTc7BD0Lh84btDQCHWz97Kh0tafKUR75ykl9Mswt2UfNmXfIs+V ttF6Zxy3K4YAZ5TqDvwrXTjH14xOvItEa2bD97xMW2wQvpk3ezb1iKOYgnz+R1aPRbIy uPJQ== 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; bh=vVWQauwv8wq9MHFlzzbl2PGbcD5jV2t2ZcPHw+50xew=; b=p9lhQSvLs3Bb+Z40MDaW1O0UoYDP9EUcpdQ6nCO+ak0b/MpiEKbsF4DNMdrJ0Tizuq wLUYIRKC0Pf2CPa34cM6LuyJY43vpWeQXLTavjnAVrettSmo2CBwWQjUxQJwI1CMFTZp 95B9rqxrjO4Pnx4KfKhBIXIsZ6cOWtod3taVbYhq9He3jKLeu5k3hxt3cKb8HhjPS8xY 79a0qVM0NeZotaXm2XQ5vzBKI2l+I5U0ZNAo4Cd23O4c1vyvNOR/itc3yMyhW862KXkL hfuUiY8UcCcdepzhAyhFauEoJmoNq5KAHDYeBVwVuU2LMhCwUHurj86tM+TzKFN5iAbr imCQ== ARC-Authentication-Results: i=1; mx.google.com; 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 m24si1282930otn.67.2020.02.26.05.29.06; Wed, 26 Feb 2020 05:29:25 -0800 (PST) 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; 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 S1726765AbgBZN1X (ORCPT + 99 others); Wed, 26 Feb 2020 08:27:23 -0500 Received: from mx2.suse.de ([195.135.220.15]:39884 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726476AbgBZN1X (ORCPT ); Wed, 26 Feb 2020 08:27:23 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 77309B133; Wed, 26 Feb 2020 13:27:21 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 34F231E0EA2; Wed, 26 Feb 2020 14:27:20 +0100 (CET) Date: Wed, 26 Feb 2020 14:27:20 +0100 From: Jan Kara To: Ritesh Harjani Cc: jack@suse.cz, tytso@mit.edu, linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca, linux-fsdevel@vger.kernel.org, darrick.wong@oracle.com, hch@infradead.org, cmaiolino@redhat.com Subject: Re: [PATCHv3 5/6] ext4: Move ext4_fiemap to use iomap framework. Message-ID: <20200226132720.GQ10728@quack2.suse.cz> References: <31caeb6a880e3070ace5dfcb0623fc06f751b443.1582702694.git.riteshh@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31caeb6a880e3070ace5dfcb0623fc06f751b443.1582702694.git.riteshh@linux.ibm.com> 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 26-02-20 15:27:07, Ritesh Harjani wrote: > This patch moves ext4_fiemap to use iomap framework. > For xattr a new 'ext4_iomap_xattr_ops' is added. > > Signed-off-by: Ritesh Harjani ... > -static int ext4_xattr_fiemap(struct inode *inode, > - struct fiemap_extent_info *fieinfo) > +static int ext4_iomap_xattr_fiemap(struct inode *inode, struct iomap *iomap) > { > __u64 physical = 0; > __u64 length; > - __u32 flags = FIEMAP_EXTENT_LAST; > int blockbits = inode->i_sb->s_blocksize_bits; > int error = 0; > + u16 iomap_type; > > /* in-inode? */ > if (ext4_test_inode_state(inode, EXT4_STATE_XATTR)) { > @@ -5130,40 +4928,44 @@ static int ext4_xattr_fiemap(struct inode *inode, > EXT4_I(inode)->i_extra_isize; > physical += offset; > length = EXT4_SB(inode->i_sb)->s_inode_size - offset; > - flags |= FIEMAP_EXTENT_DATA_INLINE; > brelse(iloc.bh); > + iomap_type = IOMAP_INLINE; > } else { /* external block */ > physical = (__u64)EXT4_I(inode)->i_file_acl << blockbits; > length = inode->i_sb->s_blocksize; > + iomap_type = IOMAP_MAPPED; > } If i_file_acl is 0 (i.e., no external xattr block), then I think returned iomap should be different... > +static int ext4_iomap_xattr_begin(struct inode *inode, loff_t offset, > + loff_t length, unsigned flags, > + struct iomap *iomap, struct iomap *srcmap) > { > - ext4_lblk_t start_blk; > - u32 ext4_fiemap_flags = FIEMAP_FLAG_SYNC|FIEMAP_FLAG_XATTR; > + int error; > > - int error = 0; > - > - if (ext4_has_inline_data(inode)) { > - int has_inline = 1; > + error = ext4_iomap_xattr_fiemap(inode, iomap); > + if (error == 0 && (offset >= iomap->length)) > + error = -ENOENT; Is ENOENT really correct here? It seems strange to me... Honza -- Jan Kara SUSE Labs, CR