From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from forward502b.mail.yandex.net (forward502b.mail.yandex.net [178.154.239.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A8F4192B87 for ; Thu, 12 Sep 2024 15:59:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.154.239.146 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726156786; cv=none; b=LYCTPArCYbAF/Qggjj2FYJDfvZaS3ODszYLJ/LTFJOwHZQqkZ64qn8wdc3vkgjgtMF2uGOYxCuPH53gpcpolT/gXiv/FUgq41dzLAemNM/RzUu/+QNiuf+fur1SBptEXCfzz0+sBQgQxYb3sqnisgWaJdIE6kMEGXa2PMxMY9EY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726156786; c=relaxed/simple; bh=MoMfcM1Jtr/RtubOuBcJdVaSEXScaU8oh1dlpg3sOeI=; h=Message-ID:Date:MIME-Version:To:Cc:References:From:Subject: In-Reply-To:Content-Type; b=gSuLQlXdIsCrRxA4Tvv3Gi4dkKSiaGhTzQYFBOXzEKqkRVlMbh5QLtaFM5Re2EKj//yKCBFZ47vig2fh0NQs230BaF4SFPUaOj+EyYTjgilwKDcH26PLsFMpWg6F4aVnPXKZwJRO6lqChFctKZsfLzaonjnOKNMBDP4t6cXwvhI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex.ru; spf=pass smtp.mailfrom=yandex.ru; dkim=pass (1024-bit key) header.d=yandex.ru header.i=@yandex.ru header.b=Emjb+8ci; arc=none smtp.client-ip=178.154.239.146 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=yandex.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=yandex.ru header.i=@yandex.ru header.b="Emjb+8ci" Received: from mail-nwsmtp-smtp-production-main-91.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-91.sas.yp-c.yandex.net [IPv6:2a02:6b8:c1c:2a89:0:640:c90:0]) by forward502b.mail.yandex.net (Yandex) with ESMTPS id 9C8B15E741; Thu, 12 Sep 2024 18:59:40 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-91.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id dxmC8E5LlW20-ghUb5ZUz; Thu, 12 Sep 2024 18:59:39 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1726156779; bh=MoMfcM1Jtr/RtubOuBcJdVaSEXScaU8oh1dlpg3sOeI=; h=In-Reply-To:Subject:To:From:Cc:Date:References:Message-ID; b=Emjb+8ciDGM018dEUqKAY54AvJg9QjEml4vBS9wQ9TLQ+HjrQexVSBjH46KGdp9Fh tbIZBnM4df4ThCOy7qDf37NwGvmEchgp/0G3mbqOjicVIdWqUSgPsMTeYSMMHFetcc KnOppRvxSFRz7iUXvayswJpg39Luji9HK0Yq5UlA= Authentication-Results: mail-nwsmtp-smtp-production-main-91.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <9c8146a5-c7fc-40ae-81bb-37a2c12c2384@yandex.ru> Date: Thu, 12 Sep 2024 18:59:39 +0300 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Cong Wang Cc: John Fastabend , Jakub Sitnicki , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, lvc-project@linuxtesting.org References: <20240905064257.3870271-1-dmantipov@yandex.ru> <5d23bd86-150f-40a3-ab43-a468b3133bc4@yandex.ru> <1ae54555-0998-4c76-bbb3-60e9746f9688@yandex.ru> Content-Language: en-US From: Dmitry Antipov Autocrypt: addr=dmantipov@yandex.ru; keydata= xsDNBGBYjL8BDAC1iFIjCNMSvYkyi04ln+5sTl5TCU9O5Ot/kaKKCstLq3TZ1zwsyeqF7S/q vBVSmkWHQaj80BlT/1m7BnFECMNV0M72+cTGfrX8edesMSzv/id+M+oe0adUeA07bBc2Rq2V YD88b1WgIkACQZVFCo+y7zXY64cZnf+NnI3jCPRfCKOFVwtj4OfkGZfcDAVAtxZCaksBpTHA tf24ay2PmV6q/QN+3IS9ZbHBs6maC1BQe6clFmpGMTvINJ032oN0Lm5ZkpNN+Xcp9393W34y v3aYT/OuT9eCbOxmjgMcXuERCMok72uqdhM8zkZlV85LRdW/Vy99u9gnu8Bm9UZrKTL94erm 0A9LSI/6BLa1Qzvgwkyd2h1r6f2MVmy71/csplvaDTAqlF/4iA4TS0icC0iXDyD+Oh3EfvgP iEc0OAnNps/SrDWUdZbJpLtxDrSl/jXEvFW7KkW5nfYoXzjfrdb89/m7o1HozGr1ArnsMhQC Uo/HlX4pPHWqEAFKJ5HEa/0AEQEAAc0kRG1pdHJ5IEFudGlwb3YgPGRtYW50aXBvdkB5YW5k ZXgucnU+wsEJBBMBCAAzFiEEgi6CDXNWvLfa6d7RtgcLSrzur7cFAmYEXUsCGwMFCwkIBwIG FQgJCgsCBRYCAwEAAAoJELYHC0q87q+3ghQL/10U/CvLStTGIgjRmux9wiSmGtBa/dUHqsp1 W+HhGrxkGvLheJ7KHiva3qBT++ROHZxpIlwIU4g1s6y3bqXqLFMMmfH1A+Ldqg1qCBj4zYPG lzgMp2Fjc+hD1oC7k7xqxemrMPstYQKPmA9VZo4w3+97vvnwDNO7iX3r0QFRc9u19MW36wq8 6Yq/EPTWneEDaWFIVPDvrtIOwsLJ4Bu8v2l+ejPNsEslBQv8YFKnWZHaH3o+9ccAcgpkWFJg Ztj7u1NmXQF2HdTVvYd2SdzuJTh3Zwm/n6Sw1czxGepbuUbHdXTkMCpJzhYy18M9vvDtcx67 10qEpJbe228ltWvaLYfHfiJQ5FlwqNU7uWYTKfaE+6Qs0fmHbX2Wlm6/Mp3YYL711v28b+lp 9FzPDFqVPfVm78KyjW6PcdFsKu40GNFo8gFW9e8D9vwZPJsUniQhnsGF+zBKPeHi/Sb0DtBt enocJIyYt/eAY2hGOOvRLDZbGxtOKbARRwY4id6MO4EuSs7AzQRgWIzAAQwAyZj14kk+OmXz TpV9tkUqDGDseykicFMrEE9JTdSO7fiEE4Al86IPhITKRCrjsBdQ5QnmYXcnr3/9i2RFI0Q7 Evp0gD242jAJYgnCMXQXvWdfC55HyppWazwybDiyufW/CV3gmiiiJtUj3d8r8q6laXMOGky3 7sRlv1UvjGyjwOxY6hBpB2oXdbpssqFOAgEw66zL54pazMOQ6g1fWmvQhUh0TpKjJZRGF/si b/ifBFHA/RQfAlP/jCsgnX57EOP3ALNwQqdsd5Nm1vxPqDOtKgo7e0qx3sNyk05FFR+f9px6 eDbjE3dYfsicZd+aUOpa35EuOPXS0MC4b8SnTB6OW+pmEu/wNzWJ0vvvxX8afgPglUQELheY +/bH25DnwBnWdlp45DZlz/LdancQdiRuCU77hC4fnntk2aClJh7L9Mh4J3QpBp3dh+vHyESF dWo5idUSNmWoPwLSYQ/evKynzeODU/afzOrDnUBEyyyPTknDxvBQZLv0q3vT0UiqcaL7ABEB AAHCwPYEGAEIACAWIQSCLoINc1a8t9rp3tG2BwtKvO6vtwUCZgRdSwIbDAAKCRC2BwtKvO6v t9sFC/9Ga7SI4CaIqfkye1EF7q3pe+DOr4NsdsDxnPiQuG39XmpmJdgNI139TqroU5VD7dyy 24YjLTH6uo0+dcj0oeAk5HEY7LvzQ8re6q/omOi3V0NVhezdgJdiTgL0ednRxRRwNDpXc2Zg kg76mm52BoJXC7Kd/l5QrdV8Gq5WJbLA9Kf0pTr1QEf44bVR0bajW+0Lgyb7w4zmaIagrIdZ fwuYZWso3Ah/yl6v1//KP2ppnG0d9FGgO9iz576KQZjsMmQOM7KYAbkVPkZ3lyRJnukrW6jC bdrQgBsPubep/g9Ulhkn45krX5vMbP3wp1mJSuNrACQFbpJW3t0Da4DfAFyTttltVntr/ljX 5TXWnMCmaYHDS/lP20obHMHW1MCItEYSIn0c5DaAIfD+IWAg8gn7n5NwrMj0iBrIVHBa5mRp KkzhwiUObL7NO2cnjzTQgAVUGt0MSN2YfJwmSWjKH6uppQ7bo4Z+ZEOToeBsl6waJnjCL38v A/UwwXBRuvydGV0= Subject: Re: [PATCH RFC net] net: sockmap: avoid race between sock_map_destroy() and sk_psock_put() In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/11/24 7:45 PM, Cong Wang wrote: > I guess you totally misunderstand my point. As a significant sockmap > contributor, I am certainly aware of sockmap users. My point is that I > needed to narrow down the problem to CONFIG_RDS when I was debugging it. I've narrowed down the problem to possible race condition between two functions. "Narrowing down" the problem to a 17.5Kloc-sized subsystem is not too helpful. > So, please let me know if you can still reproduce this after disabling > CONFIG_RDS, because I could not reproduce it any more. If you can, > please kindly share the stack trace without rds_* functions. Yes, this issue requires CONFIG_RDS and CONFIG_RDS_TCP to reproduce. But syzbot reproducer I'm working with doesn't create RDS sockets explicitly (with 'socket(AF_RDS, ..., ...)' or so). When two options above are enabled, the default network namespace has special kernel-space socket which is created in 'rds_tcp_listen_init()' and (if my understanding of the namespaces is correct) may be inherited with 'unshare(CLONE_NEWNET)'. So just enabling these two options makes the kernel vulnerable. So I'm still gently asking you to check whether there is a race condition I've talked about. Hopefully this shouldn't be too hard for a significant sockmap contributor. Dmitry