[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170209215505.GW2267@bombadil.infradead.org>
Date: Thu, 9 Feb 2017 13:55:05 -0800
From: Matthew Wilcox <willy@...radead.org>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Hugh Dickins <hughd@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Dave Hansen <dave.hansen@...el.com>,
Vlastimil Babka <vbabka@...e.cz>,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-block@...r.kernel.org
Subject: Re: [PATCHv6 08/37] filemap: handle huge pages in
do_generic_file_read()
On Thu, Jan 26, 2017 at 02:57:50PM +0300, Kirill A. Shutemov wrote:
> +++ b/mm/filemap.c
> @@ -1886,6 +1886,7 @@ static ssize_t do_generic_file_read(struct file *filp, loff_t *ppos,
> if (unlikely(page == NULL))
> goto no_cached_page;
> }
> + page = compound_head(page);
We got this page from find_get_page(), which gets it from
pagecache_get_page(), which gets it from find_get_entry() ... which
(unless I'm lost in your patch series) returns the head page. So this
line is redundant, right?
But then down in filemap_fault, we have:
VM_BUG_ON_PAGE(page->index != offset, page);
... again, maybe I'm lost somewhere in your patch series, but I don't see
anywhere you remove that line (or modify it). So are you not testing
with VM debugging enabled, or are you not doing a test which includes
mapping a file with huge pages, reading from it (to get the page in cache),
then faulting on an address that is not in the first 4kB of that 2MB?
Powered by blists - more mailing lists