From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2500F566A for ; Fri, 20 Dec 2024 01:26:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.110 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734658006; cv=none; b=F0nSmNRwJ56tljt+B+etvslzq9EmXEiIa3SARixt7MaCtRAP8Kl04QYOSE9bvf+K35ChEuMevKiisYTbiGlr1qMJDYsMKxM+tufR6GbKK1oxvVBVB0/NxAr9eId4XoICEXB2zcL3S09cI68oAoO+N6uHSZd5KGPveWoxrmeEPWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734658006; c=relaxed/simple; bh=87sNITiIqP7Xb9jmH2I0FNz21TWs+OrYTWqMpIQSrJ8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ub76a69bk41SJrfMcJipGlOAIme6Qa71VhcV+HkAwEVlEd+tHDfPIV2nxIgqk1ckkQXuQPiMiaMOsyGvrT77s4UXSoQBxIMbqdh+mz2DwkoRTtUDk8Pg1TbJJaXUD+7pteIIYNInFxJ//1vCK3ugYIoTsSB9llcBhWUx6tdLUiE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=nyHq9wP4; arc=none smtp.client-ip=115.124.30.110 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="nyHq9wP4" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1734657994; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=vNCMZ9UaPxTHcgWclYDkbWI4qPCZR16dPD7YU91Vvt0=; b=nyHq9wP4/oWqHKm2IbFmC1VpCo99dGRPPqB2qicf+9ot0xJjM+t3TH5+AYs4yS/IjJYSvuSewXgBk4P0272fo/rE12DwHgENeLjRMf3jpH7/88WJDkTVElu9iWILk3lC2Gg0Zlbe2ZwUJ4XrFQPGWRQqvUvi496fb/7ibecIkmM= Received: from 30.74.144.151(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WLrwcbY_1734657993 cluster:ay36) by smtp.aliyun-inc.com; Fri, 20 Dec 2024 09:26:34 +0800 Message-ID: <74609b22-d030-47d2-b4e5-5f9e80ca06e6@linux.alibaba.com> Date: Fri, 20 Dec 2024 09:26:33 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] mm: shmem: fix incorrect index alignment for within_size policy To: David Hildenbrand , akpm@linux-foundation.org, hughd@google.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <77d8ef76a7d3d646e9225e9af88a76549a68aab1.1734593154.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024/12/19 23:35, David Hildenbrand wrote: > On 19.12.24 08:30, Baolin Wang wrote: >> With enabling the shmem per-size within_size policy, using an incorrect >> 'order' size to round_up() the index can lead to incorrect i_size checks, >> resulting in an inappropriate large orders being returned. >> >> Changing to use '1 << order' to round_up() the index to fix this issue. >> Additionally, adding an 'aligned_index' variable to avoid affecting the >> index checks. >> >> Fixes: e7a2ab7b3bb5 ("mm: shmem: add mTHP support for anonymous shmem") >> Signed-off-by: Baolin Wang >> --- >> Hi Andrew, >> >> These two bugfix patches are based on the mm-hotfixes-unstable branch, >> and this patch has a slight conflict with my previous patch set: >> "Support large folios for tmpfs". However, I think the conflicts are >> easy to resolve. If you need me to rebase and resend the >> "Support large folios for tmpfs" patch set, please let me know. >> Sorry for the troubles :) >> --- >>   mm/shmem.c | 5 +++-- >>   1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index f6fb053ac50d..dec659e84562 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -1689,6 +1689,7 @@ unsigned long shmem_allowable_huge_orders(struct >> inode *inode, >>       unsigned long mask = READ_ONCE(huge_shmem_orders_always); >>       unsigned long within_size_orders = >> READ_ONCE(huge_shmem_orders_within_size); >>       unsigned long vm_flags = vma ? vma->vm_flags : 0; >> +    pgoff_t aligned_index; >>       bool global_huge; >>       loff_t i_size; >>       int order; >> @@ -1723,9 +1724,9 @@ unsigned long shmem_allowable_huge_orders(struct >> inode *inode, >>       /* Allow mTHP that will be fully within i_size. */ >>       order = highest_order(within_size_orders); >>       while (within_size_orders) { >> -        index = round_up(index + 1, order); >> +        aligned_index = round_up(index + 1, 1 << order); >>           i_size = round_up(i_size_read(inode), PAGE_SIZE); >> -        if (i_size >> PAGE_SHIFT >= index) { >> +        if (i_size >> PAGE_SHIFT >= aligned_index) { >>               mask |= within_size_orders; >>               break; >>           } > > > Yes, that matches the logic in shmem_huge_global_enabled(). > > Acked-by: David Hildenbrand > > > Was wondering if one can factor that out into a helper where one could > pass an optional write_end ... Yes, add it into my TODO list. Thanks for reviewing.