From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71EE8C4332F for ; Wed, 9 Nov 2022 01:38:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229992AbiKIBid (ORCPT ); Tue, 8 Nov 2022 20:38:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229913AbiKIBiQ (ORCPT ); Tue, 8 Nov 2022 20:38:16 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97A5A606A2 for ; Tue, 8 Nov 2022 17:38:14 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 57B53B81CC7 for ; Wed, 9 Nov 2022 01:38:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0586EC433D6; Wed, 9 Nov 2022 01:38:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1667957892; bh=UMWo5P+M32R7nghh/WU1viXf6T/KIQZKn7KFUdsIAtI=; h=Date:To:From:Subject:From; b=PVgLXedn6TTcCNR3Nc7vcQT7CT1+ZSkWOqCH9ELNZxQaJGmR1cozo8YlP02hweaZJ uzyj27QgkwoE+ylyAfzy/oYsvp2i7zHekWYde/7NEygp83Sxh9mH0f3CRZDMgFL44H qpdNtSd0haTCz0y4kZj7YQa1jY1245CrRsgBmJaE= Date: Tue, 08 Nov 2022 17:38:11 -0800 To: mm-commits@vger.kernel.org, willy@infradead.org, william.kucharski@oracle.com, vbabka@suse.cz, songmuchun@bytedance.com, peterx@redhat.com, mike.kravetz@oracle.com, lkp@intel.com, hughd@google.com, ebiederm@xmission.com, dhowells@redhat.com, ccross@google.com, arnd@arndb.de, sidhartha.kumar@oracle.com, akpm@linux-foundation.org From: Andrew Morton Subject: [merged mm-stable] mm-add-private-field-of-first-tail-to-struct-page-and-struct-folio.patch removed from -mm tree Message-Id: <20221109013812.0586EC433D6@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The quilt patch titled Subject: mm: add private field of first tail to struct page and struct folio has been removed from the -mm tree. Its filename was mm-add-private-field-of-first-tail-to-struct-page-and-struct-folio.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Sidhartha Kumar Subject: mm: add private field of first tail to struct page and struct folio Date: Thu, 22 Sep 2022 10:42:04 -0500 Allow struct folio to store hugetlb metadata that is contained in the private field of the first tail page. On 32-bit, _private_1 aligns with page[1].private. Link: https://lkml.kernel.org/r/20220922154207.1575343-3-sidhartha.kumar@oracle.com Signed-off-by: Sidhartha Kumar Acked-by: Mike Kravetz Cc: Arnd Bergmann Cc: Colin Cross Cc: David Howells Cc: "Eric W . Biederman" Cc: Hugh Dickins Cc: kernel test robot Cc: Matthew Wilcox Cc: Muchun Song Cc: Peter Xu Cc: Vlastimil Babka Cc: William Kucharski Signed-off-by: Andrew Morton --- include/linux/mm_types.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/include/linux/mm_types.h~mm-add-private-field-of-first-tail-to-struct-page-and-struct-folio +++ a/include/linux/mm_types.h @@ -144,6 +144,7 @@ struct page { atomic_t compound_pincount; #ifdef CONFIG_64BIT unsigned int compound_nr; /* 1 << compound_order */ + unsigned long _private_1; #endif }; struct { /* Second tail page of compound page */ @@ -264,6 +265,7 @@ struct page { * @_total_mapcount: Do not use directly, call folio_entire_mapcount(). * @_pincount: Do not use directly, call folio_maybe_dma_pinned(). * @_folio_nr_pages: Do not use directly, call folio_nr_pages(). + * @_private_1: Do not use directly, call folio_get_private_1(). * * A folio is a physically, virtually and logically contiguous set * of bytes. It is a power-of-two in size, and it is aligned to that @@ -311,6 +313,7 @@ struct folio { #ifdef CONFIG_64BIT unsigned int _folio_nr_pages; #endif + unsigned long _private_1; }; #define FOLIO_MATCH(pg, fl) \ @@ -338,6 +341,7 @@ FOLIO_MATCH(compound_mapcount, _total_ma FOLIO_MATCH(compound_pincount, _pincount); #ifdef CONFIG_64BIT FOLIO_MATCH(compound_nr, _folio_nr_pages); +FOLIO_MATCH(_private_1, _private_1); #endif #undef FOLIO_MATCH @@ -383,6 +387,16 @@ static inline void *folio_get_private(st return folio->private; } +static inline void folio_set_private_1(struct folio *folio, unsigned long private) +{ + folio->_private_1 = private; +} + +static inline unsigned long folio_get_private_1(struct folio *folio) +{ + return folio->_private_1; +} + struct page_frag_cache { void * va; #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) _ Patches currently in -mm which might be from sidhartha.kumar@oracle.com are mm-hugetlb_cgroup-convert-__set_hugetlb_cgroup-to-folios.patch mm-hugetlb_cgroup-convert-hugetlb_cgroup_from_page-to-folios.patch mm-hugetlb_cgroup-convert-set_hugetlb_cgroup-to-folios.patch mm-hugetlb_cgroup-convert-hugetlb_cgroup_migrate-to-folios.patch mm-hugetlb-convert-isolate_or_dissolve_huge_page-to-folios.patch mm-hugetlb-convert-free_huge_page-to-folios.patch mm-hugetlb_cgroup-convert-hugetlb_cgroup_uncharge_page-to-folios.patch mm-hugeltb_cgroup-convert-hugetlb_cgroup_commit_charge-to-folios.patch mm-hugetlb-convert-move_hugetlb_state-to-folios.patch