Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5533751ybp; Tue, 8 Oct 2019 04:32:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqwTOgEv8wrt+qpqQYBl8Tl4z/mAHhJb2y1J3QgdSCHV5jUvMYQa/vy9Vt+oBm6DmR3l2u9F X-Received: by 2002:a17:906:a44e:: with SMTP id cb14mr28079741ejb.277.1570534332210; Tue, 08 Oct 2019 04:32:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570534332; cv=none; d=google.com; s=arc-20160816; b=RSITYnEly0XlU9hVWC4m+uYf1VXzNIwQ+Bvr7nkrCcNW1k4+vjqcUAS8cH2Zc9aXCB t/n8XBmrSrO2uFPMFN3THEN6f333mgii6Tcp7XgRJsL8kgOghuGCGJWutY/lqOv3bVkG UQLWVasrlbCSPyO2xe5Po4n9xWWbehjLBY0Ddod3P8mbPiW0FFAsjwQr7oug19D6HWBO Eg2IPq8186nYNCUcS+YlgeGdHYkZjyTR95pEre1jeFCafrafKsD8qBH0U6fhH3K9htzT 3Ui3DKjZFew4G8KKJBtyPZpVy9xJdaGVzVz3403pbIWnE4KyPadBzPDTKVl03bEfUAw3 9Yqw== 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=WS3rtJ6wrQM3WmGgiNpriOLg4AVE0fMGVJ3/G6qKz0A=; b=sgfJyxMAdFZkLvZTx43jywribee+tuqOJPSxu1VssIckYCcN5bYUkxax6Uoo6LFgSj 8tJyEY7sykjzExZoHM3C7bpac4sYVUZklVnZbhLpfWjWKUwg0lqmsf4VIEfPPslRXVpR +RvjRyroa2jEdEWLdIgvB/Kn+qle1YeVrHwN6w2yaR9TUHMfw1Vlld7DxtppEMLA9JO8 oe0m5HZ5zqN5NeazszkWb5HZKJwJJs+dlIKzq9MdHXTuA3dsgo6ahhfZzt0ifSNfUEpA pX0Lrmq5HS14/WT8tEg9CnhaPLDp0fbrgZ4HafFcMPWgOoRaJE6/K2n7opUK5gkMymVc +/wg== 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 w1si9808042eda.214.2019.10.08.04.31.47; Tue, 08 Oct 2019 04:32:12 -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; 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 S1730516AbfJHLaP (ORCPT + 99 others); Tue, 8 Oct 2019 07:30:15 -0400 Received: from mx2.suse.de ([195.135.220.15]:40466 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729876AbfJHLaP (ORCPT ); Tue, 8 Oct 2019 07:30:15 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 36A1FAE35; Tue, 8 Oct 2019 11:30:13 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 6E84A1E4827; Tue, 8 Oct 2019 13:30:12 +0200 (CEST) Date: Tue, 8 Oct 2019 13:30:12 +0200 From: Jan Kara To: Matthew Bobrowski Cc: tytso@mit.edu, jack@suse.cz, 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 7/8] ext4: reorder map.m_flags checks in ext4_set_iomap() Message-ID: <20191008113012.GJ5078@quack2.suse.cz> References: <3551610e53aa1984210a4de04ad6e1a89f5bf0a3.1570100361.git.mbobrowski@mbobrowski.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3551610e53aa1984210a4de04ad6e1a89f5bf0a3.1570100361.git.mbobrowski@mbobrowski.org> 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 Thu 03-10-19 21:34:51, Matthew Bobrowski wrote: > For iomap direct IO write code path changes, we need to accommodate > for the case where the block mapping flags passed to ext4_map_blocks() > will result in m_flags having both EXT4_MAP_MAPPED and > EXT4_MAP_UNWRITTEN bits set. In order for the allocated unwritten > extents to be converted properly in the end_io handler, iomap->type > must be set to IOMAP_UNWRITTEN, so we need to reshuffle the > conditional statement in order to achieve this. > > This change is a no-op for DAX code path as the block mapping flag > passed to ext4_map_blocks() when IS_DAX(inode) never results in > EXT4_MAP_MAPPED and EXT4_MAP_UNWRITTEN being set at once. > > Signed-off-by: Matthew Bobrowski The patch looks good to me. You can add: Reviewed-by: Jan Kara Just those 72 columns limited comment lines... ;) Honza > --- > fs/ext4/inode.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > index e133dda55063..63ad23ae05b8 100644 > --- a/fs/ext4/inode.c > +++ b/fs/ext4/inode.c > @@ -3420,10 +3420,20 @@ static int ext4_set_iomap(struct inode *inode, struct iomap *iomap, u16 type, > iomap->type = type; > iomap->addr = IOMAP_NULL_ADDR; > } else { > - if (map->m_flags & EXT4_MAP_MAPPED) { > - iomap->type = IOMAP_MAPPED; > - } else if (map->m_flags & EXT4_MAP_UNWRITTEN) { > + /* > + * Flags passed to ext4_map_blocks() for direct I/O > + * writes can result in map->m_flags having both > + * EXT4_MAP_MAPPED and EXT4_MAP_UNWRITTEN bits set. In > + * order for allocated extents to be converted to > + * written extents in the ->end_io handler correctly, > + * we need to ensure that the iomap->type is set > + * approprately. Thus, we need to check whether > + * EXT4_MAP_UNWRITTEN is set first. > + */ > + if (map->m_flags & EXT4_MAP_UNWRITTEN) { > iomap->type = IOMAP_UNWRITTEN; > + } else if (map->m_flags & EXT4_MAP_MAPPED) { > + iomap->type = IOMAP_MAPPED; > } else { > WARN_ON_ONCE(1); > return -EIO; > -- > 2.20.1 > -- Jan Kara SUSE Labs, CR