From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B123536164B for ; Wed, 6 May 2026 20:43:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778100212; cv=none; b=TCAgIUxNSs9vUtMqA8O4l7XkSuicRThckqZk0xOTIBhZSgcQnaxmPbvxoWdXbn3FNDb5PVgnAVN2OabTB9JWRvEd3MPuCPG2M4cWckx4sGCGLh2zFRIrTD7B04nlX0qwWMRjeYHMkmkQpKYzRhcOPjXu8BNxRd8D/ILpVmeKV/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778100212; c=relaxed/simple; bh=dnfjyN0iESFBQhGX4yyWG5e0UnilO+QqljvnttYEcEU=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=EICXsRAidf8rH71SxjBiFAkjw1wY2DolQnLiHOiGaWktjMl40hsvugJeqY/iSJh2A8ggoFToZcZUUxaLnf+WBY5oL/3xuGI+XIoKm1b1VgTGR+vlgDF9okTmEhOl+943JmZMEqqmitIEwaEX8wZz2JFfnaxLNogefh1VlUpPIjk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YDec6DiK; arc=none smtp.client-ip=209.85.128.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YDec6DiK" Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-7bd5c582c6cso834157b3.1 for ; Wed, 06 May 2026 13:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778100210; x=1778705010; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=QeIGDwIloR6wW2XDZbQPZr37CB08xADpVWPsXdCwNpI=; b=YDec6DiKP26RzvwJgS0Nt0EGmCDf71MO3wuimoEr9obil3Z8+U0jnrNS18p4XbvQQ6 B+J0MqAOFGRNupfpxVCBZExLJDOl/2u6tkqFliNLoYF6M32Ce9ubpDQW2yPqxIPmWocu KfIDLz2YoTE90q+BYxLxhvXXDPHS3pnHRzJ3thVbNc/yrhx8n9lZT0mcNY/bThH25swl GX0J7cfngdEXBh0Y2LKJSqv1EB/m7nfZx9ukQ32ieqLOkVjv4F8OXVUlk9p3Xj55jTmy sW+qLE2oXRjTjB8tUdr01odkKPB8cTGFrzF7rP1o0jZL/pWeTgKA3L16CAQ5SimNY7Gb yKuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778100210; x=1778705010; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QeIGDwIloR6wW2XDZbQPZr37CB08xADpVWPsXdCwNpI=; b=ZLE6qZfu2dEs8nnowfaP/8LmjX9cJ+8ZC1oOXIq2LltWwQNsbFhVscdP8/DKEutOSd Ih405KHpO30baYeep7Gv5YN5CJHZW7wS/WOe+ViQxjBGyLV7CZJVL2epQleqed08cVDj e07EwOFA6/k2TBLCA72PhBfGx7oFGGGdiRvjWLWrce8PD9TAxuP91P99EVf2ygD8EOjP ciOviAnZg1VRU5H0zWNFT4Y8BewCDl0DkFlcje7+glpttbsgya2DOzfuG9XEox0o0wQT 4HEy0D+QnMqiHeaQeKwuoT7JJ9G7A8bEFugs5n9IhOwapkjIpN26jb1VzzsY6G5cz0v8 QXKg== X-Forwarded-Encrypted: i=1; AFNElJ+s/WMxAlY0JJjHcPcGXtnkjdHdVcMMmYMztFN+tYktJ+Y5v41gFBvQ0SAcJTRiUnIAvFF0o4rHl4Fve7k=@vger.kernel.org X-Gm-Message-State: AOJu0YzJxD8ufzNKIGefP9oeMNbtmjF9SmVcWIVQoym/sAnuCPqXiXmC Rc2wnMjVyQNI/CYVlm7rprG5lbSO0cD16c6CDDsz8TtXsGODHQ1sTDmg X-Gm-Gg: AeBDiev10nBOmCcXomlgExHeFUThzfJ3/bkFZzPKQM2xkK/el22MS+djyEF017TL1T6 zm5FAnEc3aOuwp0RTcMZq/VqFluYojT4ud0d0Veix7ZvZqpOHR8zT4yWr7fwCSqCxm/lGIcAVoP CwvEj17Yq3lhxZHESXUJpUvA5jrhnmYD4Ps6kom5u+GEFJC9ZJTDyEgLeQVhG5NyAaJgRh8DunY hEgBwia47P+ejkpc6CQ6iVgp5g7QDZVABMYIUlddTjaGnCfRffwcMig14z5wFB8mJcAGvGBnKRt 1XNNR3cMiVX1LmTVL2wGFfF35SeAzpZzOdzp7jJQuVqakztfN9WP0s9RY65D4ZvKLz887mx9UoT IrxgE4o6uedE7sNdEcxdmOKDkYAuQp1RH/LxG9GTZ4fKXhrAQmzzt/cU3BVz8+3jq/jZS6Gu9Gl jvXEAer6uf3UlOihzBke28jOHySJuvPnSOWyoK2/O5Vp+gN1Kxme4JunKk/xio9v95M54fEDwjX dgcIEfuSbYFN20= X-Received: by 2002:a05:690c:c371:b0:7bd:93b0:bd25 with SMTP id 00721157ae682-7bdf5d6bde6mr58985457b3.4.1778100209510; Wed, 06 May 2026 13:43:29 -0700 (PDT) Received: from gmail.com (172.235.85.34.bc.googleusercontent.com. [34.85.235.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7bd6685d0cbsm82291157b3.35.2026.05.06.13.43.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 13:43:28 -0700 (PDT) Date: Wed, 06 May 2026 16:43:28 -0400 From: Willem de Bruijn To: Daniel Zahka , Willem de Bruijn , Jakub Kicinski , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Willem de Bruijn Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: In-Reply-To: <9e691c63-ef7d-4e35-8cc4-77f83a16c970@gmail.com> References: <20260505-psd-rcu-v1-0-a8f69ec1ab96@gmail.com> <20260505-psd-rcu-v1-3-a8f69ec1ab96@gmail.com> <9e691c63-ef7d-4e35-8cc4-77f83a16c970@gmail.com> Subject: Re: [PATCH net 3/3] netdevsim: psp: rcu protect psp_dev reference Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Daniel Zahka wrote: > > On 5/6/26 3:34 PM, Willem de Bruijn wrote: > > Daniel Zahka wrote > >> static ssize_t > >> @@ -228,16 +237,23 @@ nsim_psp_rereg_write(struct file *file, const char __user *data, size_t count, > >> loff_t *ppos) > >> { > >> struct netdevsim *ns = file->private_data; > >> - int err; > >> + struct psp_dev *psd; > >> + ssize_t ret; > >> > >> mutex_lock(&ns->psp.rereg_lock); > >> - __nsim_psp_uninit(ns); > >> + __nsim_psp_uninit(ns, false); > >> + > >> + psd = psp_dev_create(ns->netdev, &nsim_psp_ops, &nsim_psp_caps, ns); > >> + if (IS_ERR(psd)) { > >> + ret = PTR_ERR(psd); > >> + goto out; > >> + } > > Do you want to create the new device first and only delete the old > > state if that succeeds? To avoid a netdevsim in state without dev. > > > >> > >> - ns->psp.dev = psp_dev_create(ns->netdev, &nsim_psp_ops, > >> - &nsim_psp_caps, ns); > >> - err = PTR_ERR_OR_ZERO(ns->psp.dev); > >> + rcu_assign_pointer(ns->psp.dev, psd); > >> + ret = count; > >> +out: > >> mutex_unlock(&ns->psp.rereg_lock); > >> - return err ?: count; > >> + return ret; > >> } > >> > > Unfortunately, the way we have psp_dev_unregister() written, it would > clear out the main_netdev->psp_dev field from the second > psp_dev_create() call. I don't believe there is use case to do this in a > real driver, so I'm not sure we need to change how the create/unregister > paths work. Thanks for that context. Reviewed-by: Willem de Bruijn