From: Shivank Garg <shivankg@amd.com>
To: Liu Ye <liuye@kylinos.cn>,
brauner@kernel.org, dhowells@redhat.com,
akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] mm/mm.h: Write folio->_flags_1 & 0xff as a macro definition
Date: Wed, 12 Feb 2025 11:10:21 +0530 [thread overview]
Message-ID: <50f02ce2-85f8-4dda-b3c4-ad3f20f8b9a2@amd.com> (raw)
In-Reply-To: <20250212025843.80283-3-liuye@kylinos.cn>
On 2/12/2025 8:28 AM, Liu Ye wrote:
> There are multiple locations in mm.h where (folio->_flags_1 & 0xff) is
> used. Write it as a macro definition to improve the readability and
> maintainability of the code.
>
> Signed-off-by: Liu Ye <liuye@kylinos.cn>
> ---
> include/linux/mm.h | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 7b1068ddcbb7..750e75f45557 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1098,6 +1098,8 @@ int vma_is_stack_for_current(struct vm_area_struct *vma);
> struct mmu_gather;
> struct inode;
>
> +#define FOLIO_ORDER(folio) ((folio)->_flags_1 & 0xff)
This folio order calculation is only valid for !large folios.
When it's a single page (not a large folio), the memory is interpreted as struct page.
struct folio {
...
union {
struct {
unsigned long _flags_1;
unsigned long _head_1;
/* public: */
atomic_t _large_mapcount;
atomic_t _entire_mapcount;
atomic_t _nr_pages_mapped;
atomic_t _pincount;
#ifdef CONFIG_64BIT
unsigned int _folio_nr_pages;
#endif
/* private: the union with struct page is transitional */
};
struct page __page_1;
};
...
}
I feel this to be risky, considering someone may directly use FOLIO_ORDER() macro
without folio_test_large() check.
Correct macro should look like:
#define FOLIO_ORDER(folio) (folio_test_large(folio) ? ((folio)->_flags_1 & 0xff) : 0)
Thanks,
Shivank
> +
> /*
> * compound_order() can be called without holding a reference, which means
> * that niceties like page_folio() don't work. These callers should be
> @@ -1111,7 +1113,7 @@ static inline unsigned int compound_order(struct page *page)
>
> if (!test_bit(PG_head, &folio->flags))
> return 0;
> - return folio->_flags_1 & 0xff;
> + return FOLIO_ORDER(folio);
> }
>
> /**
> @@ -1127,7 +1129,7 @@ static inline unsigned int folio_order(const struct folio *folio)
> {
> if (!folio_test_large(folio))
> return 0;
> - return folio->_flags_1 & 0xff;
> + return FOLIO_ORDER(folio);
> }
>
> #include <linux/huge_mm.h>
> @@ -2061,7 +2063,7 @@ static inline long folio_nr_pages(const struct folio *folio)
> #ifdef CONFIG_64BIT
> return folio->_folio_nr_pages;
> #else
> - return 1L << (folio->_flags_1 & 0xff);
> + return 1L << FOLIO_ORDER(folio);
> #endif
> }
>
> @@ -2086,7 +2088,7 @@ static inline unsigned long compound_nr(struct page *page)
> #ifdef CONFIG_64BIT
> return folio->_folio_nr_pages;
> #else
> - return 1L << (folio->_flags_1 & 0xff);
> + return 1L << FOLIO_ORDER(folio);
> #endif
> }
>
next prev parent reply other threads:[~2025-02-12 5:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 2:58 [PATCH 0/2] mm: Optimize folio_order Liu Ye
2025-02-12 2:58 ` [PATCH 1/2] mm/folio_queue: Delete __folio_order and use folio_order directly Liu Ye
2025-02-12 5:19 ` Shivank Garg
2025-02-12 5:25 ` Dev Jain
2025-02-12 11:28 ` David Howells
2025-02-12 2:58 ` [PATCH 2/2] mm/mm.h: Write folio->_flags_1 & 0xff as a macro definition Liu Ye
2025-02-12 5:12 ` Dev Jain
2025-02-12 5:40 ` Shivank Garg [this message]
2025-02-12 7:11 ` liuye
[not found] ` <1739340112672653.3.seg@mailgw.kylinos.cn>
2025-02-12 7:07 ` liuye
2025-02-12 9:06 ` Dev Jain
2025-02-12 12:36 ` Matthew Wilcox
2025-02-12 16:22 ` David Hildenbrand
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=50f02ce2-85f8-4dda-b3c4-ad3f20f8b9a2@amd.com \
--to=shivankg@amd.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuye@kylinos.cn \
/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: link
Be 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.