Re: [PATCH v2 2/3] mm/memory-failure.c: avoid calling invalidate_inode_page() with unexpected pages

[Miaohe Lin <linmiaohe@huawei.com>]

On 2022/3/14 10:50, HORIGUCHI NAOYA(堀口 直也) wrote:
> On Mon, Mar 14, 2022 at 09:58:49AM +0800, Miaohe Lin wrote:
>> On 2022/3/14 7:41, HORIGUCHI NAOYA(堀口 直也) wrote:
>>> On Sat, Mar 12, 2022 at 03:46:12PM +0800, Miaohe Lin wrote:
>>>> Since commit 042c4f32323b ("mm/truncate: Inline invalidate_complete_page()
>>>
>>> This commit ID does not exist in mainline (or in the latest mmotm?),
>>> so you can't use it in patch description.  Could you update this part?
>>>
>>
>> This commit is in the mmotm but not in mainline yet:
>>
>> commit 042c4f32323beb28146c658202d3e69899e4f245
>> Author: Matthew Wilcox (Oracle) <willy@infradead.org>
>> Date:   Sat Feb 12 15:27:42 2022 -0500
>>
>>     mm/truncate: Inline invalidate_complete_page() into its one caller
>>
>>     invalidate_inode_page() is the only caller of invalidate_complete_page()
>>     and inlining it reveals that the first check is unnecessary (because we
>>     hold the page locked, and we just retrieved the mapping from the page).
>>     Actually, it does make a difference, in that tail pages no longer fail
>>     at this check, so it's now possible to remove a tail page from a mapping.
>>
>>     Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>>     Reviewed-by: John Hubbard <jhubbard@nvidia.com>
>>     Reviewed-by: Christoph Hellwig <hch@lst.de>
>>
>> Am I "not" supposed to use this commit id as it's not "stable" now?
> 
> No, it's not stable yet. In whatever way you get the above commit (I guess
> you get it from https://github.com/hnaz/linux-mm), all acked mm-related
> patches are sent to Linus by Andrew *by email*, so the eventual commit IDs
> should be determined when they are applied to mainline.
> 

Many thanks for your explanation. (I get this commit id from linux-next tree:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git)
So I should remember always to get the commit id from mainline.

Thanks again. :)

> Thanks,
> Naoya Horiguchi
>