[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191218192144.GF32169@bombadil.infradead.org>
Date: Wed, 18 Dec 2019 11:21:44 -0800
From: Matthew Wilcox <willy@...radead.org>
To: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: Andreas Gruenbacher <agruenba@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christoph Hellwig <hch@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Jeff Layton <jlayton@...nel.org>,
Sage Weil <sage@...hat.com>, Ilya Dryomov <idryomov@...il.com>,
Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Richard Weinberger <richard@....at>,
Artem Bityutskiy <dedekind1@...il.com>,
Adrian Hunter <adrian.hunter@...el.com>,
ceph-devel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net,
linux-mtd@...ts.infradead.org, Chris Mason <clm@...com>,
Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
Jan Kara <jack@...e.cz>
Subject: Re: [PATCH v3] fs: Fix page_mkwrite off-by-one errors
On Wed, Dec 18, 2019 at 10:52:16AM -0800, Darrick J. Wong wrote:
> > @@ -9016,13 +9016,11 @@ vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf)
> > ret = VM_FAULT_NOPAGE; /* make the VM retry the fault */
> > again:
> > lock_page(page);
> > - size = i_size_read(inode);
> >
> > - if ((page->mapping != inode->i_mapping) ||
> > - (page_start >= size)) {
> > - /* page got truncated out from underneath us */
> > + ret2 = page_mkwrite_check_truncate(page, inode);
> > + if (ret2 < 0)
> > goto out_unlock;
>
> ...here we try to return -EFAULT as vm_fault_t. Notice how btrfs returns
> VM_FAULT_* values directly and never calls block_page_mkwrite_return? I
> know dsterba acked this, but I cannot see how this is correct?
I think you misread it. 'ret2' is never returned; we'll end up returning
VM_FAULT_NOPAGE here. Arguably it should be SIGBUS or something, but
I think retrying the fault will also end up giving a SIGBUS.
Powered by blists - more mailing lists