From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szelinsky.de (szelinsky.de [85.214.127.56]) (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 2997432D7FA; Sun, 28 Jun 2026 15:31:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.214.127.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782660713; cv=none; b=fWWH+B/SSwjvUPYKe6QN/smBYKAtRCeFAmq077X0Pz97u4kfDyAt2/U99ZWdiSAudrXR+EyosYc4gw7Maiir8K8qQ3IzzRUX7VeaL+H/vh9AOjPmX5f8Jrocq4QEbPzaT951N2szkQU4kqlImP3w/KG+OkJf4jHhFwFZ0QOj+Zc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782660713; c=relaxed/simple; bh=hrho+VCEM+PMn9utCj/hdI2qNbx+XRvATBOImWER0fw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l0l3OvM366XmLdpZbcV/GES8Ql7aOx0lkJtJ2dNikdHbvjbMJVxu65qeXW4mBEsQxGoL1vH0WYvxyyb0dKvPfR7I3ZrGPeHc/xWyy9TUftxcnwmx9BLVXF8gH18PLvsZg3d+/tZWSNcQNGoTBmsiolL84lTDQv7kKrrhsfm8xzE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=szelinsky.de; spf=pass smtp.mailfrom=szelinsky.de; dkim=temperror (0-bit key) header.d=szelinsky.de header.i=@szelinsky.de header.b=OE9PIx8o; arc=none smtp.client-ip=85.214.127.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=szelinsky.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=szelinsky.de Authentication-Results: smtp.subspace.kernel.org; dkim=temperror (0-bit key) header.d=szelinsky.de header.i=@szelinsky.de header.b="OE9PIx8o" Received: from localhost (localhost [127.0.0.1]) by szelinsky.de (Postfix) with ESMTP id C34B9E83957; Sun, 28 Jun 2026 17:31:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szelinsky.de; s=mail; t=1782660703; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ifs9Rqu4NSwYS2nYn0dX6lUO6UMTsxCOrL6aDSb7bAw=; b=OE9PIx8oyIlU71IPVUpEHjYWYzihV/oEvOTqIFw+eFEuSrDmom4O/C0seDKXJt4lv7umJi yRfQnubKEqC2CU8pcz0y2S+ObQJXw8dXjAEgb/AN+34iqRNiOiKDGKYamS5VG9kFKuJtnO rNIun7oMSJ2nTL1tRuZDyg9rsV616U1gO/8fk9u2bLm9Qvg0QrEUpZIXPb4J4R5OtAfGPu GiLOyFemQowS1UTNW0Y/tcrL2Xe4g+kNaIKdspGFsyKy4zoijGoIOvPNhFM6oR7IuNuSiV 6XAuAl9jwQp6YZ7rSm3jwuZrDpBgD1UfXouXaIhzsMkbze9Z1CsBx+c8+iP+VQ== X-Virus-Scanned: Debian amavis at szelinsky.de Received: from szelinsky.de ([127.0.0.1]) by localhost (szelinsky.de [127.0.0.1]) (amavis, port 10025) with ESMTP id 2VweZJsA0lRj; Sun, 28 Jun 2026 17:31:43 +0200 (CEST) Received: from p14sgen5.lan (p5784dea5.dip0.t-ipconnect.de [87.132.222.165]) by szelinsky.de (Postfix) with ESMTPSA; Sun, 28 Jun 2026 17:31:43 +0200 (CEST) From: Carlo Szelinsky To: Simon Horman Cc: Oleksij Rempel , Kory Maincent , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Carlo Szelinsky Subject: Re: [PATCH net 2/2] net: pse-pd: guard against freed PI data on regulator disable Date: Sun, 28 Jun 2026 17:31:29 +0200 Message-ID: <20260628153129.2995903-1-github@szelinsky.de> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260615180048.828053-1-github@szelinsky.de> References: <20260615180048.828053-1-github@szelinsky.de> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Simon, Gentle ping on this one... I think I'm just waiting on your read before I send v2, and I'd like to get it unblocked :-) v2 would take pcdev->lock around the kfree() + pcdev->pi = NULL in pse_release_pis() so the NULL is authoritative, and add the same !pcdev->pi guard to pse_pi_is_enabled() and pse_pi_enable(). Two things I'd value your view on before I send the next version: - Is the contained fix (lock around the free) ok, or would you prefer the regulator unregister reordered ahead of pse_release_pis()? - I couldn't find a concrete consumer hitting a regulator op on another CPU during unbind, so I'd describe it as a narrow window rather than a proven race. Does that sound right to you? Happy to just send v2 with the lock fix if that works for you. Thanks, Carlo