From: Qian Cai <cai@redhat.com> To: Matthew Wilcox <willy@infradead.org> Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J ."@ml01.01.org, Wong@ml01.01.org, " <darrick.wong@oracle.com>, Christoph Hellwig <hch@infradead.org>, "@ml01.01.org, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org, Dave Kleikamp <shaggy@kernel.org>, jfs-discussion@lists.sourceforge.net, Dave Chinner <dchinner@redhat.com>, Stephen Rothwell <sfr@canb.auug.org.au>, linux-next@vger.kernel.org Subject: Re: [PATCH v2 5/9] iomap: Support arbitrarily many blocks per page Date: Tue, 22 Sep 2020 13:25:42 -0400 [thread overview] Message-ID: <c804f9ec9e15daa4e82483c546558599c662f53c.camel@redhat.com> (raw) In-Reply-To: <20200922170526.GK32101@casper.infradead.org> On Tue, 2020-09-22 at 18:05 +0100, Matthew Wilcox wrote: > On Tue, Sep 22, 2020 at 12:23:45PM -0400, Qian Cai wrote: > > On Fri, 2020-09-11 at 00:47 +0100, Matthew Wilcox (Oracle) wrote: > > > Size the uptodate array dynamically to support larger pages in the > > > page cache. With a 64kB page, we're only saving 8 bytes per page today, > > > but with a 2MB maximum page size, we'd have to allocate more than 4kB > > > per page. Add a few debugging assertions. > > > > > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > > > Reviewed-by: Dave Chinner <dchinner@redhat.com> > > > > Some syscall fuzzing will trigger this on powerpc: > > > > .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config > > > > [ 8805.895344][T445431] WARNING: CPU: 61 PID: 445431 at fs/iomap/buffered- > > io.c:78 iomap_page_release+0x250/0x270 > > Well, I'm glad it triggered. That warning is: > WARN_ON_ONCE(bitmap_full(iop->uptodate, nr_blocks) != > PageUptodate(page)); > so there was definitely a problem of some kind. > > truncate_cleanup_page() calls > do_invalidatepage() calls > iomap_invalidatepage() calls > iomap_page_release() > > Is this the first warning? I'm wondering if maybe there was an I/O error > earlier which caused PageUptodate to get cleared again. If it's easy to > reproduce, perhaps you could try something like this? Yes, this is the first warning. BTW, I did run the reproducer of a805c111650c ("iomap: fix WARN_ON_ONCE() from unprivileged users") earlier, so I am wondering if this is just another victim WARN_ON_ONCE() from it. > > +void dump_iomap_page(struct page *page, const char *reason) > +{ > + struct iomap_page *iop = to_iomap_page(page); > + unsigned int nr_blocks = i_blocks_per_page(page->mapping->host, page); > + > + dump_page(page, reason); > + if (iop) > + printk("iop:reads %d writes %d uptodate %*pb\n", > + atomic_read(&iop->read_bytes_pending), > + atomic_read(&iop->write_bytes_pending), > + nr_blocks, iop->uptodate); > + else > + printk("iop:none\n"); > +} > > and then do something like: > > if (bitmap_full(iop->uptodate, nr_blocks) != PageUptodate(page)) > dump_iomap_page(page, NULL); > _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Qian Cai <cai@redhat.com> To: Matthew Wilcox <willy@infradead.org> Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" <darrick.wong@oracle.com>, Christoph Hellwig <hch@infradead.org>, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org, Dave Kleikamp <shaggy@kernel.org>, jfs-discussion@lists.sourceforge.net, Dave Chinner <dchinner@redhat.com>, Stephen Rothwell <sfr@canb.auug.org.au>, linux-next@vger.kernel.org Subject: Re: [PATCH v2 5/9] iomap: Support arbitrarily many blocks per page Date: Tue, 22 Sep 2020 13:25:42 -0400 [thread overview] Message-ID: <c804f9ec9e15daa4e82483c546558599c662f53c.camel@redhat.com> (raw) In-Reply-To: <20200922170526.GK32101@casper.infradead.org> On Tue, 2020-09-22 at 18:05 +0100, Matthew Wilcox wrote: > On Tue, Sep 22, 2020 at 12:23:45PM -0400, Qian Cai wrote: > > On Fri, 2020-09-11 at 00:47 +0100, Matthew Wilcox (Oracle) wrote: > > > Size the uptodate array dynamically to support larger pages in the > > > page cache. With a 64kB page, we're only saving 8 bytes per page today, > > > but with a 2MB maximum page size, we'd have to allocate more than 4kB > > > per page. Add a few debugging assertions. > > > > > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > > > Reviewed-by: Dave Chinner <dchinner@redhat.com> > > > > Some syscall fuzzing will trigger this on powerpc: > > > > .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config > > > > [ 8805.895344][T445431] WARNING: CPU: 61 PID: 445431 at fs/iomap/buffered- > > io.c:78 iomap_page_release+0x250/0x270 > > Well, I'm glad it triggered. That warning is: > WARN_ON_ONCE(bitmap_full(iop->uptodate, nr_blocks) != > PageUptodate(page)); > so there was definitely a problem of some kind. > > truncate_cleanup_page() calls > do_invalidatepage() calls > iomap_invalidatepage() calls > iomap_page_release() > > Is this the first warning? I'm wondering if maybe there was an I/O error > earlier which caused PageUptodate to get cleared again. If it's easy to > reproduce, perhaps you could try something like this? Yes, this is the first warning. BTW, I did run the reproducer of a805c111650c ("iomap: fix WARN_ON_ONCE() from unprivileged users") earlier, so I am wondering if this is just another victim WARN_ON_ONCE() from it. > > +void dump_iomap_page(struct page *page, const char *reason) > +{ > + struct iomap_page *iop = to_iomap_page(page); > + unsigned int nr_blocks = i_blocks_per_page(page->mapping->host, page); > + > + dump_page(page, reason); > + if (iop) > + printk("iop:reads %d writes %d uptodate %*pb\n", > + atomic_read(&iop->read_bytes_pending), > + atomic_read(&iop->write_bytes_pending), > + nr_blocks, iop->uptodate); > + else > + printk("iop:none\n"); > +} > > and then do something like: > > if (bitmap_full(iop->uptodate, nr_blocks) != PageUptodate(page)) > dump_iomap_page(page, NULL); >
next prev parent reply other threads:[~2020-09-22 17:25 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-10 23:46 [PATCH v2 0/9] THP iomap patches for 5.10 Matthew Wilcox (Oracle) 2020-09-10 23:46 ` Matthew Wilcox (Oracle) 2020-09-10 23:46 ` [PATCH v2 1/9] iomap: Fix misplaced page flushing Matthew Wilcox (Oracle) 2020-09-10 23:46 ` Matthew Wilcox (Oracle) 2020-09-10 23:47 ` [PATCH v2 2/9] fs: Introduce i_blocks_per_page Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-15 14:58 ` Dave Kleikamp 2020-09-15 14:58 ` Dave Kleikamp 2020-09-15 15:40 ` David Laight 2020-09-15 15:40 ` David Laight 2020-09-15 15:49 ` Matthew Wilcox 2020-09-15 15:49 ` Matthew Wilcox 2020-09-10 23:47 ` [PATCH v2 3/9] iomap: Use kzalloc to allocate iomap_page Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-10 23:47 ` [PATCH v2 4/9] iomap: Use bitmap ops to set uptodate bits Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-10 23:47 ` [PATCH v2 5/9] iomap: Support arbitrarily many blocks per page Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-11 5:36 ` Christoph Hellwig 2020-09-11 5:36 ` Christoph Hellwig 2020-09-17 22:00 ` Darrick J. Wong 2020-09-17 22:00 ` Darrick J. Wong 2020-09-22 16:23 ` Qian Cai 2020-09-22 16:23 ` Qian Cai 2020-09-22 17:05 ` Matthew Wilcox 2020-09-22 17:05 ` Matthew Wilcox 2020-09-22 17:25 ` Qian Cai [this message] 2020-09-22 17:25 ` Qian Cai 2020-09-23 1:06 ` Qian Cai 2020-09-23 1:06 ` Qian Cai 2020-09-23 2:48 ` Matthew Wilcox 2020-09-23 2:48 ` Matthew Wilcox 2020-09-23 5:00 ` Darrick J. Wong 2020-09-23 5:00 ` Darrick J. Wong 2020-09-23 18:59 ` Matthew Wilcox 2020-09-23 18:59 ` Matthew Wilcox 2020-09-23 16:55 ` Qian Cai 2020-09-23 16:55 ` Qian Cai 2020-09-24 1:07 ` Matthew Wilcox 2020-09-24 1:07 ` Matthew Wilcox 2020-09-10 23:47 ` [PATCH v2 6/9] iomap: Convert read_count to read_bytes_pending Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-11 5:36 ` Christoph Hellwig 2020-09-11 5:36 ` Christoph Hellwig 2020-09-17 22:02 ` Darrick J. Wong 2020-09-17 22:02 ` Darrick J. Wong 2020-09-10 23:47 ` [PATCH v2 7/9] iomap: Convert write_count to write_bytes_pending Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-17 22:02 ` Darrick J. Wong 2020-09-17 22:02 ` Darrick J. Wong 2020-09-10 23:47 ` [PATCH v2 8/9] iomap: Convert iomap_write_end types Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-17 22:03 ` Darrick J. Wong 2020-09-17 22:03 ` Darrick J. Wong 2020-09-10 23:47 ` [PATCH v2 9/9] iomap: Change calling convention for zeroing Matthew Wilcox (Oracle) 2020-09-10 23:47 ` Matthew Wilcox (Oracle) 2020-09-11 6:42 ` Christoph Hellwig 2020-09-11 6:42 ` Christoph Hellwig 2020-09-17 22:05 ` Darrick J. Wong 2020-09-17 22:05 ` Darrick J. Wong 2020-09-17 22:11 ` Matthew Wilcox 2020-09-17 22:11 ` Matthew Wilcox 2020-09-17 22:18 ` Darrick J. Wong 2020-09-17 22:18 ` Darrick J. Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c804f9ec9e15daa4e82483c546558599c662f53c.camel@redhat.com \ --to=cai@redhat.com \ --cc=" <darrick.wong@oracle.com>, Christoph Hellwig <hch@infradead.org>, "@ml01.01.org \ --cc="Darrick J ."@ml01.01.org \ --cc=Wong@ml01.01.org \ --cc=dchinner@redhat.com \ --cc=jfs-discussion@lists.sourceforge.net \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-next@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=linux-xfs@vger.kernel.org \ --cc=sfr@canb.auug.org.au \ --cc=shaggy@kernel.org \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.