Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3045889pxv; Sun, 25 Jul 2021 14:43:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRfjGYIyUlQaIAuY++JC0iMe3S+cX6nHOo1jhDNxEj4lTgiqjW1k3dHR1MFXDziBpZx9W/ X-Received: by 2002:a17:906:7c52:: with SMTP id g18mr481852ejp.224.1627249429741; Sun, 25 Jul 2021 14:43:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627249429; cv=none; d=google.com; s=arc-20160816; b=jeR612nnmgsJ7mJqGVemm0UqJcaVbcEfpoNVgT5dP8V7slDVkgpS2zz7uWSaxV95Zj 7swKspqbkcw6FRo2BL+Bo/+aa/dCXYSqzvvM/n8WXeFRYabIFKWuUuWEmqlgQnCHQOs0 Wo+9GJWqu2WcDgAdv5QgNk0gxgKKxbSN1b03u3Oy6V0rqBV78wEb7X9r93aAA7c+2VT9 ymcw4FJMJti2W2pCCZOi9oyNe8ZIz7rJIAcPMC+hWD01rxy0bXdQ5uObtzDR3EtUTu3W Ko4iiCk/o1QJR+27UScQJrY6UbKW3JeMVRMA0kbSWxMi3pg8JAlIwJ08ynyyzuEfbgU3 ek1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=s8N2idTt3koqse72Yl74x+xxuDdMO4ULLt5JkM0YAoM=; b=ly1Iob0YyN92YldAqDQ2LE4djcY0yJyVl2HKyWT2YI9J3FF54U+8iKk4oZfFZt9aJR y1N5TO9aLGCVKWW3tHRkm51e0yPyuI/HqhqZVOop2r2HHnO6mbsHENORdY4q5z6mWAEE vgjMNn7uXwvLMyNRPQlDutfkCD7CPyZg4c079UQU/XxsyXXGppGa9tGhObNh43b4vrlB ykDa0UOOLBR8cm/TtAYJXF1/tiK8qxW2mwThNg9RYEWr/bpPiAjXJMxTu74ISubpZet5 nbM9DUGXiSGIMR8xSxbh8N6TkxYbBVE0eKbgsTjtWdNxJmqLgiFZTdblUpMO9eI9OuQI k+TA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jiTMOw6D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n14si17477954edx.144.2021.07.25.14.43.27; Sun, 25 Jul 2021 14:43:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jiTMOw6D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229840AbhGYU7e (ORCPT + 99 others); Sun, 25 Jul 2021 16:59:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbhGYU7e (ORCPT ); Sun, 25 Jul 2021 16:59:34 -0400 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25F65C061757; Sun, 25 Jul 2021 14:40:03 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id l126so9415454ioa.12; Sun, 25 Jul 2021 14:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s8N2idTt3koqse72Yl74x+xxuDdMO4ULLt5JkM0YAoM=; b=jiTMOw6D+zBqM0I6CP9tirn/UVvd5jdwfd9RO5E4J96x0YOIce2j75yuAIU/Wx2eiO aQKe4ByT32OSnNByKqfDAkG3TpOonuDZimMe5r/R8KrexgNwpNT9ITK0ALnSWpNhbL6C ++b3ht9CrAcxZQP52BN3koJ0lZViUEkcSoU6KIA7HpH025tT0bg4uv+i4k7HF5at+pib G3Y49g/1WyuW+GZhYCeVHkKzxI5UvU/YScgVpfIFkNpCcS2a5cTFAE3QH9U7R3iikMTO rOrmrimERIPBPezbMV3WE+ksCWcTuTZSU4a2tKgRi+Rlq19gAOTh1SVZpqvO7NHuhuxM u+LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s8N2idTt3koqse72Yl74x+xxuDdMO4ULLt5JkM0YAoM=; b=EBSNPXUIjNcgZc9BKTohXAPdCOlmh1O47Um9xoTU8WuJDkMBbVm+BNMM82/PPqbmH1 IN8QFcIMfeA1QLnWFd5zsLaZ7bHjaL4rBItq5K+2xmSaWnq3uuZvXwR8gu60vi05Ugp8 CUIdx6I46K3j8RC0nW9/ESFZibFIfIdwMO9Y/thft0LWVPvsP6QuXAPakBI1SxHE92aB 9MSbanZdW8zEzD84xfgoQ8Uqy6nsphnZKNLQdXk+E9r2u5RvQD5nsoa28rhNkVanhPcj 2nqq3F3KJf2HZz7IXC3j4Eg9bA3cqAdiaeu76idE4XhbgR4T/y/AfRd2cxGWN+9yDhea 9ZUw== X-Gm-Message-State: AOAM531d2VW3oR1BcJv5CD2fU4zMm/YUFFxyWym6tm0dDk87vR+nUx6L 0SQDC/uRc2cYGJXga3LYpXXvxNPzpG/eX/9j+wH3lxnv X-Received: by 2002:a05:6638:22f:: with SMTP id f15mr13383793jaq.141.1627249202569; Sun, 25 Jul 2021 14:40:02 -0700 (PDT) MIME-Version: 1.0 References: <20210723174131.180813-1-hsiangkao@linux.alibaba.com> In-Reply-To: <20210723174131.180813-1-hsiangkao@linux.alibaba.com> From: =?UTF-8?Q?Andreas_Gr=C3=BCnbacher?= Date: Sun, 25 Jul 2021 23:39:51 +0200 Message-ID: Subject: Re: [PATCH v7] iomap: make inline data support more flexible To: Gao Xiang Cc: linux-erofs@lists.ozlabs.org, Linux FS-devel Mailing List , LKML , Christoph Hellwig , "Darrick J . Wong" , Matthew Wilcox , Huang Jianan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Fr., 23. Juli 2021 um 19:41 Uhr schrieb Gao Xiang : > Add support for reading inline data content into the page cache from > nonzero page-aligned file offsets. This enables the EROFS tailpacking > mode where the last few bytes of the file are stored right after the > inode. > > The buffered write path remains untouched since EROFS cannot be used > for testing. It'd be better to be implemented if upcoming real users > care and provide a real pattern rather than leave untested dead code > around. > > Cc: Christoph Hellwig > Cc: Darrick J. Wong > Cc: Matthew Wilcox > Cc: Andreas Gruenbacher > Tested-by: Huang Jianan # erofs > Signed-off-by: Gao Xiang > --- > v6: https://lore.kernel.org/r/20210722031729.51628-1-hsiangkao@linux.alibaba.com > changes since v6: > - based on Christoph's reply; > - update commit message suggested by Darrick; > - disable buffered write path until some real fs users. > > fs/iomap/buffered-io.c | 42 ++++++++++++++++++++++++++---------------- > fs/iomap/direct-io.c | 10 ++++++---- > include/linux/iomap.h | 14 ++++++++++++++ > 3 files changed, 46 insertions(+), 20 deletions(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 87ccb3438bec..f351e1f9e3f6 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -205,25 +205,29 @@ struct iomap_readpage_ctx { > struct readahead_control *rac; > }; > > -static void > -iomap_read_inline_data(struct inode *inode, struct page *page, > - struct iomap *iomap) > +static int iomap_read_inline_data(struct inode *inode, struct page *page, > + struct iomap *iomap, loff_t pos) This is completely broken. This function is about filling the page cache. All the information needed for that is in struct iomap; the start position of an iomap operation has nothing to do with it. > { > - size_t size = i_size_read(inode); > + size_t size = iomap->length + iomap->offset - pos; > void *addr; > > if (PageUptodate(page)) > - return; > + return PAGE_SIZE; > > - BUG_ON(page_has_private(page)); > - BUG_ON(page->index); > - BUG_ON(size > PAGE_SIZE - offset_in_page(iomap->inline_data)); > + /* inline data must start page aligned in the file */ > + if (WARN_ON_ONCE(offset_in_page(pos))) > + return -EIO; > + if (WARN_ON_ONCE(!iomap_inline_data_size_valid(iomap))) > + return -EIO; > + if (WARN_ON_ONCE(page_has_private(page))) > + return -EIO; > > addr = kmap_atomic(page); > - memcpy(addr, iomap->inline_data, size); > + memcpy(addr, iomap_inline_buf(iomap, pos), size); > memset(addr + size, 0, PAGE_SIZE - size); > kunmap_atomic(addr); > SetPageUptodate(page); > + return PAGE_SIZE; > } > > static inline bool iomap_block_needs_zeroing(struct inode *inode, > @@ -246,11 +250,8 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data, > unsigned poff, plen; > sector_t sector; > > - if (iomap->type == IOMAP_INLINE) { > - WARN_ON_ONCE(pos); > - iomap_read_inline_data(inode, page, iomap); > - return PAGE_SIZE; > - } > + if (iomap->type == IOMAP_INLINE) > + return iomap_read_inline_data(inode, page, iomap, pos); > > /* zero post-eof blocks as the page may be mapped */ > iop = iomap_page_create(inode, page); > @@ -589,6 +590,15 @@ __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, int flags, > return 0; > } > > +static int iomap_write_begin_inline(struct inode *inode, > + struct page *page, struct iomap *srcmap) > +{ > + /* needs more work for the tailpacking case, disable for now */ > + if (WARN_ON_ONCE(srcmap->offset != 0)) > + return -EIO; > + return iomap_read_inline_data(inode, page, srcmap, 0); > +} > + > static int > iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags, > struct page **pagep, struct iomap *iomap, struct iomap *srcmap) > @@ -618,14 +628,14 @@ iomap_write_begin(struct inode *inode, loff_t pos, unsigned len, unsigned flags, > } > > if (srcmap->type == IOMAP_INLINE) > - iomap_read_inline_data(inode, page, srcmap); > + status = iomap_write_begin_inline(inode, page, srcmap); > else if (iomap->flags & IOMAP_F_BUFFER_HEAD) > status = __block_write_begin_int(page, pos, len, NULL, srcmap); > else > status = __iomap_write_begin(inode, pos, len, flags, page, > srcmap); > > - if (unlikely(status)) > + if (unlikely(status < 0)) > goto out_unlock; > > *pagep = page; > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c > index 9398b8c31323..a6aaea2764a5 100644 > --- a/fs/iomap/direct-io.c > +++ b/fs/iomap/direct-io.c > @@ -378,23 +378,25 @@ iomap_dio_inline_actor(struct inode *inode, loff_t pos, loff_t length, > struct iomap_dio *dio, struct iomap *iomap) > { > struct iov_iter *iter = dio->submit.iter; > + void *dst = iomap_inline_buf(iomap, pos); > size_t copied; > > - BUG_ON(pos + length > PAGE_SIZE - offset_in_page(iomap->inline_data)); > + if (WARN_ON_ONCE(!iomap_inline_data_size_valid(iomap))) > + return -EIO; > > if (dio->flags & IOMAP_DIO_WRITE) { > loff_t size = inode->i_size; > > if (pos > size) > - memset(iomap->inline_data + size, 0, pos - size); > - copied = copy_from_iter(iomap->inline_data + pos, length, iter); > + memset(iomap_inline_buf(iomap, size), 0, pos - size); > + copied = copy_from_iter(dst, length, iter); > if (copied) { > if (pos + copied > size) > i_size_write(inode, pos + copied); > mark_inode_dirty(inode); > } > } else { > - copied = copy_to_iter(iomap->inline_data + pos, length, iter); > + copied = copy_to_iter(dst, length, iter); > } > dio->size += copied; > return copied; > diff --git a/include/linux/iomap.h b/include/linux/iomap.h > index 479c1da3e221..56b118c6d05c 100644 > --- a/include/linux/iomap.h > +++ b/include/linux/iomap.h > @@ -97,6 +97,20 @@ iomap_sector(struct iomap *iomap, loff_t pos) > return (iomap->addr + pos - iomap->offset) >> SECTOR_SHIFT; > } > > +static inline void *iomap_inline_buf(const struct iomap *iomap, loff_t pos) > +{ > + return iomap->inline_data - iomap->offset + pos; > +} > + > +/* > + * iomap->inline_data is a potentially kmapped page, ensure it never crosses a > + * page boundary. > + */ > +static inline bool iomap_inline_data_size_valid(const struct iomap *iomap) > +{ > + return iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data); > +} > + > /* > * When a filesystem sets page_ops in an iomap mapping it returns, page_prepare > * and page_done will be called for each page written to. This only applies to > -- > 2.24.4 > Andreas