From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (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 5515F31A81C for ; Mon, 18 May 2026 10:02:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779098556; cv=none; b=cunxlKzN+JM8jA93/CgMR3irBtT4yOGRpprKsDDjxH88zqWDshRHftY6p/I0lz4NLR2j6aIwD9ASCnIABBDByO6K2VWGHQAsoiF48IFw0MnxGJ/qX741h/0TwLJdTGg/h3DKoeaMUV8KE5Iex+NPZSs621bZARvhsD6gqqh6/lk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779098556; c=relaxed/simple; bh=DjPX0iLJm5HdjauSG8OjNGuHimq1+bp8IrsTjoCD3LE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OX21t4qzJ664T8A9P6Jc/7deLexDwweFRYH14vnUho6lRy5Ogf1DpTI8kORKbqyC39nYykAe9aMnBzH8AS763cx1ntR0s8n1b8Z5b69gIuPY+P4LVAF0/kAKTNJHCrIZA2n6NUZH/fWT8hs9mA4tUr30vZrImLRFB12zLQIxkOo= 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=TD1fL2/h; arc=none smtp.client-ip=209.85.167.44 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="TD1fL2/h" Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-5a746f9c092so3465276e87.1 for ; Mon, 18 May 2026 03:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779098554; x=1779703354; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=BN+YMmv9QnScORg4tpVq+mKnF6MQYSJi7uGVyTrlWV4=; b=TD1fL2/h/JDmVytPBKlmEbIzZ/Dpk62bFhV6+2iRmfzfshEjTd/haYYCVdG3UsywdR wrbLuuPsv2v11QawvNstFcr7lXxOXbBaRMGivqCtBbxYbqFxty7PUpwpbvY/x7thvPoM PHHgAxHx0RyioVEcNS9lX9kKZmDguqGHgFL//QSPR8Xi1SK7B5tqO7ibU/OtAXF3BJyw SVrEC25Xo3J2mKyVJYKx1TVY6gqsQnqXHE97HDLbNT2op5JveLnD6yUASETffD2x1nTY 10loPMnHIRPWrvKQ473UjiLCbHMuKdoCeoD5Ih1C5mi6ns/XUR6xRsWHeV/qN2u4NYp5 coTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779098554; x=1779703354; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BN+YMmv9QnScORg4tpVq+mKnF6MQYSJi7uGVyTrlWV4=; b=F9JyUMlO6bXs0ZuxmW+PT2O08AIXcSbfsd9J88r3ZMROQ4W+7UDMd8mRWQWwg5Na63 yR7lxLxcCHBwukZlQ8M/NFj6shJo4r5N2nkMP9tJQW3JwQQXRDl+DTE4gBxfoQB8QApd re06Llut6VDPElDWtjeWjRKVn4dnIa7O5H0gIsfRunTDv9UEXaH29ObHf5A+xL6mc3mT Vm3UB1SzBW/jiC+OBT2HjRboICkpvKy5wrqHZgwJUXnXQYDhzrb4NIBNMxLjCI9urr7K 3H/Y5XkhQ88TI/a8kgFJrJE8bFOZac52lp2rlPn6AoJk0xFoX2W7x85QTNV6kFReXUc8 MkCA== X-Forwarded-Encrypted: i=1; AFNElJ++DPZdMxWijZsIzyX2jVpZmIEVBhXm+kxV+C/fGVtaf7kknJ87E3yiW8KpsNl8iCft96Gv6dZ7JwI2eh8=@vger.kernel.org X-Gm-Message-State: AOJu0YzZnQ4qN7VSHRMXACgAiMykNb4Hk/CN1Ult9+IMoFnHkKEavSO3 Z/rVhygdItQE3H965LfhgeKkbtYP5G1XAopIsPODdnaycF3Qzul2M9qLeYkKAw== X-Gm-Gg: Acq92OGNdMAiNK7Hprx+f2Nn/YCSBUcZZ4Q0qvo3/DhqBcW4/SlSIgotuO7lTDoZ2jq GCgyFEg/pTep0GhYmzYszfHH2nqtIjxzIqnawdszYLBTqdrzpHh9aBEc80lPiL4cbZVLIbpChJ7 D1E1ujOpGkdsobvLTnKwd/ePbwVkEnLs+WIDGNVq4qEH6wd4CuCkTp7EM73UEN2d4+BGGkJ/c/h xZWqqhF20o3r3fZOp5lbRTVR47WNmBb7pPCmhTM8RntCaQ2sh8PYzrusM/uKUcGLUdEJR3bnrKd CBr6+KjV173aUcSVKFhYXPS0WJv8Pa6rbBgaMlOGHH4McAHZf4ZVHOM+kBmCtV2UhaD7Ms7NO3H GXu2nbmOrnhH1RyeB6o4JVOew3wo47fcrdzrpWafodHWTtuEfp9kPSF680b7vSROY83Cu7+hVcs DWnFLzbYd3k8DesmzLbQopef+0 X-Received: by 2002:a05:6512:3f13:b0:5a4:a85:ba3b with SMTP id 2adb3069b0e04-5aa0e09df5emr3864589e87.19.1779098552997; Mon, 18 May 2026 03:02:32 -0700 (PDT) Received: from grain.localdomain ([5.18.255.97]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a91e0ce644sm3193851e87.80.2026.05.18.03.02.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 03:02:32 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 373085A005B; Mon, 18 May 2026 13:02:32 +0300 (MSK) Date: Mon, 18 May 2026 13:02:32 +0300 From: Cyrill Gorcunov To: Simon Horman , linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com Subject: Re: [PATCH v2] ice: Fix wrong dsn read in ice_adapter_put Message-ID: References: <20260517125307.287246-1-horms@kernel.org> 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=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.3.1 (2026-03-20) On Mon, May 18, 2026 at 01:21:21AM +0300, Cyrill Gorcunov wrote: > On Sun, May 17, 2026 at 01:53:07PM +0100, Simon Horman wrote: > ... > > > void ice_adapter_put(struct pci_dev *pdev) > > > { > > > + const struct ice_pf *pf = pci_get_drvdata(pdev); > > > + unsigned long index = pf->adapter->index; > > > > Is it possible for pf->adapter to be NULL here if the device was probed in > > firmware recovery mode? > > > > If the device enters firmware recovery mode during ice_probe(), the driver > > calls ice_probe_recovery_mode() and skips the ice_adapter_get() allocation. > > If the device is subsequently unplugged, the memory-mapped read for the > > firmware state register might return 0. > > > > This would cause ice_is_recovery_mode() to evaluate to false in ice_remove(), > > allowing the normal teardown sequence to proceed and call ice_adapter_put(). > > Would the unconditional dereference of pf->adapter->index then cause a NULL > > pointer dereference? > > If we're in recovery mode the ice_remove will not reach ice_adapter_put, > instead it will stop service work and just deinit devlink interface, no? Thinking more I think I got what sashiko meant here: the pullout of the adapter when it been in recovery mode already, and reading register state is obviously incorrect here too, instead we have to save the state upon probing in some flag and use it later. I'll update the patch.