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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DD37C64EC4 for ; Thu, 9 Mar 2023 08:38:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB4946B0071; Thu, 9 Mar 2023 03:38:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D64276B0072; Thu, 9 Mar 2023 03:38:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2BA2280001; Thu, 9 Mar 2023 03:38:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AEDE46B0071 for ; Thu, 9 Mar 2023 03:38:18 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 746A3A692C for ; Thu, 9 Mar 2023 08:38:18 +0000 (UTC) X-FDA: 80548707876.12.081C618 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf23.hostedemail.com (Postfix) with ESMTP id B027A14000B for ; Thu, 9 Mar 2023 08:38:15 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ROyaLxOg; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf23.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678351096; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L9yiM7YX1LH9gY11Mx4sM/MvapXNHfRacAa76keNXQ4=; b=ZJxNaozoCFXGiIhwrJcmdkrLpmMciWf1jTXzCRDmvotUvRG/3PKiELj9HEaq4aCOs+eykp uVyizlXmyJ59kK4p9XNztj8erpUUHwVW2EHy+Yse4LcP6dq4i6r2uEAVUvz7O1Lz0pKr8r 0CvyItCLzZVdLxvolwAy8KBOp/TGaAY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ROyaLxOg; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf23.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678351096; a=rsa-sha256; cv=none; b=lro957Dh6GhNhsjPcpwCn1MQGuyV5dFMrMr54jgKciesM3kftdhYE+xUKQfJHbV0USQb5y i290hE1mXSaIEqNVzNPHbVTiJNh0cjwhvRVRhe8uIAaUG7YL9pUwwQUFX7KtMncXfJ6+54 5X+Q7UVTO50mnWUzj/kFAhAO0losZ1o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678351095; x=1709887095; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=dlGlMy640JD1Y7x742ADAbcu0VK+hnDBh/IIP7/8FeA=; b=ROyaLxOg2XJe9Uvhqqq+DHaNczny/D6z+3yQL1UThHV0n+xQOxh9/D4j ZijE2hlLu2fjgUtGQlLN3I0RANLyZ9ntTOS3z+Aey1J6HkGaI28hiaB92 Ekhbyw0n8+v8i7R95wShX7fHdeAO5KVrGxkvOQyOxiQzVlA1oXMUx1drn EI1otepOErU3yPD/PNQXfjMWha4AtodDJodZ6GW+m3zWK0SprS2ZKKarc iNSDdXHRxVra402qpoUmcEPcx0S2+ebp7nHwOf5BSzYfgcCXG7ggRhLTr Wuu01iWat1S+CyIVbrl0+AHbDLfQ113fNlVZR5DhYDxIZLD2zyNIer3qn A==; X-IronPort-AV: E=McAfee;i="6500,9779,10643"; a="398968365" X-IronPort-AV: E=Sophos;i="5.98,245,1673942400"; d="scan'208";a="398968365" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2023 00:38:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10643"; a="707520420" X-IronPort-AV: E=Sophos;i="5.98,245,1673942400"; d="scan'208";a="707520420" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2023 00:38:11 -0800 From: "Huang, Ying" To: Vlastimil Babka Cc: Linus Torvalds , Andrew Morton , linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org, Matthew Wilcox Subject: Re: [GIT PULL] hotfixes for 6.3-rc1 References: <20230304131528.4645d19a2ab897fb7518159e@linux-foundation.org> <20230304152058.de91bf7abf424383ce31d500@linux-foundation.org> <87jzzu7jt9.fsf@yhuang6-desk2.ccr.corp.intel.com> <43f35191-9147-0aec-cb57-0bc14d041039@suse.cz> Date: Thu, 09 Mar 2023 16:37:07 +0800 In-Reply-To: <43f35191-9147-0aec-cb57-0bc14d041039@suse.cz> (Vlastimil Babka's message of "Wed, 8 Mar 2023 11:39:28 +0100") Message-ID: <877cvq8gng.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B027A14000B X-Stat-Signature: j19j3pmk173ubyodambkpcpp3p681kyr X-HE-Tag: 1678351095-843240 X-HE-Meta: U2FsdGVkX1+YA8Km6uqpdMR2zJ+jUkutHTzvasPWJWCZ/GPir+veXwOfKpZq0PirRW+MtzhOddZD9vhO8w6l+P3qwO2jdadDZRHtsvotLqLT0FdDZQWNwbkzgF7QUi7vzyyjy1D0e7IlhYdFubS9PHYExMkCjpSeQDRJIa6ZcWDgYwzDbhV19efVQkARQ062808wjZft4rLHtMQawJ9j5y07shVY4RQDQyYaZ7FlknQCZP8vhgxMidfng7YYHwdaqlb2j9uyqKaEsXuO13lyCRvvkny4cAdnotHxh8FQMoMHk3NHZ46z9idoWKTjNFKmGYEQwyR5TAkdBLIFil4oYIClmkqPPrxZ5wo2gENZK7YPJndGeD1eYYpZBqFKziQ1b4MOwH8b715O6mlZla2LrJ67Gh5YbJr7BC69jgFOQm8mITjFzwZjw26rN70yJMHjpOiQmQnPiAUhd5KjwFzB8O53FPaBjduPWF5RK4U+pumB/p1lsaRT7Y857HRvdtMvPghdmfXdlMyDJF+E3eJkoEhn6/g2g67qolk1HsEKWHhp0jg7v72ppiFIhiNjQRiAxeey2zPPZX/cEZrNNmeD0DHQsvbf73a41xiG066rkWFkmfMROkVJRh+YztCkfDpMOk9fl754s7CFydh2Sc9uRcp3WZ8e8emTmKRUINPCWoENj15CoaIRCkd32qVLTliYE6ShklHe4TwzaVQNydPa/yaLprqJpBv2+FXsxGBLsalDCrlkA3B7oMP80NofsngsiPRrRcNvCFE6QUHHrKhI1NMSukRTeGUndTCJ1gMDf0GF8hBYmLJkMMqD4vYHYczIHFWDj7nPuzkMwyyOn9vdsD2d4om9AXBlWeHsNFLhvdRiWUx0N4ptwPdMT+JjfWP8aSiHpStdirJbKwmRpNqwC05TylmP6NXW9qVqZ3I4Ksc117O4cIxpMm931pHQXV8c6jvKgE8Xhk4Xr4rHT65 MlLIftbh /V2SE4c8Eck/4G/EzR0bIdUk3NJHIt9Edjv8TwSPJ5EfaCdAzmHZLYLAcisfVMZB+E/fUqLXD1leR5sUtzwl+kWD+eey1gAHlCp+JkMuv/etdauK2/cJIZeGTvtdZo4X26eOntLm7AJoXJYFVKjs5XpNKKrVaoDRE2t0IfZTKk+lth4i0ToB/XpG6GIJI4uvAzFs7gfztZSPOzy3MBfhXpsERssr6jki86agOqNir31RGDueYuE7HP5oYdw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Vlastimil Babka writes: > On 3/6/23 02:25, Huang, Ying wrote: >> Hi, Linus, >>=20 >> Linus Torvalds writes: >>=20 >>> On Sat, Mar 4, 2023 at 3:21=E2=80=AFPM Andrew Morton wrote: >>>> >>>> Ah. Ying did it this way: >>> >>> Yeah, I saw that patch flying past, but I actually think that it only >>> silences the warning almost by mistake. There's nothing fundamental in >>> there that a compiler wouldn't just follow across two assignments, and >>> it just happens to now not trigger any more. >>> >>> Assigning to a union entry is a more fundamental operation in that >>> respect. Not that the compiler still doesn't see that it's assigning a >>> value that in the end is not really type compatible, so a different >>> version of gcc could still warn, but at that point I feel like it's >>> more of an actual compiler bug than just "oh, the compiler didn't >>> happen to follow the cast through a temporary". >>=20 >> Yes. Your fix is much better. This can be used for >> __page_set_anon_rmap() family too to make the code look better? > > Those are trickier due to the PAGE_MAPPING_ANON tagging bit which your > code doesn't need to handle because you can simply store an untagged > anon_vma pointer. Otherwise we could have the union at the struct page > level already (but probably not at this point as IIRC Matthew is > planning to have completely separate types for anon and file folios). > > So right now we have e.g. folio_get_anon_vma() using unsigned long as > the intermediate variable, page_move_anon_rmap() using a void * > variable, __page_set_anon_rmap() casting through a (void *) ... Is there > a single recommended way for "tagged pointers" that we could unify that t= o? Ah, you are right. We need to deal with tagging bit and maybe struct movable_operations *. I tried to write the below debug patch (only build test it). The code adds 1 or 2 lines for each function. But to be honest, the original force casting method appears more natural to me. Best Regards, Huang, Ying ---------------------------8<------------------------------------ >From 68a0f54921beca8aeaa8fe78867e62b5a66658b8 Mon Sep 17 00:00:00 2001 From: Huang Ying Date: Thu, 9 Mar 2023 15:29:58 +0800 Subject: [PATCH] dbg mapping_ptr --- mm/rmap.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index 8632e02661ac..50ee208baff9 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -466,6 +466,13 @@ void __init anon_vma_init(void) SLAB_PANIC|SLAB_ACCOUNT); } =20 +union mapping_ptr { + struct address_space *mapping; + unsigned long tag; + struct anon_vma *anon_vma; + struct movable_operations *mops; +}; + /* * Getting a lock on a stable anon_vma from a page off the LRU is tricky! * @@ -493,16 +500,17 @@ void __init anon_vma_init(void) struct anon_vma *folio_get_anon_vma(struct folio *folio) { struct anon_vma *anon_vma =3D NULL; - unsigned long anon_mapping; + union mapping_ptr mptr; =20 rcu_read_lock(); - anon_mapping =3D (unsigned long)READ_ONCE(folio->mapping); - if ((anon_mapping & PAGE_MAPPING_FLAGS) !=3D PAGE_MAPPING_ANON) + mptr.mapping =3D READ_ONCE(folio->mapping); + if ((mptr.tag & PAGE_MAPPING_FLAGS) !=3D PAGE_MAPPING_ANON) goto out; if (!folio_mapped(folio)) goto out; =20 - anon_vma =3D (struct anon_vma *) (anon_mapping - PAGE_MAPPING_ANON); + mptr.tag &=3D ~PAGE_MAPPING_FLAGS; + anon_vma =3D mptr.anon_vma; if (!atomic_inc_not_zero(&anon_vma->refcount)) { anon_vma =3D NULL; goto out; @@ -1115,18 +1123,20 @@ int folio_total_mapcount(struct folio *folio) void page_move_anon_rmap(struct page *page, struct vm_area_struct *vma) { void *anon_vma =3D vma->anon_vma; + union mapping_ptr mptr; struct folio *folio =3D page_folio(page); =20 VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); VM_BUG_ON_VMA(!anon_vma, vma); =20 - anon_vma +=3D PAGE_MAPPING_ANON; + mptr.anon_vma =3D anon_vma; + mptr.tag |=3D PAGE_MAPPING_ANON; /* * Ensure that anon_vma and the PAGE_MAPPING_ANON bit are written * simultaneously, so a concurrent reader (eg folio_referenced()'s * folio_test_anon()) will not see one without the other. */ - WRITE_ONCE(folio->mapping, anon_vma); + WRITE_ONCE(folio->mapping, mptr.mapping); SetPageAnonExclusive(page); } =20 @@ -1142,6 +1152,7 @@ static void __page_set_anon_rmap(struct folio *folio,= struct page *page, struct vm_area_struct *vma, unsigned long address, int exclusive) { struct anon_vma *anon_vma =3D vma->anon_vma; + union mapping_ptr mptr; =20 BUG_ON(!anon_vma); =20 @@ -1162,8 +1173,9 @@ static void __page_set_anon_rmap(struct folio *folio,= struct page *page, * the PAGE_MAPPING_ANON type identifier, otherwise the rmap code * could mistake the mapping for a struct address_space and crash. */ - anon_vma =3D (void *) anon_vma + PAGE_MAPPING_ANON; - WRITE_ONCE(folio->mapping, (struct address_space *) anon_vma); + mptr.anon_vma =3D anon_vma; + mptr.tag |=3D PAGE_MAPPING_ANON; + WRITE_ONCE(folio->mapping, mptr.mapping); folio->index =3D linear_page_index(vma, address); out: if (exclusive) --=20 2.39.2