lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Y6XE6jLIax/+xcjF@infradead.org> Date: Fri, 23 Dec 2022 07:10:34 -0800 From: Christoph Hellwig <hch@...radead.org> To: Andreas Gruenbacher <agruenba@...hat.com> Cc: Christoph Hellwig <hch@...radead.org>, "Darrick J . Wong" <djwong@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>, Matthew Wilcox <willy@...radead.org>, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, cluster-devel@...hat.com Subject: Re: [RFC v3 6/7] iomap/xfs: Eliminate the iomap_valid handler On Fri, Dec 16, 2022 at 04:06:25PM +0100, Andreas Gruenbacher wrote: > Eliminate the ->iomap_valid() handler by switching to a ->page_prepare() > handler and validating the mapping there. > > Signed-off-by: Andreas Gruenbacher <agruenba@...hat.com> > --- > fs/iomap/buffered-io.c | 24 ++++-------------------- > fs/xfs/xfs_iomap.c | 38 +++++++++++++++++++++++++++----------- > include/linux/iomap.h | 17 ----------------- > 3 files changed, 31 insertions(+), 48 deletions(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 6b7c1a10b8ec..b73ff317da21 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -623,7 +623,7 @@ static int iomap_write_begin(struct iomap_iter *iter, loff_t pos, > const struct iomap_page_ops *page_ops = iter->iomap.page_ops; > const struct iomap *srcmap = iomap_iter_srcmap(iter); > struct folio *folio; > - int status = 0; > + int status; > > BUG_ON(pos + len > iter->iomap.offset + iter->iomap.length); > if (srcmap != &iter->iomap) > @@ -642,27 +642,11 @@ static int iomap_write_begin(struct iomap_iter *iter, loff_t pos, > if (IS_ERR_OR_NULL(folio)) { > if (!folio) > return (iter->flags & IOMAP_NOWAIT) ? -EAGAIN : -ENOMEM; > + if (folio == ERR_PTR(-ESTALE)) { > iter->iomap.flags |= IOMAP_F_STALE; > + return 0; > } > + return PTR_ERR(folio); > } > > if (pos + len > folio_pos(folio) + folio_size(folio)) > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > index 669c1bc5c3a7..2248ce7be2e3 100644 > --- a/fs/xfs/xfs_iomap.c > +++ b/fs/xfs/xfs_iomap.c > @@ -62,29 +62,45 @@ xfs_iomap_inode_sequence( > return cookie | READ_ONCE(ip->i_df.if_seq); > } > > -/* > - * Check that the iomap passed to us is still valid for the given offset and > - * length. > - */ > -static bool > -xfs_iomap_valid( > - struct inode *inode, > - const struct iomap *iomap) > +static struct folio * > +xfs_page_prepare( > + struct iomap_iter *iter, > + loff_t pos, > + unsigned len) > { > + struct inode *inode = iter->inode; > + struct iomap *iomap = &iter->iomap; > struct xfs_inode *ip = XFS_I(inode); > + struct folio *folio; Please tab align this like the other variable declarations above. > - /* > - * Check that the cached iomap still maps correctly to the filesystem's > - * internal extent map. FS internal extent maps can change while iomap > - * is iterating a cached iomap, so this hook allows iomap to detect that > - * the iomap needs to be refreshed during a long running write > - * operation. > - * > - * The filesystem can store internal state (e.g. a sequence number) in > - * iomap->validity_cookie when the iomap is first mapped to be able to > - * detect changes between mapping time and whenever .iomap_valid() is > - * called. > - * > - * This is called with the folio over the specified file position held > - * locked by the iomap code. > - */ We'll still need to capture this information somewhere. I'd suggest to move it to the prepare/get method and reword it so that this is mentioned as an additional use case / requirement.
Powered by blists - more mailing lists