From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 49C4D204C3C for ; Thu, 9 Jan 2025 10:59:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736420374; cv=none; b=hr6DJbZ89oecFfvr/CcHTTTkV+HQZCt7rSLlESsdMx5naZpiSmXajpFWTIBw619YnNxbKIeTESxDDIPwmy4EGHhjhakZ/Y10Vl24JOi2PHJZ958Weaq+YqQh14IkLtCCGdAmHh1nWzmSqAcGtDLuXuqWwRUDqHoI7GtyTLUf1w0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736420374; c=relaxed/simple; bh=QO+8EwbJGvqBWCSEp/iekR/lW1wlFfO62fQHJbRasd0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ovwE99lxygXAYmzOaih/TSHn5bdY+TaBjl44CLKgSlK9sKQzPn0/9Ka7m362jufFZRHFLyd38GO2KlctxC4TsUQR7EBDksGIaICvp3+j/4PV7/8/lYtNZS/Gyx7aSRqM+xx2mD07z+I/TGMokZU6ZuqdIazLeVf8ZzDYrJ0Lovc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HLlSy8TF; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HLlSy8TF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736420372; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wK0FqgoNCI706ZNDwKuUWEFrZzy/qpwSQvIl8nfU3ZQ=; b=HLlSy8TFpR46kiJCWakIRvcXYNi64ohL+j3ZPEjDuHDRsBZNrnFP0ACTIfbGHQtyyNTa85 OLiDwver6+5MlJQQdRhTh9lHUCzEvr7d4gtwP6klQR6kgywaGo5smDL+wEEYy6LKOHza3g ZlxHdHXjyHG/OcOYSPMRKi18/LhiHAk= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-156-T7pHITLGMdWxNBI5k-J9bg-1; Thu, 09 Jan 2025 05:59:28 -0500 X-MC-Unique: T7pHITLGMdWxNBI5k-J9bg-1 X-Mimecast-MFC-AGG-ID: T7pHITLGMdWxNBI5k-J9bg Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-7b6c51069f5so127907185a.3 for ; Thu, 09 Jan 2025 02:59:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736420368; x=1737025168; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wK0FqgoNCI706ZNDwKuUWEFrZzy/qpwSQvIl8nfU3ZQ=; b=Ss8kSb7YpunbyRbEGBLPnGeqZDfMuxjOvtdh5ebl2FrSwTtNwA9fL7ySZQwlxTczct KFwNcT7ErOxal9NjViFv1JDhqt0nsj2j7wDbobVhH2CVMdRuahs3Xdhr1qQv7k5fXN1u 8s+kfFPuWPBTfYbo09nVS90OiqaRnTjbL1fLaKk0X7HPInOzLEgqsPXu1pKqF8fRb0az iuufv3p7GvxHE3jAkRpLBBVEyrs8wVMfubsR4sgIWDLDnARE6qfsqJSTJyKGm30uZ+rd igjPHMZZLTqfKyKyH8Njv6gO0qn0AKRq1iINSdIOOhXzc2/ptQeE5/yWK7C6QANRNMsf 4irA== X-Forwarded-Encrypted: i=1; AJvYcCUFQABUqGhHjO2M/ad2Sc2+RCDArNgDUFx76p+SDkb1jBDewhBQQ6u3kUyrXOKYbJeQh8rHnE8MSc4WL3s=@vger.kernel.org X-Gm-Message-State: AOJu0YyQC8CHhNPsIt+pQHv1S9O0vwHlDZqxrAAy+Ig0REHqYrUN/vL8 QGh8rqWniaNhlMsaqIIqWqG0IQTt1MVeitOXQv9PQrkdU6dCGYyLT6YzXW+ecsS84Ytkvdgt4nx qwdp+hDGWnXFyldLi9tAVSXdpbkwX/MeKQvHP3UaEOcBRd0JHeJPefkwNHaSekw== X-Gm-Gg: ASbGncsu00jV06k7WCHBtvOP6pIR8Zmv7yiaCsHoFWr2gn1mS6isiHAcOiR3jPfg4YC 2q7wmf2JMkvB/kLIJHM/qncJEf/bFkF/aMO0en7rr+19fugYlUwKHXDN5uvftl2m//NJGCeknkV n0Bee7QttmBjMZaVFudbOZNqBDV/LkGOo86paP9VmOsA0ykzMmGVyznPEKzfSYpAt7Lm0ns/myO XjP/V13/Y/jwvgnxLHCCuswJaycrEky34Y4PWRLzGtQJsqQsV2EWKhB8Bg1IF+CirCtLQICUscm Fsg4et2Y X-Received: by 2002:a05:6214:29e5:b0:6d4:257a:8e with SMTP id 6a1803df08f44-6df9b1f6e24mr96948856d6.4.1736420368264; Thu, 09 Jan 2025 02:59:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IH8mmSRaTNnwp1OnK5Lb74v5ufYLk0h2ejCS+7l3gscGwPpNOuj4xG12KpfdG1Ge1VDxg5Avw== X-Received: by 2002:a05:6214:29e5:b0:6d4:257a:8e with SMTP id 6a1803df08f44-6df9b1f6e24mr96948636d6.4.1736420367943; Thu, 09 Jan 2025 02:59:27 -0800 (PST) Received: from [192.168.88.253] (146-241-2-244.dyn.eolo.it. [146.241.2.244]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dfab306ae1sm872096d6.111.2025.01.09.02.59.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jan 2025 02:59:27 -0800 (PST) Message-ID: <4abb5ce6-394e-47dd-ad02-ed75a8aa42e1@redhat.com> Date: Thu, 9 Jan 2025 11:59:25 +0100 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 net v2] mctp i3c: fix MCTP I3C driver multi-thread issue To: Leo Yang , jk@codeconstruct.com.au, matt@codeconstruct.com.au, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Leo Yang References: <20250107031529.3296094-1-Leo-Yang@quantatw.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20250107031529.3296094-1-Leo-Yang@quantatw.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 1/7/25 4:15 AM, Leo Yang wrote: > We found a timeout problem with the pldm command on our system. The > reason is that the MCTP-I3C driver has a race condition when receiving > multiple-packet messages in multi-thread, resulting in a wrong packet > order problem. > > We identified this problem by adding a debug message to the > mctp_i3c_read function. > > According to the MCTP spec, a multiple-packet message must be composed > in sequence, and if there is a wrong sequence, the whole message will be > discarded and wait for the next SOM. > For example, SOM → Pkt Seq #2 → Pkt Seq #1 → Pkt Seq #3 → EOM. > > Therefore, we try to solve this problem by adding a mutex to the > mctp_i3c_read function. Before the modification, when a command > requesting a multiple-packet message response is sent consecutively, an > error usually occurs within 100 loops. After the mutex, it can go > through 40000 loops without any error, and it seems to run well. > > But I'm a little worried about the performance of mutex in high load > situation (as spec seems to allow different endpoints to respond at the > same time), do you think this is a feasible solution? For the record, I'm taking the liberty of dropping the above paragraph from the changelog, as the question IMHO should have been placed after the --- separator, has been already replied and repost just for this change would consume more time from everyone. Cheers, Paolo