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 7E2ACC36013 for ; Mon, 31 Mar 2025 15:58:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0812228000C; Mon, 31 Mar 2025 11:58:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 009B5280001; Mon, 31 Mar 2025 11:58:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D501A28000C; Mon, 31 Mar 2025 11:58:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9CDD7280001 for ; Mon, 31 Mar 2025 11:58:52 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9B27B140F96 for ; Mon, 31 Mar 2025 09:59:10 +0000 (UTC) X-FDA: 83281398060.12.C817F75 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf24.hostedemail.com (Postfix) with ESMTP id 3E042180005 for ; Mon, 31 Mar 2025 09:59:07 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=UJMBgGsb; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Us48FF6g; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=UJMBgGsb; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Us48FF6g; dmarc=none; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743415148; 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=IdJX3EPh9zBNVXcfpydPnfMxZ6GfiCP+RhGRVnB0bTs=; b=eof71LJ0lYT58mnVmq3M6OIcLDBaJXWzGtdN3En1OPk+yq/7Psekgn5upDYQMWHZPmbJIj A89ucMEXOeJK+kcKBXOPShVpan5RyQe4HhCp2Vzfh7HTHW+R3y2eCHvF0ayr80u43A6aeo pZCQtqK5/NuRs5rb0ie4KrV31VlwPHc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743415148; a=rsa-sha256; cv=none; b=AIV7Ak9o0HRxSTBHFnyXEKmFMpwGpXQi0virl1HGtNNT3MLsaH83JflRpOys+yox0cctE8 h5f8HWnw55xcKZdorxjxqUq6XZeCJpOr+dHCqZ0erVvUDQIC3esLDTEU65kzLVrZyl2/rj 6GkwYfYfon6PxgJpmJwadt76EeXYlRc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=UJMBgGsb; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Us48FF6g; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=UJMBgGsb; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Us48FF6g; dmarc=none; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0C0BC1F38D; Mon, 31 Mar 2025 09:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1743415146; 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=IdJX3EPh9zBNVXcfpydPnfMxZ6GfiCP+RhGRVnB0bTs=; b=UJMBgGsb89hYXxoQNZR7fxon4nMOezI+Ogxs4FPU/uSPd488PWUX3t4XSkDzJGmPphfBWY f6AZ8/j5NtpRLPIZ7pedpQtQAv1g7MYbR8rCAkugodzHyA/NapHfkGWYmXJDfR6NdFWUEM W4Hn6hHmT4+qoE6MicMOHW2l31glqk8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1743415146; 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=IdJX3EPh9zBNVXcfpydPnfMxZ6GfiCP+RhGRVnB0bTs=; b=Us48FF6gfumWf0od57vWzU7yqIIbPhn9LfQpqRxMcSwD+7A8lb89Azbp/uIeoIhb0zNbJ1 34oigXPf6BORX6DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1743415146; 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=IdJX3EPh9zBNVXcfpydPnfMxZ6GfiCP+RhGRVnB0bTs=; b=UJMBgGsb89hYXxoQNZR7fxon4nMOezI+Ogxs4FPU/uSPd488PWUX3t4XSkDzJGmPphfBWY f6AZ8/j5NtpRLPIZ7pedpQtQAv1g7MYbR8rCAkugodzHyA/NapHfkGWYmXJDfR6NdFWUEM W4Hn6hHmT4+qoE6MicMOHW2l31glqk8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1743415146; 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=IdJX3EPh9zBNVXcfpydPnfMxZ6GfiCP+RhGRVnB0bTs=; b=Us48FF6gfumWf0od57vWzU7yqIIbPhn9LfQpqRxMcSwD+7A8lb89Azbp/uIeoIhb0zNbJ1 34oigXPf6BORX6DA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id DFA2F13A1F; Mon, 31 Mar 2025 09:59:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id q6IeNmln6mdWWwAAD6G6ig (envelope-from ); Mon, 31 Mar 2025 09:59:05 +0000 Message-ID: <39586553-6185-4b83-b18a-3716caf2f3cf@suse.cz> Date: Mon, 31 Mar 2025 11:59:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [GIT PULL] Introduce try_alloc_pages for 6.15 Content-Language: en-US To: Sebastian Sewior , Alexei Starovoitov Cc: Linus Torvalds , bpf , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Andrew Morton , Peter Zijlstra , Steven Rostedt , Michal Hocko , Shakeel Butt , linux-mm , LKML References: <20250327145159.99799-1-alexei.starovoitov@gmail.com> <20250331071409.ycI7q6Q2@linutronix.de> From: Vlastimil Babka In-Reply-To: <20250331071409.ycI7q6Q2@linutronix.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3E042180005 X-Stat-Signature: bfci8kru5n4qwdqqxodgfczcj1ffhw9p X-Rspam-User: X-HE-Tag: 1743415147-679212 X-HE-Meta: U2FsdGVkX1/xcGoxUUjeSGPDgFm/+4Z2vw4jnfO9EjfzE8rT44wG5AATeprA5SE/mXFzhVCX9kACaN5xMKP/olsUVl54tzIdcTDe5dIkR0x78DUENfJNmaEheLGLb71qOtxqLXPRy286pT2mOMyvh9B6ak2Q1pGS3F+arMtMqqg97B4aC0aFXfHkBTA4KPvcGJxeiovhXetzLClrX/fKSVvdSSzi/x66JKxm5EJNNOH9A9k+GTDCDt8mnKUY+PrRLcoMUiNVQzeZMODY7aD8J1VeZBLN3kdtFKuAquuICEyo19B7e2uX62u2L1TbOFRwROeot8YgTpt4x867bgmJ0YvUFIkw6yLSwgQsFaW2MeAtubCsdLW6wo2/Pd2ldtjRejXIhMvYB96mM2Cns/cTZmaAnfI4vOKVVKtYWMntc59xWhEIwhRu7+n3cYEK0fr3eifMjN3q/5MvfaK+hlEAc3UGWAMxAbtO/qh2EEg8u23dGFzZfRlUvX9yJBXXauaYiVQX0N69lJzc1advH+KRV5O+XJwByA4jki8DNPwNQ7HRr6JtslVV7lv9qn7V2lD5vTbAracq6PRaqVn+VbmcEvm2YCSMLLROH3qnwHvSKt7sXZjQpj7M4B1nWDc9SR9o/qHXI15DFrkA++ZRmAGZtTZsskIb4trnVg+eEqcI6JRJIXxYaQfr7AcTVh+QMiTkqRNgmJ5u0QKXys6WTluAFrulpN1gRlhaQSWSETldjFvu0N0Mpn/YRAl9h/J5ctWIjxOxrcOCy7fmorjVANPBL+0aAsjz/xpremOuPLcTOixlBsqZKmNO8hnLIkOF7KkQ7Qt+FLy5Ro66RIX5bDBVxymaFe6WT1GLCCQkypC4guurJvWZsITMROa57Vkmb/kkIcfdPOkJfs9fhrNgcIMWag7Kp+ov0czgZQG77/kTya1oo9oXQ/XW0oSSt02tO97LDZqP61h6C+b/RSyltpG 4BhdJfxQ bi571nQm1tmx80Ti80BYE3cd2OPnQ1aCO0VK6GPvZ8E+CF+GmOgWEhXN7EOkhWZFPckOsgwebEY9einLCSuhZ8N+dw/K8I8LYeY0odcglWMqEddVTaxWZMUsbjZq18nJ/Wdxzo/AQPnhZL0rSB+at2voRJlY8fZ79V0v8uoOzJv7a+PfSyFv/jjK7zSXwnV5PMJVSk6G3hAfoXTDadXVZk07aMw3z8jgPxINr8ZjVVMLvAK9Xlj5yC1h4xkd79HaJ3Xq/Pa1LgIj4k22UeuKTSqZBL8RLXV4AmNqDaOXeqtIFa1DM2J0SSU6P32p4JoFCsm7aNINXTWFHoTabu9HmiX71MQI0hPNkNvRgHH0Kg9jaeM8A00WJCc6+XBLIyLhqVpOPFVqjY/FrBA7vAheugLUgeT9ZFNv+8MLrHdn2JPufoLYLDlG2cbiLaosEdtXKhh6T+oU6nQ+73qv42zSZX72K8AFNzPpPrVT8yEfgW5gQPWlWr26Dc8ALyjalSRLoE2ma99EAXRyPWE9phHm/MCkqTg== 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: List-Subscribe: List-Unsubscribe: On 3/31/25 09:14, Sebastian Sewior wrote: > On 2025-03-30 14:49:25 [-0700], Alexei Starovoitov wrote: >> On Sun, Mar 30, 2025 at 1:56 PM Linus Torvalds >> wrote: >> > So maybe "nmisafe_local_lock_t" or something in that vein? >> > >> > Please fix this up, There aren't *that* many users of >> > "localtry_xyzzy", let's get this fixed before there are more of them. >> >> Ok. Agree with the reasoning that the name doesn't quite fit. >> >> nmisafe_local_lock_t name works for me, >> though nmisafe_local_lock_irqsave() is a bit verbose. >> >> Don't have better name suggestions at the moment. >> >> Sebastian, Vlastimil, >> what do you prefer ? > > nmisafe_local_lock_t sounds okay assuming the "nmisafe" part does not > make it look like it can be used without the trylock part in NMI context. Yes I was going to point out that e.g. "nmisafe_local_lock_irqsave()" seems rather misleading to me as this operation is not a nmisafe one? I think it comes back to what we discussed in previous versions of the patchset. IMHO conceptually it's still a local_lock, it just supports the new trylock operations. However, to make them possible (on non-RT) if a particular lock instance is to be used with the trylock anywhere, it needs the new "acquired" field, and for the non-trylock operations to work with the field too. So (to inform Linus) the earlier attempt [1] was to just change the existing local_lock_t, but that adds the overhead of the field and manipulating it for instances that don't use trylock. The following attempt [2] meant there would be only a new local_trylock_t type, but the existing locking operations would remain the same, relying on _Generic() parts inside them. It was preferred to make the implementation more obvious, but then we have the naming issue for the operations in addition to the type... [1] https://lore.kernel.org/bpf/20241218030720.1602449-4-alexei.starovoitov@gmail.com/ [2] https://lore.kernel.org/bpf/20250124035655.78899-4-alexei.starovoitov@gmail.com/ > But yeah, it sounds better than the previous one. > > Sebastian