Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 7 Dec 2022 11:25:40 -0800
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc:     Muchun Song <muchun.song@linux.dev>, linux-kernel@vger.kernel.org,
        Linux Memory Management List <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Muchun Song <songmuchun@bytedance.com>,
        Matthew Wilcox <willy@infradead.org>,
        Mina Almasry <almasrymina@google.com>,
        Miaohe Lin <linmiaohe@huawei.com>, hughd@google.com,
        tsahu@linux.ibm.com, jhubbard@nvidia.com,
        David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH mm-unstable v5 01/10] mm: add folio dtor and order setter
 functions
Message-ID: <Y5DotA/pLbakONGl@monkey>
References: <20221129225039.82257-1-sidhartha.kumar@oracle.com>
 <20221129225039.82257-2-sidhartha.kumar@oracle.com>
 <BAD34D59-187B-4BB3-B139-7983A8B62648@linux.dev>
 <Y5ALigw0kUO/B3z2@monkey>
 <4161AF1A-9508-4DF8-B756-FEB476EB32B5@linux.dev>
 <Y5DXivFOA+bO0IYQ@monkey>
 <b995eccf-5818-84ee-560e-20c00f9936b4@oracle.com>
 <d5755326-a71e-242b-5e1e-86fc897dc292@oracle.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d5755326-a71e-242b-5e1e-86fc897dc292@oracle.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?1KD4bMdzJXRva8HCuscSHChoHFGk5zOY93ATYzWBeqT3DN15bdKGijsmNk?=
 =?iso-8859-1?Q?EFWmm5ha1d0Xgh5IK3WxL0QJrW8Xhwu1Abax23JCVqUMyW1UwkmZJGHtSY?=
 =?iso-8859-1?Q?2UDl3uPrRBs3nwr+otno55LQtA05wtIHZXTLn7pal2FTz9JWN/GYQseXRk?=
 =?iso-8859-1?Q?ymcnaWNqL3y9ueNiecsoCxrTzgHK43TG6m8jAV63iA17DrmNbop30jAUxN?=
 =?iso-8859-1?Q?gpfwHx0XkVkyn1OZMkX1d7wEAdak64VhQ+qzYf57gs0oVtrEeC2cRjH2YJ?=
 =?iso-8859-1?Q?z7CWJNubtRf+9I+fWRRSTJrqzqE4mjqrp3esoVeGpHCGnuu5QslKMCXtey?=
 =?iso-8859-1?Q?3DSkrZKWRCMUF0R66A9IuA4U3EP+t3aRhh6ngJv4FpC2f5XXi0qdrabxB6?=
 =?iso-8859-1?Q?nKg4gslZtwcgxwJE/w6Dj+MpNXqbqmgYrfODnEv+U09QuRbgyUQOvo1hUi?=
 =?iso-8859-1?Q?HkR6FaQR/xVfMEcpTH4Dna7BhDEfOZMmWVZ6ImvEi25HKj0ArhImNkXvvM?=
 =?iso-8859-1?Q?Dac4V92fOTq3xTiCR+7yzr0+VaUin0NtpbbY/r1sX5JG5G7511OxaM+nYx?=
 =?iso-8859-1?Q?tux3r8Sf0Wo5OknbZFmD90Kv/V5WNEajxHPSjvO1KWkZ09/a+FAI3SHdYO?=
 =?iso-8859-1?Q?CBdxb81VFJGMFKFlDL/8lauddb+k7KOEIGOp0MATIP+SwBJRGBqx1UfXKJ?=
 =?iso-8859-1?Q?f4tdaUHaDNKmKZ+Cs4qc0fz94aVsGao4d35cbbS3gVlBvByhi8UK7Je27p?=
 =?iso-8859-1?Q?ltUiEC476NJwFvINc2C4yERx3v2twI1y9ceCzS6T8asHEizaMwwTyUOmGD?=
 =?iso-8859-1?Q?Tqq05E4zgv2vQET3GeRWLL2oVrnY4PLL8fV0sbF+GhHZAf14Vk1y7Zzeul?=
 =?iso-8859-1?Q?pD6O1eIg+QqEJNi5XPEAXBMnigtyfc2PIwmUq9LDopOfzJOqYwLN8EXXQq?=
 =?iso-8859-1?Q?21uWwSCKtFMcjAiSsZX1vV3jfMBhIAr2v5GMhnRIeamXC13g43t+XyWMDT?=
 =?iso-8859-1?Q?TXNwsDQOkbD0lK3FlV63z5cIWmP4zioxNuq+jf6aQdXkz9oi1fojpt+3GV?=
 =?iso-8859-1?Q?4sm+WhVgZ9Mj3UK9VkvOKFH/VfVrUgCk0+cxZ8XNccwn52jtb5CX9pIO9J?=
 =?iso-8859-1?Q?8W2uvZf2V/a8VLF1ZBRh8WuZ6DCkfGUUGT/vm+xaLTHrAt7h29x6yryp4F?=
 =?iso-8859-1?Q?lQMg1oDmqrWLCBleWtF/45ZKEYdaXVTM5AKF3QDRk3VVJrfKtHUAjHF+Vf?=
 =?iso-8859-1?Q?EwgUvfsBJGA5Qu4tWuV0PYCHITt53OH6aEU05x/QakdpgbwHYmVA99jNfW?=
 =?iso-8859-1?Q?Z0Dfe9GzH/UFBpDWq2N2guVBwIdyWb7HjPR0vAnMN0yKujhbH25+JHuAIt?=
 =?iso-8859-1?Q?KHLcgXJwRXHhNyru5q87WAPPuEkuAbze1EXpo9D/POAJFvd6uHA7/z9Lk3?=
 =?iso-8859-1?Q?2vzkNW1WGpyZmHdF+Ljrs9ao3NuOXGaOp0eMICaeR0IO3zZTbxrbuWlLXQ?=
 =?iso-8859-1?Q?+y8IxH1kPDGwAvlrjqjLeJFtLY+aNHfagBiNrrGjdjym+CDF/OLtlH19v6?=
 =?iso-8859-1?Q?dnBaEa9kexb2O5SYXQTM9bP/f9mtN78wv97LYY9fFA6oyc9S1ivkB8/CO0?=
 =?iso-8859-1?Q?M2INGzSDkDSXNKQRYEaQakfA9DLjihHS3pu+kXD8N4avgAwjEbRZev7Q?=
 =?iso-8859-1?Q?=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a812800-956e-4c23-89d1-08dad888d51c
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2022 19:25:43.0321
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gZNJXtu5GGtvHiMPNKLZjDsxlMen9R031+hsONHUXWSPImao19beq83d9BgD87Jyde24Idz/6BUaYnRruX4mjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR10MB6740
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-12-07_09,2022-12-07_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0
 suspectscore=0 phishscore=0 malwarescore=0 spamscore=0 mlxscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2212070164
X-Proofpoint-GUID: UFJa5H2K-Ax7Efz2Pz4dpvuPZnCfl97m
X-Proofpoint-ORIG-GUID: UFJa5H2K-Ax7Efz2Pz4dpvuPZnCfl97m
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 12/07/22 11:05, Sidhartha Kumar wrote:
> On 12/7/22 10:49 AM, Sidhartha Kumar wrote:
> > On 12/7/22 10:12 AM, Mike Kravetz wrote:
> > > On 12/07/22 12:11, Muchun Song wrote:
> > > > > On Dec 7, 2022, at 11:42, Mike Kravetz <mike.kravetz@oracle.com> wrote:
> > > > > On 12/07/22 11:34, Muchun Song wrote:
> > > > 
> > > > Agree. It has confused me a lot. I suggest changing the code to the
> > > > followings. The folio_test_large() check is still to avoid unexpected
> > > > users for OOB.
> > > > 
> > > > static inline void folio_set_compound_order(struct folio *folio,
> > > > ??????????????????????? unsigned int order)
> > > > {
> > > > ????VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
> > > > ????// or
> > > > ????// if (!folio_test_large(folio))
> > > > ????//???? return;
> > > > 
> > > > ????folio->_folio_order = order;
> > > > #ifdef CONFIG_64BIT
> > > > ????folio->_folio_nr_pages = order ? 1U << order : 0;
> > > > #endif
> > > > }
> > > 
> > > I think the VM_BUG_ON_FOLIO is appropriate as it would at least flag
> > > data corruption.
> > > 
> > As Mike pointed out, my intention with supporting the 0 case was to
> > cleanup the __destroy_compound_gigantic_page code by moving the ifdef
> > CONFIG_64BIT lines to folio_set_compound_order(). I'll add the
> > VM_BUG_ON_FOLIO line as well as a comment to make it clear it is not
> > normally supported.
> > 
> > > Thinking about this some more, it seems that hugetlb is the only caller
> > > that abuses folio_set_compound_order (and previously set_compound_order)
> > > by passing in a zero order.? Since it is unlikely that anyone knows of
> > > this abuse, it might be good to add a comment to the routine to note
> > > why it handles the zero case.? This might help prevent changes which
> > > would potentially break hugetlb.
> > 
> > +/*
> > + * _folio_nr_pages and _folio_order are invalid for
> > + * order-zero pages. An exception is hugetlb, which passes
> > + * in a zero order in __destroy_compound_gigantic_page().
> > + */
> >  ?static inline void folio_set_compound_order(struct folio *folio,
> >  ??????????????? unsigned int order)
> >  ?{
> > +?????? VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
> > +
> >  ??????? folio->_folio_order = order;
> >  ?#ifdef CONFIG_64BIT
> >  ??????? folio->_folio_nr_pages = order ? 1U << order : 0;
> > 
> > Does this comment work?
> > 
> > 
> 
> I will change the comment from referencing
> __destory_compound_gigantic_page()
> to __destroy_compound_gigantic_folio, although
> __prep_compound_gigantic_folio() is another user of
> folio_set_compound_order(folio, 0). Should the sentence just be "An
> exception is hugetlb, which passes in a zero order"?

How about a comment like this?

/*
 * folio_set_compound_order is generally passed a non-zero order to
 * set up/create a large folio.  However, hugetlb code abuses this by
 * passing in zero when 'dissolving' a large folio.
 */

My only concern is that someone may modify the routine such that it no
longer works when passed zero order.  It is not likely as anyone should
notice the special case for zero, and look for callers.
-- 
Mike Kravetz