Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp1294757rbb; Mon, 26 Feb 2024 05:13:48 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWO2lE5cIatprz+BwSsepMuM8BNqU6e/I6j4gsxHmNeUSnytodNWI0d9AzUPDlpw3s3Oz9MGMe3ew3H01lVb8t7aNoyUQ2OHjn4pQJv/g== X-Google-Smtp-Source: AGHT+IF2WJAos46aQpuo0xMeFcGu9mWUZWtWHOGx1D+pWSfmagBJPSpbL4YHgrxyom14Z5DxSsBV X-Received: by 2002:a05:690c:d21:b0:608:b4:d530 with SMTP id cn33-20020a05690c0d2100b0060800b4d530mr7035238ywb.20.1708953228380; Mon, 26 Feb 2024 05:13:48 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708953228; cv=pass; d=google.com; s=arc-20160816; b=NFzIPa0UhhT9TbMHYww9OAvsQkP6z6C/J2s0wUD4SqYroEOV4g2F77fHsIp/p3/T07 q5F0XczSaAkw/K/cc187vA7rxrI+rVjeqgCJbQ0iNBM3rV9IwhJKDeriKTCMy2EJc2ud go/XHIfr84vMz4Ny14NRAI6g+nrq+6s5x0E4eufwHhpnt52c5raBtP1wrebnzo9pk0G0 saA0RNpUisEGkN+PGsVLoYR2D+pXnH/jcdKWgEFdVsXA3I+uU8d6wJoDiZ53SG+op2G/ YB9UGvJ2SGhbmudtBUueNHiEPyNRYPlgIIZvN+Q1XOIeX517I9Pj7n0pBeXNoyb3Ql0/ YTiw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=XrJaRl/i8WegCldf8LCVE5CThus2MUtbS0XrzCijRIE=; fh=bhR7WtrIyJuoCJ4FnoCk2GHb3e8nURnys41KxjeTunA=; b=JUIhoGD/keTy2rnvJHhSRK973BCW56u+JrqSboq2nrxKtftwWqynMFbhHPGpFBe1Rt nHj8REJexx0TsH/CnLjl4KiAb6/9kMsTL2ugthJg5/qiUhPBZPjPKjHJCtG2bVeow3FX spn2baj9grJu3wXhn6rjuHaCOcpR/Pwr61igrbrSE5QPMzY7dQG/YfL/oD6Cg4ZUEGVy e6blSzHknugU/gN/PROiHnsfBd0F6v2PMwhyP7DvOjR+5gFGo3vHYLgvCiw2spK3v9fA Brdg3jmietICVOGmbt/K93lECV1xWlJW9lOs/QFMi6wtgFbNSVP7PjaVyfkVVI3GwgW7 tQ5g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hc3rG1yg; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-81457-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-81457-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id xz16-20020a05620a5e1000b007873a97da69si4702979qkn.161.2024.02.26.05.13.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 05:13:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-81457-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hc3rG1yg; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-81457-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-81457-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 262101C288A4 for ; Mon, 26 Feb 2024 13:13:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 06BC08528A; Mon, 26 Feb 2024 13:13:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="hc3rG1yg" 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 23A9580037; Mon, 26 Feb 2024 13:13:40 +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=1708953220; cv=none; b=KSEwofR6QJHVBpJLcQmlFcqsu4LFnCNdKEsZDK7i+0gGASAG2Vb03zoWMiOuHzkYCCWalbe3OpCdd+mygCJI1QNLkPVf66Od8eUpOHC4h0pFgWLw0K/x3reB9sOBOb1yELn/4jmer8x/RsUNXu4BmHYtjdALmkdsQ3DjxsZUXPQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708953220; c=relaxed/simple; bh=5d8tuwRD3hnn1I/Q5u9fzmp1C7q+UTW7gVYHJW8kmrc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=krIQiO7OIUqoHxhB5YZ9QOkfwoN3UG1OWPSzhlyhXQo251cthAhA8QAu9VZZI08KWAa2xvj16cJTNVqooqbNMS1FO3LEmGFmheIe3ve2OVHnQ9FPFZk1zCDPx97RTvOijQ7P1QpGVeiM9NPpRKy2v8hefN947e8nfaAexG4Rt2I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=hc3rG1yg; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id A64FAC433F1; Mon, 26 Feb 2024 13:13:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1708953220; bh=5d8tuwRD3hnn1I/Q5u9fzmp1C7q+UTW7gVYHJW8kmrc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hc3rG1yg2BT8VqE8Z4ZwK4KtS8Lwnpl4TmaFs/SYKt8drW1WeIAbd8KPilt2BRNPX sanWLnB4FwMlOzwk4BB3yfkdfNRBnjz3LVsgFBxamgyzw4OswEu9u08JmXoLxAOq/t oVfQcxbKs2kKClI8Dpi2ezGeuwkYW8fj4uiH2lAg= Date: Mon, 26 Feb 2024 14:13:21 +0100 From: Greg Kroah-Hartman To: Krishna Kurapati Cc: Maciej =?utf-8?Q?=C5=BBenczykowski?= , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, quic_ppratap@quicinc.com, quic_wcheng@quicinc.com, quic_jackp@quicinc.com Subject: Re: [RFC PATCH] usb: gadget: ncm: Fix handling of zero block length packets Message-ID: <2024022602-each-tropical-9459@gregkh> References: <20240226112816.2616719-1-quic_kriskura@quicinc.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240226112816.2616719-1-quic_kriskura@quicinc.com> On Mon, Feb 26, 2024 at 04:58:16PM +0530, Krishna Kurapati wrote: > While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX > set to 65536, it has been observed that we receive short packets, > which come at interval of 5-10 seconds sometimes and have block > length zero but still contain 1-2 valid datagrams present. > > According to the NCM spec: > > "If wBlockLength = 0x0000, the block is terminated by a > short packet. In this case, the USB transfer must still > be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If > exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, > and the size is a multiple of wMaxPacketSize for the > given pipe, then no ZLP shall be sent. > > wBlockLength= 0x0000 must be used with extreme care, because > of the possibility that the host and device may get out of > sync, and because of test issues. > > wBlockLength = 0x0000 allows the sender to reduce latency by > starting to send a very large NTB, and then shortening it when > the sender discovers that there’s not sufficient data to justify > sending a large NTB" > > However, there is a potential issue with the current implementation, > as it checks for the occurrence of multiple NTBs in a single > giveback by verifying if the leftover bytes to be processed is zero > or not. If the block length reads zero, we would process the same > NTB infintely because the leftover bytes is never zero and it leads > to a crash. Fix this by bailing out if block length reads zero. > > Fixes: 427694cfaafa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call") > Signed-off-by: Krishna Kurapati > --- > > PS: Although this issue was seen after CDC_NCM_NTB_DEF_SIZE_TX > was modified to 64K on host side, I still believe this > can come up at any time as per the spec. Also I assumed > that the giveback where block length is zero, has only > one NTB and not multiple ones. Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You have marked a patch with a "Fixes:" tag for a commit that is in an older released kernel, yet you do not have a cc: stable line in the signed-off-by area at all, which means that the patch will not be applied to any older kernel releases. To properly fix this, please follow the documented rules in the Documentation/process/stable-kernel-rules.rst file for how to resolve this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot