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 8BE9D331A5B for ; Tue, 7 Jul 2026 09:02:32 +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=1783414954; cv=none; b=m80jzkrEhwRZ8N6b1r8/T0+0hFCTcNmtwAgVY3e3uXSsJbjKFrdPgKuKPlZPysvZ+IUkNbkhzE3Y0Kk2NjQW+q2owWMWLJq1yKTX+2TkLzyQTc6V/7l3MNSaKsM0uUplvtlUR+Sr1voDn6b6pUdlL5e547lJ/8JzNnaRmP4B8YU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783414954; c=relaxed/simple; bh=QfiiqDPs4hpVeN7dGC1uwStx9g3fgFGCd8ZIjhLqd/8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bVslTfYV24LLRnPnZhYdmlkQwmRKl9GoShVtYlFT0BFZpqxIHXnjAKHkyHufc3IizLW6KezRRckfbmnPLFJA3R96OwWmQmPqA2M2Z6+VYoLNUeBgK46BfrfW7yaOWHoLaauwa0dTrteSsoTf1gz9tq8at9wJhYYSCukvtRz3XDw= 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=ZWycCoWE; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=SyGx83Cm; 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="ZWycCoWE"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="SyGx83Cm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783414951; 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=XvE/3KwFuCcanwiTTFebUv/R3s4QYWaS+H0gfSa4GvQ=; b=ZWycCoWEysUTnweJ7sJE8/AopGWR8lN35UF8oLIGEDlIe6rAl14u93VW1YfQAyAO+hoL70 QW+AAOgIxnUGzhT85FiXAH8JHEtOw1BUdFloGxFis/5GOdXc0C/M1960rLJJmNfAYoQBhz 7pF2YcRokz+tnHiIyXK+qMf3HlbgNkQ= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-7-5VayKi8TOEewLceUoa65TQ-1; Tue, 07 Jul 2026 05:02:30 -0400 X-MC-Unique: 5VayKi8TOEewLceUoa65TQ-1 X-Mimecast-MFC-AGG-ID: 5VayKi8TOEewLceUoa65TQ_1783414949 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-493a6fe9ebdso21223005e9.0 for ; Tue, 07 Jul 2026 02:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1783414949; x=1784019749; 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=XvE/3KwFuCcanwiTTFebUv/R3s4QYWaS+H0gfSa4GvQ=; b=SyGx83CmI9HBzRW6YXDbqDimU7W8OjXygSViDIeVadGLbZaj4mYCouLSd6Dcxtyxa2 v+A79leCClzYrRYEc91s1Ab99DMLkTdhrkNXZdXvDZYZ2pJnhJP17vR++0yTATuMPnon itu6KKFrCrGpZ5kb5Lq3U3Kq3Qqe7E5wxAdizxkLSa7P7+MWRleV7wsXxWoEu9/E3lmX SJ0Rs237ZsegeAOyNkwXw/SxVP12sUrRM0wJykUlxlnwZHldCsLN5Fo+L/vE4t5uXjqn twnFS8ligGUqynKmCpeuIQvkz5gzvYrQ1NsdQr36tZq3/FPX/3/C4CB5uHIOF3dpUrdX ThRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783414949; x=1784019749; 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=XvE/3KwFuCcanwiTTFebUv/R3s4QYWaS+H0gfSa4GvQ=; b=HU+60XP5/0uWPUV3KG6+4n10J/1ai4VhKvicMGpG68pvSMwrgaIb2JA4P9b2nRgx2u 2T8aPZHqwjAg6xM4fdnft+6pYi+Y+hizA8ZOZnjIaZjCeSyC6HtESUwU7qBGCwvhs7yX i+bJMQeZFdgFXKDLnTLLD3s6vsAWA0Iqz5+9d9S2p38ri5ZLkRoLCjzI2g5ArHMtTbpw nAtCIuCzjRdr8pSXIaikVCYk1OT8hzYryVhZEtqOjITc9JuRRJAEm+QZGyxeJjuoNrwv 8u2hwT0iQpL6a6MQ7rMYU2G7CESbrEV5u048c8bbsr0bW7A/2ypr+GDvzSziE/fznT8v Uurw== X-Forwarded-Encrypted: i=1; AHgh+RogSY9GWxQcWWhdK0gzCjT7D1pfkyVxyjuGNiRAl1GBy/P18q7grZgRYoBOhglK83MvLGfZSvagJG3SNH8=@vger.kernel.org X-Gm-Message-State: AOJu0YxCiEFgz+gwqItcZ4lfYFrdfIrP8LRcVn33oHWpddxZGXimhvxd aS4aV7dhNJMrtZNw+ZbYI4AIRczcB4oRvIH8Ks/OZVwb3GmZbnN8+8516qt66cSE+uKhUHB4UHx E6/DDfCBygQqQkmU0tyfY2Q7LZiC8MHhuMMoKSHq5PPUoDrmLXxXrifNHWyTyoKukPA== X-Gm-Gg: AfdE7cnFlJYjfAnPJMd5yGezfhyvB/HmeyR5ckLT0Z3trTwPCPIP6RRqqx62JIbT0zk NPhDEX3l0RYJVO1nktHh9ALLqwHda+wpBS4JsbMC/9/0Vh3QVPfuw2/k17nB6kLrZSrjdBBr4Y0 q8QPJXlPn+B1mqICjdRUCxYJpybWMaxJcX2SMPGJQijdEBc07O9AdJDYivxBp29lC/Wa580h3N7 QJgK1H/0QXddIRXYHizC7rxlIGoXBTjWFOSOm4mgdiAwnPBonganKJCeFY4MCuNBOFEE2aWPOlT UuzMJsauU2VfKeCyATgKNMXJTE2RX3B2fO+XW9sPrRrIjCm4CwL0h9xDPtDdlE/NbOuFekvElcM vvScYgXXDSbbQLFgFz6AoYhuTUS1vo8js+hT1Q1eoXyObuAMqgeGvtEL4ZIWHF1HxLmuXcJEGtO GUiKExZa1aG8+2 X-Received: by 2002:a7b:cc81:0:b0:493:cc01:807b with SMTP id 5b1f17b1804b1-493df0a0861mr33866575e9.38.1783414948960; Tue, 07 Jul 2026 02:02:28 -0700 (PDT) X-Received: by 2002:a7b:cc81:0:b0:493:cc01:807b with SMTP id 5b1f17b1804b1-493df0a0861mr33866145e9.38.1783414948477; Tue, 07 Jul 2026 02:02:28 -0700 (PDT) Received: from ?IPV6:2a0d:3344:5521:6b10:58fd:68f:7756:389d? ([2a0d:3344:5521:6b10:58fd:68f:7756:389d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493e0fc1348sm40703705e9.14.2026.07.07.02.02.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2026 02:02:27 -0700 (PDT) Message-ID: Date: Tue, 7 Jul 2026 11:02:26 +0200 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-next v2] ipv4: hold a consistent view of rt->dst.dev under RCU To: luoxuanqiang , Ido Schimmel Cc: "David S . Miller" , Eric Dumazet , Jakub Kicinski , David Ahern , Simon Horman , Kuniyuki Iwashima , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Xuanqiang Luo References: <20260701032434.17500-1-xuanqiang.luo@linux.dev> <20260705164649.GA295849@shredder> <5e2119f1-3c1c-43eb-984e-a8eeab2896e0@linux.dev> Content-Language: en-US From: Paolo Abeni In-Reply-To: <5e2119f1-3c1c-43eb-984e-a8eeab2896e0@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 7/7/26 3:26 AM, luoxuanqiang wrote: > 在 2026/7/6 00:46, Ido Schimmel 写道: >> On Wed, Jul 01, 2026 at 11:24:34AM +0800,xuanqiang.luo@linux.dev wrote: >>> From: Xuanqiang Luo >>> >>> rt_flush_dev() walks the per-CPU uncached route list and rewrites >>> rt->dst.dev in-place to blackhole_netdev under spin_lock_bh(). >>> This lock does not exclude RCU readers, which may load rt->dst.dev >>> multiple times within a single rcu_read_lock() region. >>> >>> ip_rt_send_redirect() is a typical example: it reads rt->dst.dev >>> three times to obtain in_dev, the L3 master ifindex, and net. >>> A concurrent device unregistration can repoint rt->dst.dev to >>> blackhole_netdev between those reads, making the reader combine >>> state from two different net_devices — for instance, an in_dev >>> from the real device but a netns and peer lookup from the blackhole >>> device. ip_rt_get_source() has the same problem: it reads >>> rt->dst.dev four times to obtain the output ifindex, the netns, >>> and the source address, so a concurrent flush can cause the source >>> selection to mix state from different devices. >> Why only change ip_rt_send_redirect() and ip_rt_get_source() when the >> patch is titled "ipv4: hold a consistent view of rt->dst.dev under RCU"? >> What is the criterion? > > Thanks! You are right, the subject is too broad. I will make them > more accurate in the next version. > >>> Take a single dst_dev_rcu() snapshot of rt->dst.dev at the start >>> of each affected RCU reader and use that snapshot throughout, so >>> concurrent flushes cannot cause mid-function inconsistency. >>> Publish the in-place write in rt_flush_dev() with rcu_assign_pointer() >>> to match the readers. >> The rt_flush_dev() change should be a separate change. Note that >> dst_dev_put() was already converted to use rcu_assign_pointer(). >> > I will split the rt_flush_dev() change into a separate patch. > >>> Fixes: caacf05e5ad1a ("ipv4: Properly purge netdev references on uncached routes.") >> Please remove the Fixes tag given you are targeting net-next. > > Just to clarify: is the suggestion to drop the Fixes tag here solely > because this patch is targeted at net-next? Or are there any other > reasons? Generally speaking, yes: net-next patches should not include a fixes tag unless the blamed commit is on net-next only. More specifically, this patch is really a behavior improvement and not a vertical fix, as such we want to avoid it propagating on stable trees, as the fixes tag sometimes does. /P