From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (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 679C43F8899 for ; Mon, 17 Aug 2026 10:54:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786964062; cv=none; b=T5kGL4gm58+BL960fs/g8a5ye9AxdLcujYl4f9//PlzU2zPmgw8Cg0YzBMP9Dk5fbkApQHexFAP7cBOSb5PVF5XUShg/1dyonKEZFbn5VFQcl/ORXr7a9A72IwJV7NeZCmfwlXM2UoKEVX5zd/toITDCY1BqiZrgToW82mpJIUE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786964062; c=relaxed/simple; bh=wBt+qA7Eu+6UZqjucFzyMQ5hbOzMrLvPLSOiRELvNkU=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=PJnk7EL1szW6bRGGA6HCrjs6HzdqormscHWXDwhK+ek0K7H4Ucu62RzxJv25Qm5diwxOcaGMaMKFnuyRJ7IVtfE6Y9yZUSd36boyH8dHkNruwcVibU0OXPT5QQ/7yPba8EYK6K5mkG/ehSkYroqGHqQIyXG1U67FXaa9Hy8NiFc= 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=knGrj9FC; arc=none smtp.client-ip=115.124.30.132 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="knGrj9FC" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1786964047; h=Message-ID:Date:MIME-Version:Subject:From:To:Content-Type; bh=k3hXHOxNZFvP3ECw7qKsRya7tzKP/+v6sM6ift4LbNo=; b=knGrj9FCWEDCrK0XjmlhVhA8DfGn+4Wl1Ww9ZuUULppDPVuAIx2m0FMr8aSQMRG+hXv1p1euOEBteARHK9au8NIgBWYqY/F1S36mNPyncjlYxTlIVCv8qHALlhUZUu5wzxsuqreMCqmLFDWOW6tYgaNPxtMOLbMPsyvq7zzx+AQ= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R921e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0X96YJJC_1786964046; Received: from 30.74.144.121(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X96YJJC_1786964046 cluster:ay36) by smtp.aliyun-inc.com; Mon, 17 Aug 2026 18:54:06 +0800 Message-ID: Date: Mon, 17 Aug 2026 18:54:05 +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] mm: shmem: fix incorrect vm_flags usage when checking allowable orders From: Baolin Wang To: "Lorenzo Stoakes (ARM)" Cc: akpm@linux-foundation.org, david@kernel.org, hughd@google.com, ziy@nvidia.com, liam@infradead.org, nico.pache@linux.dev, dev.jain@arm.com, ryan.roberts@arm.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <3246987a-7f99-4dcd-b3f9-50d9a8c112ff@linux.alibaba.com> In-Reply-To: <3246987a-7f99-4dcd-b3f9-50d9a8c112ff@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/17/26 5:34 PM, Baolin Wang wrote: > > > On 8/17/26 3:40 PM, Lorenzo Stoakes (ARM) wrote: >> On Mon, Aug 17, 2026 at 03:16:43PM +0800, Baolin Wang wrote: >>> Lance reported that when MADV_HUGEPAGE is set on a tmpfs file mounted >>> with >>> huge=advise option, khugepaged fails the allowable order check and >>> does not >>> scan the tmpfs file for collapse. >> >> Ugh. >> >> But really I think this isn't quite accurate - what you mean to say I >> think is >> that when _nothing else_ causes the mm to be considered for khugepaged >> collapse, >> an MADV_HUGEPAGE-advised tmpfs VMA alone does not cause scanning to >> commence. > > Yes. > >>> After commit 6beeab870e70 ("mm: shmem: move >>> shmem_huge_global_enabled() into >>> shmem_allowable_huge_orders()"), the shmem/tmpfs allowable order >>> check reads >>> vma->vm_flags directly.  However, when MADV_HUGEPAGE is handled, >>> khugepaged_enter_vma() is called before the VMA's vm_flags have been >>> updated, >>> so the check uses stale flags and incorrectly rejects the VMA for >>> collapse. >>> As a result, khugepaged does not collapse the tmpfs file into PMD >>> order in time. >> >> Could we at least refer to the non-deprecated field in the commit >> message? >> i.e. vma->flags. >> >> Probably worth mentioning VMA_HUGEPAGE_BIT also. > > Sure. > > >>> Fix this by passing vm_flags as a parameter to >>> shmem_allowable_huge_orders() >>> instead of reading it from the vm_area_struct. >> >> Ugh this is so disgusting. >> >> I understand this is a fix for a bug to be backported but couldn't we >> just >> achieve the same without having to add a deprecated field to be passed >> around? >> >> As you say the khugepaged_enter_vma() isn't really so helpful in >> hugepage_madvise(). >> >> But you could add this to the bottom of madvise_update_vma(): >> >>     if (vma_flags_test(&new_vma_flags, VMA_HUGEPAGE_BIT)) >>         khugepaged_enter_vma(vma, new_flags); >> >> I don't think this is really egregious on this code path and could go >> some way >> towards us eliminating the silly thing of passing around flags-to-be-set. > > This is not the point (maybe I didn't describe it clearly). The point is > that the allowable orders check for tmpfs in shmem_huge_global_enabled() > (called by shmem_allowable_huge_orders()) uses a stale vma flag. > > static unsigned int shmem_huge_global_enabled(struct inode *inode, > pgoff_t index, >             loff_t write_end, bool shmem_huge_force, >             struct vm_area_struct *vma, >             vm_flags_t vm_flags) > { >     ...... >     switch (SHMEM_SB(inode->i_sb)->huge) { > >     ...... >     case SHMEM_HUGE_ADVISE: >         if (vm_flags & VM_HUGEPAGE) >             return THP_ORDERS_ALL_FILE_DEFAULT; >         fallthrough; >     default: >         return 0; >     } > } > > So we should pass the new vma flags for shmem_allowable_huge_orders() to > check the allowable orders for tmpfs. Changing madvise_update_vma() > doesn't help with the allowable orders check for tmpfs. Sorry for misreading your code (I need a coffee before reading the email :)). Please ignore my reply. After looking at the code again, yes, this can work. If nobody rejects, I will follow your suggestion in v2. Thanks.