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 DF4ABC678D5 for ; Wed, 8 Mar 2023 10:39:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75B626B0072; Wed, 8 Mar 2023 05:39:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 709EE6B0074; Wed, 8 Mar 2023 05:39:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D243280001; Wed, 8 Mar 2023 05:39:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4A80F6B0072 for ; Wed, 8 Mar 2023 05:39:13 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1D8EE80B98 for ; Wed, 8 Mar 2023 10:39:13 +0000 (UTC) X-FDA: 80545383786.30.1003A19 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf22.hostedemail.com (Postfix) with ESMTP id 1D944C0014 for ; Wed, 8 Mar 2023 10:39:09 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vkOnQ1gE; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=NrmAxNRa; spf=pass (imf22.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678271950; 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=KNZPDd1h+V7c8y4zbj3TUyGQ4AIRsQ8PJ9MlbnzDo+A=; b=iUKLDmltWJH4a5f+bRGOM00yv2AThPWIo9oiLQjtT9y2eApIgacbxHcSSnih2xThdv4Yc1 D/FfOZ8pc2KtndopGmGbq3cqsmqxfVOoWZnoReX9P7M+qv4JT3Q03SqTZ0WZkLmaEXCWjo fvby0DJbcPKYvS31OKGTmfuDko2atxk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vkOnQ1gE; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=NrmAxNRa; spf=pass (imf22.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678271950; a=rsa-sha256; cv=none; b=Jk3Q7ZzlkAPh8GMgNGamzePqFUToUa3B7blkmKx+DFIKKxqcEbcFqj4Es9Zoznr9nJTLUi JikvgA/Zl8CKE6IPU6eQ1qax31+0QXQFIwa3iZh0KRba73aGkOhsPPrRlsadrCX7v20K8u KVhfv7D+8q5yyUfZHOidpQRiWf8tbxM= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C981F21A0C; Wed, 8 Mar 2023 10:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1678271948; h=from:from:reply-to: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; bh=KNZPDd1h+V7c8y4zbj3TUyGQ4AIRsQ8PJ9MlbnzDo+A=; b=vkOnQ1gEmHEclBKwGNUyQvnWPcskuZJZjqA2ec8jNzh3vPISlrZYDAjOZTNfxLB6NsiGHa 1QjN5PPCzkQ1oLxoqv0zTVyGq4No6KKVEmvJRPmvbn0YL1p0WmG+GRPmOo1goxeGdZGPND r+s25UhN+nrMPEWJCWEdSU26Qa7K9Yw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1678271948; h=from:from:reply-to: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; bh=KNZPDd1h+V7c8y4zbj3TUyGQ4AIRsQ8PJ9MlbnzDo+A=; b=NrmAxNRa9WBs1/vFXW7SeQXuv5AOB60b3HPiSqsC1utUFtBtVwgEW3hxyDt9l6YfXOFWvH wZGz9xNc3sZK9yAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A2DD51391B; Wed, 8 Mar 2023 10:39:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 24+SJsxlCGSeYwAAMHmgww (envelope-from ); Wed, 08 Mar 2023 10:39:08 +0000 Message-ID: <43f35191-9147-0aec-cb57-0bc14d041039@suse.cz> Date: Wed, 8 Mar 2023 11:39:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [GIT PULL] hotfixes for 6.3-rc1 Content-Language: en-US To: "Huang, Ying" , Linus Torvalds Cc: Andrew Morton , linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org, Matthew Wilcox References: <20230304131528.4645d19a2ab897fb7518159e@linux-foundation.org> <20230304152058.de91bf7abf424383ce31d500@linux-foundation.org> <87jzzu7jt9.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Vlastimil Babka In-Reply-To: <87jzzu7jt9.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: r7w3u69ittp5asbmok9trppht4f59bao X-Rspam-User: X-Rspamd-Queue-Id: 1D944C0014 X-Rspamd-Server: rspam06 X-HE-Tag: 1678271949-609824 X-HE-Meta: U2FsdGVkX195sNR0VizZQzEYLfmlfv+vFqptC51MYy8zxD8jnXFuvzJF0GPfQnTNKD/hiXcaX3TCKhIjsLTd3ykTurAmwr7WZKlHhzUMx8pOVOI9qhi9XC9tU+KqsAUQnpol+hNz0QQybU95Ln9oABtsG8rZG+/qLNzX8307L/IJc4lyRXqwo6mKGACepa6HOSBMRmv8rPx7va+q1x2kgPwCIl5hEY9kPF3UvnMgHWUHOFCp7XUJruutL2EIqDttnpS8PV1bPd3Wc4OLoSSM1us6t9EVeexQ+654f/WvvHKAHxdJk8PMhv9mtwy6TJWQYyHvQlzsEYf8fP6+tqNV7WpHtRlUv2ejdTu2udXIFwJrh6+At6MF8A2YewGo2CUXVAILHrEV/Kg9Av6P+M8YcITR+qeSJI6uw5bEucGqFisytkoqE6jGSamoTp9I40GY4eRezoRzbGy5a12+4YLfqAWiHAp5lmau3w6Xw9nWJMJ1FbUkksFNTrmAICfQuXg5Lo+p2My9VpDMomlp5hSWGK41HBSHp/XO4fh/7LdiGrpy9Wc71wXwpf5kRkq6Wz+MHXsdgz1au6pBeGOlX0VhQOhLEWY+3urRjwD5V2f90FS7rL9lKg/42a7mC1fbDoHMbcUpLSeBx/dy+p8dtiKcAd1yongG+VIXGs+72pgA9cOqMak8izNK2uguJ4XhRxNtUvGfW++FyWyQRIWV1RRRN/ftKg3XeN/5ZzUBPBxzJIPGgWj1yPYl18GSXkOC0RRfAriKMxWYBOrxw7P0WzyxY0PI1n0/+9PeRVOsDwOClwRtFrL/fBRUEDrFOcI9aN+yppFS9XF08LjeTzH45AdlWt4vMMJfo1UrnepsdOlQdW7lYOHe3qkQTse4APVu5Q61G7yG+GMLQg+KLmWqWK3P8B2k+VO/3LmoNf7eG5ERB5E3hhaj+2adTiBro17A8eofzCaUaPL7B79GKNOu7or kWSC3MMV gZifBml8TiM4op6nSy8FkkXFcaWzJSXJ+HImMAHXiJBV8nHSBI9aNTPU9nARBHQdxZ1OGvjjTMr+0fALUviiddCVDEzmJ6U1xaeM3pLalvZ3KeDdOsowgYQ3Nd6WL5D8v2QG+FWV/g8pGigpkTjJaVG776QBp3nNl2FhExgXbBk5kwWp1d19w33UzDvmVGP38ggv0945veHb0hwRd7BX9qxLrSYo1YKykSAz1L1CXLJNEsES0gMN1dnWqlfUhpITwNMBfL64UwBbX+187z6PNJ0AoEnyPQPrx7EiVKNTMS37QwsWMfNA+zhZVGQD9oUEawYKctLY1+mWqkYkRMU+h0kStPDoeKXwQM7Q0aqNVpdwao8w= 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: On 3/6/23 02:25, Huang, Ying wrote: > Hi, Linus, > > Linus Torvalds writes: > >> On Sat, Mar 4, 2023 at 3:21 PM 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". > > 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 to? > Best Regards, > Huang, Ying >