[{"id":3669529,"web_url":"http://patchwork.ozlabs.org/comment/3669529/","msgid":"<6b8f1536-444c-e75a-c4b3-d5cbe7c1786e@ssi.bg>","list_archive_url":null,"date":"2026-03-26T08:32:45","subject":"Re: [PATCH 2/2] ipvs: Guard access of HK_TYPE_KTHREAD cpumask with\n RCU","submitter":{"id":2825,"url":"http://patchwork.ozlabs.org/api/people/2825/","name":"Julian Anastasov","email":"ja@ssi.bg"},"content":"Hello,\n\nOn Tue, 24 Mar 2026, Waiman Long wrote:\n\n> The ip_vs_ctl.c file and the associated ip_vs.h file are the only places\n> in the kernel where HK_TYPE_KTHREAD cpumask is being retrieved and used.\n> Now that HK_TYPE_KTHREAD/HK_TYPE_DOMAIN cpumask can be changed at run\n> time. We need to use RCU to guard access to this cpumask to avoid a\n> potential UAF problem as the returned cpumask may be freed before it\n> is being used.\n> \n> Signed-off-by: Waiman Long \n> ---\n> include/net/ip_vs.h | 20 ++++++++++++++++----\n> net/netfilter/ipvs/ip_vs_ctl.c | 13 ++++++++-----\n> 2 files changed, 24 insertions(+), 9 deletions(-)\n> \n> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h\n> index 29a36709e7f3..17c85a575ef4 100644\n> --- a/include/net/ip_vs.h\n> +++ b/include/net/ip_vs.h\n> @@ -1155,7 +1155,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)\n> \treturn ipvs->sysctl_run_estimation;\n> }\n> \n> -static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)\n> +static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)\n> {\n> \tif (ipvs->est_cpulist_valid)\n> \t\treturn ipvs->sysctl_est_cpulist;\n> @@ -1273,7 +1273,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)\n> \treturn 1;\n> }\n> \n> -static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)\n> +static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)\n> {\n> \treturn housekeeping_cpumask(HK_TYPE_KTHREAD);\n> }\n> @@ -1290,6 +1290,18 @@ static inline int sysctl_est_nice(struct netns_ipvs *ipvs)\n> \n> #endif\n> \n\n\tMay be there is little fuzz here, due to the recent\nchanges in the nf-next tree. If this is a bugfix due to the\nmissing RCU protection, may be you should add Fixes line too\nand use the nf tree. Probably, there will be fuzz/collisions with\nthe changes in the nf-next tree...\n\n> +static inline bool sysctl_est_cpulist_empty(struct netns_ipvs *ipvs)\n> +{\n> +\tguard(rcu)();\n> +\treturn cpumask_empty(__sysctl_est_cpulist(ipvs));\n> +}\n> +\n> +static inline unsigned int sysctl_est_cpulist_weight(struct netns_ipvs *ipvs)\n> +{\n> +\tguard(rcu)();\n> +\treturn cpumask_weight(__sysctl_est_cpulist(ipvs));\n> +}\n> +\n> /* IPVS core functions\n> * (from ip_vs_core.c)\n> */\n> @@ -1604,7 +1616,7 @@ static inline void ip_vs_est_stopped_recalc(struct netns_ipvs *ipvs)\n> \t/* Stop tasks while cpulist is empty or if disabled with flag */\n> \tipvs->est_stopped = !sysctl_run_estimation(ipvs) ||\n> \t\t\t (ipvs->est_cpulist_valid &&\n> -\t\t\t cpumask_empty(sysctl_est_cpulist(ipvs)));\n> +\t\t\t sysctl_est_cpulist_empty(ipvs));\n> #endif\n> }\n> \n> @@ -1620,7 +1632,7 @@ static inline bool ip_vs_est_stopped(struct netns_ipvs *ipvs)\n> static inline int ip_vs_est_max_threads(struct netns_ipvs *ipvs)\n> {\n> \tunsigned int limit = IPVS_EST_CPU_KTHREADS *\n> -\t\t\t cpumask_weight(sysctl_est_cpulist(ipvs));\n> +\t\t\t sysctl_est_cpulist_weight(ipvs);\n> \n> \treturn max(1U, limit);\n> }\n> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c\n> index 35642de2a0fe..f38a2e2a9dc5 100644\n> --- a/net/netfilter/ipvs/ip_vs_ctl.c\n> +++ b/net/netfilter/ipvs/ip_vs_ctl.c\n> @@ -1973,11 +1973,14 @@ static int ipvs_proc_est_cpumask_get(const struct ctl_table *table,\n> \n> \tmutex_lock(&ipvs->est_mutex);\n> \n> -\tif (ipvs->est_cpulist_valid)\n> -\t\tmask = *valp;\n> -\telse\n> -\t\tmask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);\n> -\tret = scnprintf(buffer, size, \"%*pbl\\n\", cpumask_pr_args(mask));\n> +\t/* HK_TYPE_KTHREAD cpumask needs RCU protection */\n\n\tCan we switch IPVS to use HK_TYPE_DOMAIN? The initial\nintention was to follow the code in kthread.c. Then you can \nreconsider if HK_TYPE_KTHREAD should be alias to HK_TYPE_DOMAIN,\nmay be not if there are no other users...\n\n> +\tscoped_guard(rcu) {\n> +\t\tif (ipvs->est_cpulist_valid)\n> +\t\t\tmask = *valp;\n> +\t\telse\n> +\t\t\tmask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);\n> +\t\tret = scnprintf(buffer, size, \"%*pbl\\n\", cpumask_pr_args(mask));\n> +\t}\n> \n> \tmutex_unlock(&ipvs->est_mutex);\n> \n> -- \n> 2.53.0\n\nRegards\n\n--\nJulian Anastasov ","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","netfilter-devel@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (4096-bit key;\n unprotected) header.d=ssi.bg header.i=@ssi.bg header.a=rsa-sha256\n header.s=ssi header.b=6x1g62Px;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11437-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (4096-bit key) header.d=ssi.bg header.i=@ssi.bg header.b=\"6x1g62Px\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=193.238.174.39","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ssi.bg","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=ssi.bg"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fhH9g06tKz1yGD\n\tfor ; Thu, 26 Mar 2026 19:33:42 +1100 (AEDT)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 1FC82303F7E3\n\tfor ; Thu, 26 Mar 2026 08:33:18 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 91DAA3AD501;\n\tThu, 26 Mar 2026 08:33:14 +0000 (UTC)","from mx.ssi.bg (mx.ssi.bg [193.238.174.39])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 91AE228506A;\n\tThu, 26 Mar 2026 08:33:08 +0000 (UTC)","from mx.ssi.bg (localhost [127.0.0.1])\n\tby mx.ssi.bg (Potsfix) with ESMTP id AE496217FB;\n\tThu, 26 Mar 2026 10:32:58 +0200 (EET)","from box.ssi.bg (box.ssi.bg [193.238.174.46])\n\tby mx.ssi.bg (Potsfix) with ESMTPS;\n\tThu, 26 Mar 2026 10:32:57 +0200 (EET)","from ja.ssi.bg (unknown [213.16.62.126])\n\tby box.ssi.bg (Potsfix) with ESMTPSA id 1088560A78;\n\tThu, 26 Mar 2026 10:32:54 +0200 (EET)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby ja.ssi.bg (8.18.1/8.18.1) with ESMTP id 62Q8WjID021116;\n\tThu, 26 Mar 2026 10:32:45 +0200"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1774513992; cv=none;\n b=Y1uASaZ1JYQcPrqDCANoxiiTj+OTJQsFfHO/kuM8Hghszr/YUtuRtD4LP1s4t1Oefqn81G08s7Nk3VEvpnFVPlAHtONjtnMGUWLvJIWT/LXDQUl5W4enVTtccHn4d2T0LK6sC87vHxvrx1vfgQc5vYnaVm3FGs+ZDwvX0TODHP4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1774513992; c=relaxed/simple;\n\tbh=zFJihH7S9d8lhKpyC2+Bj5Ej46SSk23yPU+CPIQQYUE=;\n\th=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=m0SB2BY4IzLQ0StuDexTp7OKDGiu2rom8YsBzYI3LJD4OO+uD816t4ssoXdx1t7TxwlTzcf0utZY8fnV2S735ABF1pw8o62tfPdDDhZOoDxnIj+8Tjc8iXWbwsWWLkepiLrWJHhvwsnVtnx93xQqui4V8scKpEkaHRS5F2VQam8=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ssi.bg;\n spf=pass smtp.mailfrom=ssi.bg;\n dkim=pass (4096-bit key) header.d=ssi.bg header.i=@ssi.bg header.b=6x1g62Px;\n arc=none smtp.client-ip=193.238.174.39","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ssi.bg; h=cc:cc\n\t:content-type:content-type:date:from:from:in-reply-to:message-id\n\t:mime-version:references:reply-to:subject:subject:to:to; s=ssi;\n\t bh=6I+plcb8eOm5Rjsl7JTC/dDFJZWTUZs1pJqBClmoxnY=; b=6x1g62PxtaJ5\n\t6OLKZjPRJgm6jTTJcMJpNEZp4NzgLpDi/qV2pNgBFuOznW/AXHkxEdUa6sf1sIv4\n\tj0RU6iPROIk2MwNfmayVyrqRxxMFSJd29M0fhX9omsUmSle64/AmRTKYOgG76cv2\n\tFcQJ0TUEJACdv37EanZ4cTqxNK8Hi52eoHjc5dynIDSOzd7nPugIhPttDol9WBCw\n\tfjQXBy+qAFDI7oe4t29m3NUgoWODi5OmWcqaW7ybLweEgY8eTEdWLEs9ZwvUiafW\n\t9WXg3Y2jiobhwDJipqXguKzHahKZmLWztcNGUHl+nVSltJ0umq2KLdUL+Jd3pQp7\n\tReOnt/hkBoartRKRdqb7mJn/zy3DLXgmBal3yaUqlGESMeBkLUu4ySImkqm7SD7p\n\tawFjygPVOuWNmj72BjyMhluRcnkW+Vs3RdxQXnylhjPp1vmp2c/orNkdp4J7kkAp\n\tYPkERJu/BK8R83g/HMlVTV9RSUnfGD0njkq1XqRctNXVM9J2A95kgIAR74B3Lt3Q\n\tZftPuqwMGEOyQq1ZitAkYTmjCHIII9Gn62tsGQFY9ntbiMI7AMlCjSHmsX0gB7/5\n\t0R9blgeQ1Up3YlC6eXmY2iK/GgVHrIpKTI/zQUHU/y56xkkujVY7QehFAU3eXeSN\n\tGaI7bb9svpczZ5LSCr/U6f6iEhqTUGE=","Date":"Thu, 26 Mar 2026 10:32:45 +0200 (EET)","From":"Julian Anastasov ","To":"Waiman Long ","cc":"Simon Horman ,\n \"David S. Miller\" ,\n David Ahern , Eric Dumazet ,\n Jakub Kicinski , Paolo Abeni ,\n Pablo Neira Ayuso ,\n Florian Westphal , Phil Sutter ,\n Frederic Weisbecker ,\n Chen Ridong , Phil Auld ,\n linux-kernel , netdev@vger.kernel.org,\n lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,\n coreteam@netfilter.org, sheviks ","Subject":"Re: [PATCH 2/2] ipvs: Guard access of HK_TYPE_KTHREAD cpumask with\n RCU","In-Reply-To":"<20260324151827.2006656-3-longman@redhat.com>","Message-ID":"<6b8f1536-444c-e75a-c4b3-d5cbe7c1786e@ssi.bg>","References":"<20260324151827.2006656-1-longman@redhat.com>\n <20260324151827.2006656-3-longman@redhat.com>","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}},{"id":3671711,"web_url":"http://patchwork.ozlabs.org/comment/3671711/","msgid":"","list_archive_url":null,"date":"2026-03-31T14:23:44","subject":"Re: [PATCH 2/2] ipvs: Guard access of HK_TYPE_KTHREAD cpumask with\n RCU","submitter":{"id":71281,"url":"http://patchwork.ozlabs.org/api/people/71281/","name":"Waiman Long","email":"longman@redhat.com"},"content":"On 3/26/26 4:32 AM, Julian Anastasov wrote:\n> \tHello,\n>\n> On Tue, 24 Mar 2026, Waiman Long wrote:\n>\n>> The ip_vs_ctl.c file and the associated ip_vs.h file are the only places\n>> in the kernel where HK_TYPE_KTHREAD cpumask is being retrieved and used.\n>> Now that HK_TYPE_KTHREAD/HK_TYPE_DOMAIN cpumask can be changed at run\n>> time. We need to use RCU to guard access to this cpumask to avoid a\n>> potential UAF problem as the returned cpumask may be freed before it\n>> is being used.\n>>\n>> Signed-off-by: Waiman Long \n>> ---\n>> include/net/ip_vs.h | 20 ++++++++++++++++----\n>> net/netfilter/ipvs/ip_vs_ctl.c | 13 ++++++++-----\n>> 2 files changed, 24 insertions(+), 9 deletions(-)\n>>\n>> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h\n>> index 29a36709e7f3..17c85a575ef4 100644\n>> --- a/include/net/ip_vs.h\n>> +++ b/include/net/ip_vs.h\n>> @@ -1155,7 +1155,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)\n>> \treturn ipvs->sysctl_run_estimation;\n>> }\n>> \n>> -static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)\n>> +static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)\n>> {\n>> \tif (ipvs->est_cpulist_valid)\n>> \t\treturn ipvs->sysctl_est_cpulist;\n>> @@ -1273,7 +1273,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)\n>> \treturn 1;\n>> }\n>> \n>> -static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)\n>> +static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)\n>> {\n>> \treturn housekeeping_cpumask(HK_TYPE_KTHREAD);\n>> }\n>> @@ -1290,6 +1290,18 @@ static inline int sysctl_est_nice(struct netns_ipvs *ipvs)\n>> \n>> #endif\n>> \n> \tMay be there is little fuzz here, due to the recent\n> changes in the nf-next tree. If this is a bugfix due to the\n> missing RCU protection, may be you should add Fixes line too\n> and use the nf tree. Probably, there will be fuzz/collisions with\n> the changes in the nf-next tree...\nThanks for the suggestion, I will rebase the patches on top of the \nnf-next tree.\n>\n>> +static inline bool sysctl_est_cpulist_empty(struct netns_ipvs *ipvs)\n>> +{\n>> +\tguard(rcu)();\n>> +\treturn cpumask_empty(__sysctl_est_cpulist(ipvs));\n>> +}\n>> +\n>> +static inline unsigned int sysctl_est_cpulist_weight(struct netns_ipvs *ipvs)\n>> +{\n>> +\tguard(rcu)();\n>> +\treturn cpumask_weight(__sysctl_est_cpulist(ipvs));\n>> +}\n>> +\n>> /* IPVS core functions\n>> * (from ip_vs_core.c)\n>> */\n>> @@ -1604,7 +1616,7 @@ static inline void ip_vs_est_stopped_recalc(struct netns_ipvs *ipvs)\n>> \t/* Stop tasks while cpulist is empty or if disabled with flag */\n>> \tipvs->est_stopped = !sysctl_run_estimation(ipvs) ||\n>> \t\t\t (ipvs->est_cpulist_valid &&\n>> -\t\t\t cpumask_empty(sysctl_est_cpulist(ipvs)));\n>> +\t\t\t sysctl_est_cpulist_empty(ipvs));\n>> #endif\n>> }\n>> \n>> @@ -1620,7 +1632,7 @@ static inline bool ip_vs_est_stopped(struct netns_ipvs *ipvs)\n>> static inline int ip_vs_est_max_threads(struct netns_ipvs *ipvs)\n>> {\n>> \tunsigned int limit = IPVS_EST_CPU_KTHREADS *\n>> -\t\t\t cpumask_weight(sysctl_est_cpulist(ipvs));\n>> +\t\t\t sysctl_est_cpulist_weight(ipvs);\n>> \n>> \treturn max(1U, limit);\n>> }\n>> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c\n>> index 35642de2a0fe..f38a2e2a9dc5 100644\n>> --- a/net/netfilter/ipvs/ip_vs_ctl.c\n>> +++ b/net/netfilter/ipvs/ip_vs_ctl.c\n>> @@ -1973,11 +1973,14 @@ static int ipvs_proc_est_cpumask_get(const struct ctl_table *table,\n>> \n>> \tmutex_lock(&ipvs->est_mutex);\n>> \n>> -\tif (ipvs->est_cpulist_valid)\n>> -\t\tmask = *valp;\n>> -\telse\n>> -\t\tmask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);\n>> -\tret = scnprintf(buffer, size, \"%*pbl\\n\", cpumask_pr_args(mask));\n>> +\t/* HK_TYPE_KTHREAD cpumask needs RCU protection */\n> \tCan we switch IPVS to use HK_TYPE_DOMAIN? The initial\n> intention was to follow the code in kthread.c. Then you can\n> reconsider if HK_TYPE_KTHREAD should be alias to HK_TYPE_DOMAIN,\n> may be not if there are no other users...\n\nYes, I can certainly switch to use HK_TYPE_DOMAIN instead. The reason I \nkeep HK_TYPE_KTHREAD is that it may not be obvious to others that \nkthread is now following the HK_TYPE_DOMAIN cpumask, \nkeeping  HK_TYPE_KTHREAD but making it an alias can make that clear.\n\n\n>> +\tscoped_guard(rcu) {\n>> +\t\tif (ipvs->est_cpulist_valid)\n>> +\t\t\tmask = *valp;\n>> +\t\telse\n>> +\t\t\tmask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);\n>> +\t\tret = scnprintf(buffer, size, \"%*pbl\\n\", cpumask_pr_args(mask));\n>> +\t}\n>> \n>> \tmutex_unlock(&ipvs->est_mutex);\n>> \n>> -- \n>> 2.53.0\n> Regards\n>\n> --\n> Julian Anastasov \n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","netfilter-devel@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=U7VDlINX;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.232.135.74; helo=sto.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11517-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com\n header.b=\"U7VDlINX\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=170.10.133.124","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=redhat.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=redhat.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4flVlq3YbPz1yGH\n\tfor ; Wed, 01 Apr 2026 01:25:59 +1100 (AEDT)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 57A133045C1A\n\tfor ; Tue, 31 Mar 2026 14:25:08 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 1C0483FB047;\n\tTue, 31 Mar 2026 14:24:59 +0000 (UTC)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 667593F7A8D\n\tfor ; Tue, 31 Mar 2026 14:24:57 +0000 (UTC)","from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-84-JphZul2mPUKkspbNxYcMHQ-1; Tue,\n 31 Mar 2026 10:24:45 -0400","from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 937301886BE2;\n\tTue, 31 Mar 2026 14:23:49 +0000 (UTC)","from [10.22.80.26] (unknown [10.22.80.26])\n\tby mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id 921FD19560AB;\n\tTue, 31 Mar 2026 14:23:45 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1774967098; cv=none;\n b=nLnE/JJI39TYeuo+946Kr++nOmt+0Bakkfid2nAFfw2k3tbqLlko4vlQpdezTSN5OXetOPjjbVJYOSuWpOl9+Cm1Z5ljbCAalarm8HXvshmubwxKcEyIJrcZl3UrU1s+NCMqvOvUfLTRvrixU/B5qqdyaMbI2p/4+KumIeDZ1Kw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1774967098; c=relaxed/simple;\n\tbh=qq8PLy0+8DA4C0FTyjzMTsfyH4GsvOGNzncTx4/Waq4=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=Y3Vc7c3yRQGsHtXfDxQ6O+JxGDCukgiYooR12sDtyNbMPCvBm44DfLarONrAXJqJPvEKT+yDIs/I7aLndfOnoeBP0AFVr5/+WgIpD167dgMDut4CI4xhAeoju2mDEa7g+z5yHxK8r6iGe4p8rT++fHtXc4bswOuKkTWaqFm4XG0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=redhat.com;\n spf=pass smtp.mailfrom=redhat.com;\n dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com\n header.b=U7VDlINX; arc=none smtp.client-ip=170.10.133.124","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1774967096;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=xGbExH2WyJPhqEH/I3Ex4mJo86JJcu+eMS2b1MQ0hyc=;\n\tb=U7VDlINXk+kHDY0y7FWqWTlqnoSSokJI/vqnP/RjvZXNoVcJ7CSkkWeHfgbhrFlsvUGihL\n\tx3GIdRm48nMTaAv3RAcHHXI2X40HAYSuENJttkh2wmGJq1yBZVVzIIx3tOe9D+3bOkPJQ8\n\t+FQeBUgCOr0C5Wz6fjuq1gnQYVdWNkA=","X-MC-Unique":"JphZul2mPUKkspbNxYcMHQ-1","X-Mimecast-MFC-AGG-ID":"JphZul2mPUKkspbNxYcMHQ_1774967082","Message-ID":"","Date":"Tue, 31 Mar 2026 10:23:44 -0400","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH 2/2] ipvs: Guard access of HK_TYPE_KTHREAD cpumask with\n RCU","To":"Julian Anastasov ","Cc":"Simon Horman , \"David S. Miller\"\n , David Ahern ,\n Eric Dumazet , Jakub Kicinski ,\n Paolo Abeni , Pablo Neira Ayuso ,\n Florian Westphal , Phil Sutter ,\n Frederic Weisbecker ,\n Chen Ridong , Phil Auld ,\n linux-kernel , netdev@vger.kernel.org,\n lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,\n coreteam@netfilter.org, sheviks ","References":"<20260324151827.2006656-1-longman@redhat.com>\n <20260324151827.2006656-3-longman@redhat.com>\n <6b8f1536-444c-e75a-c4b3-d5cbe7c1786e@ssi.bg>","Content-Language":"en-US","From":"Waiman Long ","In-Reply-To":"<6b8f1536-444c-e75a-c4b3-d5cbe7c1786e@ssi.bg>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.12"}}]