From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 030BE145FE0; Thu, 19 Feb 2026 09:40:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771494050; cv=none; b=hjHwrR6UGGz4al4TDKPEGElpk8OGV5jre+GODF20mqclFnE6QEpvRjmajW6CzBOa+yL5uXz1e3CVnDPFadBJBkrnuf1iMgCGBTFDsnSVCo3QmTKABFkYp+lHAcV8lQVLX7BhQkKxv4I8KZ4zu5qIzBafPvaTL6NHbTKnSU8V/BA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771494050; c=relaxed/simple; bh=T6w5GKsIgoEG6KRs18wTkCD0f1hYe1RlC28TLv/Hmyw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=srwJch608zEKHisu68qpjY28LCRi3XU7ZoZoQe/rDtx9yo+kazobWcRHWv2D3hAsvA6iXOnbmHu3qIbQIMfgDo2D61f9N8N8QN4BZI7eZjkscHy5wpsoMNJCFkaTWvwOQ78DzzYwT85X2tXVvlHR54G0u3ZmrUOtBVE0XBzf4kk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rCR3Ki3B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rCR3Ki3B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9324C4CEF7; Thu, 19 Feb 2026 09:40:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771494049; bh=T6w5GKsIgoEG6KRs18wTkCD0f1hYe1RlC28TLv/Hmyw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rCR3Ki3BrRY9t4a3tuHHH41DPhYGzOUbvqhFAo3pOFTP+VjVbaZl5nLQMrdOzbfkB hA7FQEt/LUzdIfyHx30abRFeWbyOyzeh+cMotlHwZdiSdSJfvUo0wPtoh4bfDEpGOC Zl2YlQ5n6TaO7Xo/1Y1x9h2Q8C87IYT4WV8oFCRiXyejY37yQYBrJer+ai1iwSQrnp hNnrKSsqLp++klS6muhxLQJbdCtY90sr6SJRBroGhU0oDA8KYtKunPKjLnbbnjY5Gy 8/ZthfYmqktoiuDlPz/UkPaegh7Ji3rvC99DyzhkFAlJbpG7hFFVUNQ9bYxU0Z9qF7 Uz1TgBS3K//9A== Date: Thu, 19 Feb 2026 09:40:45 +0000 From: Simon Horman To: Zeeshan Ahmad Cc: Sridhar Samudrala , "David S . Miller" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , netdev@vger.kernel.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v1] net: core: fix logical inconsistency in failover_slave_register() Message-ID: References: <20260219090216.12884-1-zeeshanahmad022019@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260219090216.12884-1-zeeshanahmad022019@gmail.com> On Thu, Feb 19, 2026 at 02:02:16PM +0500, Zeeshan Ahmad wrote: > Smatch warns that 'fops' is dereferenced at line 66 before being checked > for NULL at line 85. > > The current code inconsistently assumes 'fops' might be NULL at lines 62 > and 85, while dereferencing it without a check at line 66. > > Move the NULL check to the beginning of the function immediately after > 'fops' is initialized. This ensures safety for all subsequent > dereferences and allows the removal of redundant checks. > > Signed-off-by: Zeeshan Ahmad Hi Zeeshan, It's not entirely clear to me what the behaviour should be if fops is NULL, or indeed if fops can be NULL. But looking over both this function and other users of failover_get_bymac() it seems to me that the general patter is to skip steps that needs to dereference fops if fops is NULL. So I think it would be best to do the same here - that is modify the code around line 66 to make it conditional on fops not being NULL. Otherwise, if fops is NULL then steps that would have been taken are skipped. It is true that in those steps would never be reached and the kernel would have panic'ed due to a NULL dereference on line 66. So maybe your approach is better, perhaps with the addition of a WARN_ON_ONCE. But I feel that opens a larger surface that needs to be fixed in terms of understanding other users of failover_get_bymac() and if they (still) need to take fops being NULL into account. LMKWYT On process, if this is a fix - which I think means there is at least a theoretical case where it can go *boom* - then please target at net rather than net-next, and include a Fixes tag. Else, ## Form letter - net-next-closed We have already submitted our pull request with net-next material for v7.0, and therefore net-next is closed for new drivers, features, code refactoring and optimizations. We are currently accepting bug fixes only. Please repost when net-next reopens after Feb 23rd. RFC patches sent for review only are obviously welcome at any time. See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle -- pw-bot: defer