[{"id":3682180,"web_url":"http://patchwork.ozlabs.org/comment/3682180/","msgid":"<a4f06cd8-c17e-d64d-8129-5797fe7b6452@ssi.bg>","list_archive_url":null,"date":"2026-04-24T19:41:54","subject":"Re: [PATCHv3 net] ipvs: fix races around est_mutex and est_cpulist","submitter":{"id":2825,"url":"http://patchwork.ozlabs.org/api/people/2825/","name":"Julian Anastasov","email":"ja@ssi.bg"},"content":"Hello,\n\nOn Fri, 24 Apr 2026, Julian Anastasov wrote:\n\n> Sashiko reports for races and possible crash around\n> the usage of est_cpulist_valid and sysctl_est_cpulist.\n> The problem is that we do not lock est_mutex in some\n> places which can lead to wrong write ordering and\n> as result problems when calling cpumask_weight()\n> and cpumask_empty().\n> \n> Fix them by moving the est_max_threads read/write under\n> locked est_mutex. Do the same for one ip_vs_est_reload_start()\n> call to protect the cpumask_empty() usage of sysctl_est_cpulist.\n> \n> To remove the chance of deadlock while stopping the\n> estimation kthreads, keep the data structure for kthread 0\n> even after last estimator is removed and do not hold mutexes\n> while stopping this task. Now we will use a new flag 'needed'\n> to know when kthread 0 should run. The kthreads above 0\n> do not use mutexes, so stop them under est_mutex because\n> their kthread data still can be destroyed if they do not\n> serve estimators. Now all kthreads will be started by\n> the est_reload_work to properly serialize the stop/start\n> for kthread 0.\n> \n> Reduce the use of service_mutex in ip_vs_est_calc_limits()\n> because under est_mutex we can safely walk est_kt_arr to\n> stop the kthreads above slot 0.\n> \n> Link: https://sashiko.dev/#/patchset/20260331165015.2777765-1-longman%40redhat.com\n> Link: https://sashiko.dev/#/patchset/20260420171308.87192-1-ja%40ssi.bg\n> Link: https://sashiko.dev/#/patchset/20260422125123.40658-1-ja%40ssi.bg\n> Fixes: f0be83d54217 (\"ipvs: add est_cpulist and est_nice sysctl vars\")\n> Signed-off-by: Julian Anastasov <ja@ssi.bg>\n\n\tSashiko found another use-after-free [1] that is easy to\nfix here. I'll send new patch version tomorrow...\n\npw-bot: changes-requested\n\n[1] https://sashiko.dev/#/patchset/20260424175858.54752-1-ja%40ssi.bg\n\nRegards\n\n--\nJulian Anastasov <ja@ssi.bg>","headers":{"Return-Path":"\n <netfilter-devel+bounces-12193-incoming=patchwork.ozlabs.org@vger.kernel.org>","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=iiq54waw;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-12193-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=\"iiq54waw\"","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 tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::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 4g2NdX6dV7z1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 25 Apr 2026 05:42:08 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 14A3C3000729\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 24 Apr 2026 19:42:06 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 468A81C861D;\n\tFri, 24 Apr 2026 19:42:05 +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 AF44A324B1F;\n\tFri, 24 Apr 2026 19:42:00 +0000 (UTC)","from mx.ssi.bg (localhost [127.0.0.1])\n\tby mx.ssi.bg (Potsfix) with ESMTP id CEB8221268;\n\tFri, 24 Apr 2026 22:41:57 +0300 (EEST)","from box.ssi.bg (box.ssi.bg [193.238.174.46])\n\tby mx.ssi.bg (Potsfix) with ESMTPS;\n\tFri, 24 Apr 2026 22:41:56 +0300 (EEST)","from ja.ssi.bg (unknown [213.16.62.126])\n\tby box.ssi.bg (Potsfix) with ESMTPSA id 47293608CE;\n\tFri, 24 Apr 2026 22:41:56 +0300 (EEST)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby ja.ssi.bg (8.18.1/8.18.1) with ESMTP id 63OJfs4O061735;\n\tFri, 24 Apr 2026 22:41:54 +0300"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777059724; cv=none;\n b=U6Ljl6LBDSjP3/yiO6aSeUCZV16aAkQCbBH2cdVtU8KGtRvxXT+2Xh352pNA13qHNB59ZDdGFGLmdzJxad4JOYewYf0ocPLLMlkvAH6EuAy8VMUeCFGNtLTRqi9ih/5WHOF56RH/98I873k4/WEcOtg5llJH9pt3Uw1GR/l8Q/Y=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777059724; c=relaxed/simple;\n\tbh=J4V079oJH/X4SzK+eaSEG3TU+LTBhZnF0URApET19AY=;\n\th=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=W4ZPpsm5yDU6toVmTH6ClIaZs4H+p/wpeus+OvIKKT3zrrp9Y537BH4bNPv4TyyKTUt/a5JPKBLag+gUeTsLQkFLHPvep8QXyhwOfTDWFwAIDl+ssJEqgk0krakFQdte30R7ns7brIpQdIUxiqhNjfO6JL3aX6KEDmxOgyd+6pU=","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=iiq54waw;\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=+lkcq51BXjlUl/RoV+HLZ1U3WWqXQCBySHt2szrrI3E=; b=iiq54wawWI33\n\tQcmNX30ozb30ozHm5Y0Dm27hrKgtl1GV6VYEOiZmX3YzzQUE0K6cgZLwPXantprS\n\tjQx2Jlv5i3wrxqz6pyiDqJakPfMP37UyQxcTrPU80yAlXyYyMcc5faJxkeH91ud5\n\t+JK2Xqx/hvfnx7Sbv4dsMGQsQcncCKyMxyLwEvhAVNihV9LHokplteirlg2d0Rvc\n\tPsDzkJlBlI1eRBL2x7asWmH8h9DARdj+hdf3UHsr/2WBXRylrCasFhIyGtmowL1D\n\tsZsNziN54ndmUvWcCrMHsr513z/vNz6Ki7KM/WSR5ow8Gc+888NwmJFlyFP9eg5R\n\t+wN3xGzcJ/QLIJPfievUFUYYsrDsSDSZs4Nc7kvLYR5KeZnes2BDgmvmGiDDS3yx\n\tKvdPGbENs/2psTWzrU/5Q9+GYzg5deGFbqX0SC/zXsnxDoM5fxgeswQOSrjPnaM4\n\tgkvJsBnxnGK/GX4vqyG8c/cuQenfZ5H8ZTWXUYr2DtDVQ8UaQxXQF0ZyXtIv69oz\n\tZ3JegWPAKxejgXtNYFx3yxzX59c4hUGRudtVMEMbZBTjXd6UrObC7dWt0yg0EGEO\n\tS520T2YhxoHzRQinEmXemkgrKykUcbZ8+UsBmewHb+Y9xXmxCrQVZnPdg96I5lsx\n\t/hGakdNVh7/COSqUlRnr7z3cklHJ2LE=","Date":"Fri, 24 Apr 2026 22:41:54 +0300 (EEST)","From":"Julian Anastasov <ja@ssi.bg>","To":"Simon Horman <horms@verge.net.au>","cc":"Pablo Neira Ayuso <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>,\n        lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org","Subject":"Re: [PATCHv3 net] ipvs: fix races around est_mutex and est_cpulist","In-Reply-To":"<20260424175858.54752-1-ja@ssi.bg>","Message-ID":"<a4f06cd8-c17e-d64d-8129-5797fe7b6452@ssi.bg>","References":"<20260424175858.54752-1-ja@ssi.bg>","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"<netfilter-devel.vger.kernel.org>","List-Subscribe":"<mailto:netfilter-devel+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:netfilter-devel+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}}]