From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 CBB7E3C5DC2 for ; Thu, 19 Mar 2026 12:44:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773924248; cv=none; b=RmRaO9JISOe8N4FaHQDGyJvnEIqkP1J9v+0HDmtdKCv6Zwfzb4cbywmrgpkJUjh1v26zfVnr1hRL1WzcUoFVxZimnEYUL3rIu6w/RBEQvj2zxMn/fc9XbjMefu+oLTWYQLlzTVsrMTEyz20Ivt4DvU4Tj0JaM1moHtf6dtpCKaw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773924248; c=relaxed/simple; bh=Hqvg7xhMst5DndB/D8ak/6M3aygYH5XzQLjkv0TtWuM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=m9cZ4uSJDfFLr3SXZTHQvwXqdFOUpjI5hzvYyChCfvCEweOzmF3TsTCv28FMDi2hCNVGHKyihANdq6AjjXbavZ0/QNsCn49h0Aqb+FipcllT+1hkmBmMRyzyMyhXaxtMFgHmSusZ15AQv8rywtqI23a4SlRO5RyqW5AOvpV8mw8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BiHqyzEM; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=jQDjJHc+; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BiHqyzEM"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="jQDjJHc+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773924245; h=from:from: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; bh=nY70eJF99QytEX7DipnKVmL+suwwJ5IWXmC9xLflxuQ=; b=BiHqyzEMj3wnRHwycrUlwR51w8Xxu4miUySfbee6Jy0xBxCJWe+QK6wFxw9DuaO8qOxwcN G9nKNXwlgD7QHmVr5b5rhAUQLfFdz7i8QgK+faUw9rnj8GPptYpjGYAW3+gHmCrL1UKY3U MaDPeprpndt5+YQjyFRWarV7rUO+kW8= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-513-2kjhRqQiPxWfsoP8W4spSg-1; Thu, 19 Mar 2026 08:44:04 -0400 X-MC-Unique: 2kjhRqQiPxWfsoP8W4spSg-1 X-Mimecast-MFC-AGG-ID: 2kjhRqQiPxWfsoP8W4spSg_1773924243 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4852ccff333so8016965e9.2 for ; Thu, 19 Mar 2026 05:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1773924243; x=1774529043; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nY70eJF99QytEX7DipnKVmL+suwwJ5IWXmC9xLflxuQ=; b=jQDjJHc+55/UIshziBfu7CGJyvhuW7F9H28OHJJkmH4fYoEAg/WyW3kn3YI6i0zqJI k7ue/a1Bx9NSONyxi2nKJnpEBjjFqZ+XGA3YQx2gECqyfL/t/vRCfeU4oCXWpguePAPH AQ4Ec03MrBng40P0tc8H/ehVXWbobnqNwkjLZcqWDZfr/KoEYfGiPScztIOuvHMNJple JXi4jDtvpB68A9tXXfkvS5iG5I0a7OHOXUcKkg9L5g/ettQDDzHv3IJnYtkioAWVdNbY 8w78Gjvj/rzliR9cTOx2anhhZ7VcU2FdPs8kosVb7BpDYFYOAQurS6GwrcYb+yjj4aww Nb2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773924243; x=1774529043; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nY70eJF99QytEX7DipnKVmL+suwwJ5IWXmC9xLflxuQ=; b=mABM/W0Nt6pkoH7+MNzM1C6Sjc+UgCEmNFLyDQfw8etF2JOVH8EYZtzrhiatIkCFDk qvYsn3swvZEJt27KzxIp6zOIxCQxe4pNV1dL0+/Bk4O2CN1xHWirGLKK2YYUiKJfGPB6 N6LMjnwb+mLzL/QfrAggpRnIk7kZ60D9jJ1TgLy3amdImprFxREpidQmHUa1qVrXhDBx Y6S8Tf2NEBpVQI+Tpol10i+S86JDPfB2I39UMBoNbqSeA8wZzIYJNADUuZUbSdnvmR/G tCx972YXjIafwyURcppXJM4PiEeGW9MZprSDt9+GuhbkstFyDuHwT+cctzCSbVr/V5Al RGhg== X-Forwarded-Encrypted: i=1; AJvYcCU11iK0qFXL2c07mfsCaD4ke3W3H1N6FJoFns2vKS8ciedSO/y1cuejYiRJVSUjaMrJRNuGAVml9LK1+o8=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1MuR2i51+/JtMBsYSEGO5ahiILK3M9g7YLIdUbYFmeL1Vc7nU RxYxekuBnERUorMpZa72PNuemjdGPS2gjEXXqIlo176gzshIr1nHGHg0JwAKRgA89I8qOAIASzU TBav6u72NIZsWy0PfltGQN1eJ0BSH3cSuQiE0kQ5erSCrEPhpo2YWMTg6xVIlOs1egw== X-Gm-Gg: ATEYQzznuK73j3CUzuisd3TP/qM73zIPI+Av14d0rdafvJ0rKhjz6/C5Rcifbl2kAcA bgYUGAtq65K0YKwe4DZHPvucySTeiQxdGMBqPXZf/n4vkZ6Mm6U5zr5cPEc1Ww/uUgzOfK7TA4t WP4YgFPKHT7UvmefU4A9+qqPp66JB44uNM6kTl42GZUs9E/tq0lzP7XkEW0+dAzEPPnky9qTuru 0oKp2zXHlrrsTgEL+NKHvaMeS5mP9Lnx2PwlPl4JjXR+ePZm+/9h938V6TSW51tIf8qYU/IMRuh 9ZLFcgrG005XPGIM0GPJ8u257kdzbEo56jNkMM35jOdPoboHC8zO4m7VH8YAyzszAXKMel4TROj w1bSmK+h9C/CU0GUCKi6prlfYlxiMdZOLHMNyjBZAVgzXeLLgWdx2qsp0 X-Received: by 2002:a05:600c:1e8c:b0:485:3d43:7c9a with SMTP id 5b1f17b1804b1-486f456fe06mr122764135e9.25.1773924243042; Thu, 19 Mar 2026 05:44:03 -0700 (PDT) X-Received: by 2002:a05:600c:1e8c:b0:485:3d43:7c9a with SMTP id 5b1f17b1804b1-486f456fe06mr122763715e9.25.1773924242570; Thu, 19 Mar 2026 05:44:02 -0700 (PDT) Received: from [192.168.88.32] ([216.128.11.196]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b518495aasm15971859f8f.3.2026.03.19.05.44.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Mar 2026 05:44:01 -0700 (PDT) Message-ID: <258f99ac-bd34-4d14-8271-1266b9aba6f8@redhat.com> Date: Thu, 19 Mar 2026 13:44:00 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net v1] net/ipv6: mcast: fix circular locking dependency in __ipv6_dev_mc_inc() To: Jakub Kicinski , Jiayuan Chen , Josef Bacik Cc: netdev@vger.kernel.org, Jiayuan Chen , syzbot+afbcf622635e98bf40d2@syzkaller.appspotmail.com, "David S. Miller" , David Ahern , Eric Dumazet , Simon Horman , Taehee Yoo , linux-kernel@vger.kernel.org, nbd@other.debian.org References: <20260317111208.62667-1-jiayuan.chen@linux.dev> <20260318181536.47ed9fd1@kernel.org> <20260318202649.004d33fd@kernel.org> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20260318202649.004d33fd@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Adding Josef. On 3/19/26 4:26 AM, Jakub Kicinski wrote: > On Thu, 19 Mar 2026 11:04:24 +0800 Jiayuan Chen wrote: >>>> Split mca_alloc() into mca_alloc() + mca_init(): mca_alloc() does the >>>> GFP_KERNEL allocation before mc_lock, mca_init() initializes under >>>> mc_lock. If the address already exists, the pre-allocated memory is >>>> simply freed. Also move inet6_ifmcaddr_notify() outside mc_lock since >>>> it also does GFP_KERNEL allocation. >>> Moving the allocation seems fine, but also having to move the >>> notification, potentially letting the notification go out of order >>> makes me wonder if we aren't better off adding helpers for taking this >>> lock which also call memalloc_noio_{save,restore} ? >> Yeah, using memalloc_noio helpers is simpler. I checked and there >> are about 18 places taking mc_lock, so having a common mc_lock()/mc_unlock() >> wrapper that does the noio save/restore covers them all (if necessary). >> >> The only thing that feels a bit odd is using memalloc_noio in the networking >> subsystem. It makes sense in block/fs to protect itself from recursion. > > Totally agree that it feels a bit odd that we have to worry about IO, > but unless we can figure out a way to prevent nbd sockets from getting > here all our solutions are dealing with noio in networking code :( > IMHO it's better to acknowledge this with the explicit memalloc_noio > so future developers don't break things again with a mis-placed > allocation. I think a problem here is that the nbd socket is still exposed to user-space, while in use by the block device. I fear that the more syzkaller will learn new tricks, the more we will have to had strange noio all around the networking code. I *think* we could prevent this kind of races with something alike the following: - nbd sets a DOIO sk flag on the sockets it uses. - the socket layer prevents socketopts()/ioctl() entirely on DOIO sk I'm not sure if that could break nbd users, but allowing the user-space to mess with the socket used for backing a block device looks very dangerous. /P