From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f48.google.com (mail-dl1-f48.google.com [74.125.82.48]) (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 1F3CC3D4117 for ; Thu, 23 Apr 2026 06:55:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776927326; cv=none; b=WJwbFB3VWH2p9s1PD9Hy7cN6Amt9jUof0IqmXoIgmmcR5Z5SykFEU8kLtjsWiStYcMu1t5lKx0GxlKzR6z9HsQ/hbnewmscTUqKtvwTAFlfUJbA5PITrZOpKuw69FZVpu7pUIS4VVtUyGFCEmAI1GhJRtNVJOagIPqzg7k0rgOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776927326; c=relaxed/simple; bh=WkK0k/e0hNXF+pgwnaYOKO1eVKPkc8tQ6NYSLjy9qVY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Rjui7m040uw72W5XXSoquSwJZhPJ9NjXJ7fxjjID0PX1R5q86VkLRzDdOwt+ipj3THn2nVtSW2XQoKEf5gjroLvlX8oQkcFxGLtKST+g59Dy5P5FJsQNvYDbIL5gpko+IAtT11LDaoP2WLkAc//1OvOkJDkrirIaffVtNmVg4Ek= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wkennington.com; spf=none smtp.mailfrom=wkennington.com; dkim=pass (2048-bit key) header.d=wkennington-com.20251104.gappssmtp.com header.i=@wkennington-com.20251104.gappssmtp.com header.b=Fd+Y0jAk; arc=none smtp.client-ip=74.125.82.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wkennington.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=wkennington.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wkennington-com.20251104.gappssmtp.com header.i=@wkennington-com.20251104.gappssmtp.com header.b="Fd+Y0jAk" Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-12db7bf1541so2634300c88.0 for ; Wed, 22 Apr 2026 23:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wkennington-com.20251104.gappssmtp.com; s=20251104; t=1776927324; x=1777532124; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=lKzsjqI7iNKcF5Q0iWD4bwo8udZOOyNt3EuqeHWnF9M=; b=Fd+Y0jAkz6C4Fx9f/zRoYFB2oWEeWQTCCFGGwqW62keipxm4aeRgSRr2hBnM2WSQ+B 8pZGVF2/cYo/195cuf344zFNgyoSvIiOKLPX4ZPiJQAPjIvLvfPWq4RhQSP7Axag0TtZ ASm1x/PClm0Avt2UxSECy+32lZZ0DZE2Weora2pkW3aZhwbCENAlC8xqDstOuaIB9l37 te9Jydw6P6xG90+BAZL0yUK2Fv0VsD979ZuGLqFKPNN66qjZa5HOW5buZymy67G3PgIB cVyu2ScPB+aVoKpxW906uyFAMwEkKfKiqpfSGF6UHgb6ZoUaNkxkBsaxLgXqjPGk2RMD k75w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776927324; x=1777532124; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lKzsjqI7iNKcF5Q0iWD4bwo8udZOOyNt3EuqeHWnF9M=; b=mh0JSfRGR+NFaC3ARYm5XY1dRXsPolG58p31N4VsO6I5qDnfsCU+rL4X93c95CpQPM 3TMANcsslY+An0veCnzE7ZZFGDJtlF6eVQaokWQYThvKaGU1wpjQNMo0fChhG/ocCZeA LVW4w+sN9FSzNBjeF461+iOENrZw0+xtgv8GrK9HpM6Kep4FN7sGpAdyQDgcuB1C5vnY shKnr6bUrE09y1sYImYekMVL4QtkFeH0TrqzZQ552gw+kaFl2td4gL7gCgt4kGUJ8J4l ZNMdVdek3u0sqC8EVm6kSbnYJzN5YX7/2tBHtMQzsLYZdmcWN79RDok8fTj5CRRSPEw8 fzUQ== X-Forwarded-Encrypted: i=1; AFNElJ/8S/1DnKplzpazsM/HOcfBGM6SKyUS7B+koj2+EXhpdiyiHxL8CK5GWg5m3/rOwi8KbRbigKI5I8vPt88=@vger.kernel.org X-Gm-Message-State: AOJu0YzvDH0OXu0TutIHUQMt7w0km6jvRtRDq96TCJlcjnQxNfQs+anM 1jyx8WXso1/5h1gH7fbYSddTdVonL7iOH+D34UDcnJ7Dop7Xlz5do98knhQT1hy//ns= X-Gm-Gg: AeBDietwcqscgAQfSB798fU10AvubCIkqPdtIVdGSRRqjX+ARW52RVyvfVHOeuIoEAe ZdqwIeGnZEyrxtS7i+RF1kvEIhwGn613af3EiGopvt2fSSleaWThdtOLrRFf+F6lT/DOezv+NH8 OeErKlsDwxmJaV4GGhdSBUkdtSnRPQYVgazGOgkz8qAW15PfCT4yWKlVXPXAS6uKIkPZY+5xWWA rZLqZQXIzWGaMjsGjhopx3fE5Xfk5SlzPdoFee69RAtjR5PnoGVsFhbxCwS3AUNjpZIe8P47Yy6 fhumBtzt50mNAV65CrEY5OfV6YKysiEN10/1PKArdKMpN4O58CsbwBcHKrl/33oxvkpplW1YMUH nC20Jg+JMg/98wSuBOg8tVx5xKcUff+1RUtG5o/W1CC5KtbQZaEHI3EbPWrEYN/rOZQbpBUl9Zf TXIvj8hpNlw7wdT3lIFR9xvGZZHU8s7hRoRrXn8fHnUhrU70kgiozsXSrKlznWmgp1fR1EO27PX msMS8n6cSw72iM= X-Received: by 2002:a05:7022:fa0:b0:123:2c98:f65d with SMTP id a92af1059eb24-12c73f6fc12mr14027226c88.13.1776927324063; Wed, 22 Apr 2026 23:55:24 -0700 (PDT) Received: from ?IPV6:2600:1700:5ae0:228c:e58:7bff:fe94:34ed? ([2600:1700:5ae0:228c:e58:7bff:fe94:34ed]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12c749c422csm27268805c88.3.2026.04.22.23.55.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2026 23:55:23 -0700 (PDT) Message-ID: Date: Wed, 22 Apr 2026 23:55:21 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mctp i2c: check packet length before marking flow active To: Jeremy Kerr , Matt Johnston , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Wolfram Sang Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260423001517.79219-1-william@wkennington.com> <61bb1b3838609996600f46ccb2c4ff89d085ee6f.camel@codeconstruct.com.au> Content-Language: en-US From: "William A. Kennington III" In-Reply-To: <61bb1b3838609996600f46ccb2c4ff89d085ee6f.camel@codeconstruct.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/22/26 20:47, Jeremy Kerr wrote: > Hi William, > >> Move the mctp_i2c_get_tx_flow_state() call to after the length sanity >> check to ensure we only transition the flow state if we are actually >> going to proceed with the transmission and locking. > Good catch, thanks! > >> Subject: [PATCH] mctp i2c: check packet length before marking flow active > You'll want to indicate that this is for the net tree, rather than > net-next, so something like: > > Subject: [PATCH net] net: mctp i2c: check packet length [...] Thanks, forgot the convention... > > With that change: > > Acked-by: Jeremy Kerr > > Out of curiosity though, how did you hit the hdr_byte_count mismatch in > the first place? Our current theory is that we have known buggy firmware on our NVME MCTP devices and we are seeing some kind of corruption on the bus that we are going to fix in on the firmware side. We started also seeing kernel crashes along with the bad firmware symptoms, walked through ~110 kdumps and found i2c locks that were held by 2 owners (eeprom reading and the MCTP TX queue). This ended up causing deadlocks in the i2c stack that result in panics. We noticed in many of these cases that we had 10K+ BERs and 800+ NACKs in the i2c driver stats struct at the time of crash. > > Cheers, > > > Jeremy