From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 8E93138886A for ; Tue, 10 Feb 2026 17:24:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770744285; cv=none; b=L7854RxEHWM0RdN57h/qKT1wh0f86ta91jhgaEQ6ELHITlr7SglyqqdAEt95ma6x3zvHith1QgU+njSQRCIUroZfvQhJWeHBJnsnXZKaIOmFGtUdCH/3qQ81im080Y5qS2H0Gcw4OTTIl0Ag+tOOf+JYpFJTr1I+jkc1hQF0YX8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770744285; c=relaxed/simple; bh=Wd3YSz4r0LCpgTa6gQcvb7t6hbNezRGr0SM90Ujny/A=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=A1onneqZR8h4n13Bcj3aMURwLmakaioV8GAjxJ65jKMQGsgna86+lE3aDaiTsbE316xvT8rNMuCdS7Lo7lc0qrBopivLEinNlD0iOpze2dAuT9suVpcDPvO/QFScvvO1zptA8fDXhGCJFExXkG3ngOq/2+tUcJYVrDitv9ygW1w= 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=Ss73s5h+; arc=none smtp.client-ip=209.85.214.173 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="Ss73s5h+" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2aaf9191da3so7437415ad.2 for ; Tue, 10 Feb 2026 09:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770744284; x=1771349084; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=exOj3yYPEa1TYDiWarKxK5k3MV6+EjzaaIJ4oOWyLaY=; b=Ss73s5h+GElY1s0DhutSz6CbTo2WTDHzihInucAby4sIk9S78raW4udZBEDt83cKRs c2PFGO8/9tx57oj8MUdQTOkFbGxRXSB3ceQIfSND1kjeENAn1m1yEbmemxmsqgZ9ymfz iFDe7L5nmo2x2IcmrReuFIU7a8ehiCvJFibPUYyIJkhupoyCtCvIezLvq/bRmcd4axdc 8amGYHbDqOCocQNTEiiiaJpY64UNUCDfWjOfl1WqK9UZ/PkbxANuDaIkoC9k58ZfN+G6 e+ar4O4g6GDuaJNiB4sDw1M78GTEHY966jt3L4X6g4LdDCvl/a11N+HEaAD2UhmzUpSX OwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770744284; x=1771349084; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=exOj3yYPEa1TYDiWarKxK5k3MV6+EjzaaIJ4oOWyLaY=; b=fhXgx+4FinG63ZFmI3FOs8WMRqafy5jf4g8MK7VIw1VXumK20nOkuBwPN6FdlAzq/F qfbaOGLviaXnomILfMW597XIHSOOJvyUYRLne5n9+Utl1ewADZSTXdy+/5yZr1UF0ujF gIsicIgbk+mpH+7gjT84CWaGiJVbBUM6Gc4oOqFphGYawc7yc5mX20oCKIRUTYN3BNNP cAcItiJi4T2lMBd+Wj53vQ0L4VqPvZj7LL2Lom2xTEECSuB327vY6iwbolT9LYkc0mgT js4emx9Rf9DAqMOeAhaHyEj+oi3PA3AnQcZksdrgWHLQhEKGnP5qj1+Acjrj7WTnyjLJ 01WQ== X-Forwarded-Encrypted: i=1; AJvYcCXrCXufCU8KAR6/JpVMLaYIxHK04Fg99hHBXlaoWMPjQG4Cos4tZozFETjY2mPVqx73bP0UX7pmHh1zqyk=@vger.kernel.org X-Gm-Message-State: AOJu0Yyotzbj698Voin9LV/gWReDB+3JzrKyOy37vSCxNTpuD749FbKx 3IV9EjWPjpIeH9hB6+2eUEnFI/nEttUoUV75Se8ECQmsCFlYJRPxrdwF X-Gm-Gg: AZuq6aLSnhSk1XUdA0JA1v5CvbTfkRz3RqOXjkYCtCSxA6bIJyCUfZ99aTH5Oh40XfL xQIJoyEq6japfzAnQmMkj20gqx488Y0SbwMi+u21s1kxYHUYI4S99/+kQmXsmc2/OEE+5IQJC/i OiqxwnT1lkom+a6VP+yDJAm5XqNnotXM4esKUV19LLX+e5DR2OVbssdPfrf3k+eb+xXYVoEIuvs JyfgCYbZrYiLG5bTqrkmEKMjXOwZnoX8hiUhmApOaW75SepN04o71luH3WkWoQahMvp+VP+dqWr DQTdgYlV38oCEvuY6olLuR9cmWsN5MlYfEf3yMdhstBIq0crUmpv5q4K+bKmXh4yPJ61nE8K8Fv R9VYEKw/geL1LNcbs8lMMOy3461aVAr+WuYRQOrKD4zda17WnVbfC8Y+JHCYrl2TD8FeUasCQct 9atN4/CrHMOOtZT9+WxRtnuslSu4Y7qyXD96kSKVj+mMnt2O/Ll/mIvmMvKKn8xOShpy+cAvK1K J47848LjZx5Xg/rfJly0UE= X-Received: by 2002:a17:903:2f8b:b0:29d:a26c:34b6 with SMTP id d9443c01a7336-2a95194ab72mr139665545ad.50.1770744283691; Tue, 10 Feb 2026 09:24:43 -0800 (PST) Received: from [192.168.0.128] ([98.97.33.227]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-2a9636184a3sm110427275ad.20.2026.02.10.09.24.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 09:24:42 -0800 (PST) Message-ID: <2c0395d5323770a32d53c6b874a735b888e4d4f1.camel@gmail.com> Subject: Re: [PATCH] fbnic: close fw_log race between users and teardown From: Alexander H Duyck To: Chengfeng Ye , kernel-team@meta.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, jacob.e.keller@intel.com, lee@trager.us, horms@kernel.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 10 Feb 2026 09:24:41 -0800 In-Reply-To: <20260209163854.521415-1-dg573847474@gmail.com> References: <20260209163854.521415-1-dg573847474@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-02-09 at 16:38 +0000, Chengfeng Ye wrote: > Fixes a theoretical race on fw_log between the teardown path and fw_log > show/write functions. >=20 > The fw_log null check was performed outside the lock in both > fbnic_dbg_fw_log_show() and fbnic_fw_log_write() (called from debugfs > paths or mailbox threaded IRQ handler). Concurrent teardown in > fbnic_fw_log_free() could clear and free the log buffer after the check > because there is no proper synchronization, leading to list traversal or > buffer access on freed memory. >=20 > fbnic_fw_log_write() can be reached from the mailbox handler > fbnic_fw_msix_intr(), but fbnic_fw_log_free() runs before IRQ/MBX > teardown. fbnic_dbg_fw_log_show() runs via debugfs and seems to be > not synchronized with removal either. >=20 > Possible Interleaving scenario: > CPU0: fbnic_dbg_fw_log_show() or fbnic_fw_log_write() > if (fbnic_fw_log_ready()) // true > ... preempt ... > CPU1: fbnic_fw_log_free() > vfree(log->data_start); > log->data_start =3D NULL; > CPU0: continues, walks log->entries or writes to log->data_start >=20 > Move readiness checks under the fw_log spinlock, and clear the log state > under the same lock in fbnic_fw_log_free() before freeing the buffer. > This makes readers/writers mutually exclusive with teardown. >=20 > Signed-off-by: Chengfeng Ye You conflated two cases. One that can happen and one that can't. >From what I can tell the debugfs issue cannot happen as the debugfs files are removed before the log is freed. If the debugfs files can still be accessed after they are removed we have bigger issues. The log is initialized after the mailbox is enabled, and freed before it is disabled so the write can currently race with the free call. That said the current fix is pretty messy in terms of resolving it. A better fix for this might be to pull out fbnic_fw_log_enable/disable from the fw_log_init/free and leave them in the places currently occupied by the fw_log_init/free calls. With that we could place the log_init before the request_mbx call, add fw_log_free as an exception case before "free_irqs", and relocate fw_log_free to the line after the fw_free_mbx calls as it is a resource that should be put in place before the mailbox is enabled, and not cleared until after the mailbox and debugfs file has been disabled.