From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E154C433EF for ; Fri, 29 Oct 2021 23:14:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 653C860F38 for ; Fri, 29 Oct 2021 23:14:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231458AbhJ2XQn convert rfc822-to-8bit (ORCPT ); Fri, 29 Oct 2021 19:16:43 -0400 Received: from mail-qk1-f179.google.com ([209.85.222.179]:38858 "EHLO mail-qk1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbhJ2XQn (ORCPT ); Fri, 29 Oct 2021 19:16:43 -0400 Received: by mail-qk1-f179.google.com with SMTP id bi29so10915296qkb.5 for ; Fri, 29 Oct 2021 16:14:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BDRvnZUE4sqi81I5tqAPBqMdjUr4Q5ab25TOPbUu00E=; b=MWuPiVYNz6S4q2Axw+/wXzDqFCPkTIKT52AmfS0boc3937cHv1+Wh8oZGtVErlEBe9 AGiqcm/6Lsk94kNQArWKwvhxOnAuGJ6uWbPhFznarWhg3LCZgVQiw2kCzn+ACPvLGItY YQFFoTTN3ThNX5OIfuMn4q3D4kaQIqz7HHiMhg0XcBz61upSIjIgRxiYfs8GsR2Azi1V ZLHV2wUFi3pWr/MiMczq+O0mHZcZKuDJFgvRemmx+hPbOrpBhJ21gkB+AHlnBxDu7m4F UsaupTyKcsEDj+swsUJ3Gl3WkCryBkKoMqOqxDB0dZJJDI+CFFVJfJzLL9dzgJ/3fq+o Qkqw== X-Gm-Message-State: AOAM532kGzuiBkNP182U7+dxdhBd6J2x/0AGfAIA2PPhUEC4OYUqasbY JkcG+k435fcKBveRAaU4Qw/uPiXh1/A= X-Google-Smtp-Source: ABdhPJxl6eTPkWwAf6bd1UVDtJ6S0MxknmtkHKLCj0AUZxeMLoKZiGxrMYznb8iJsZVedWLnH5kT0Q== X-Received: by 2002:a37:f90a:: with SMTP id l10mr11185222qkj.402.1635549253283; Fri, 29 Oct 2021 16:14:13 -0700 (PDT) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com. [209.85.160.178]) by smtp.gmail.com with ESMTPSA id t5sm968559qtc.15.2021.10.29.16.14.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 16:14:12 -0700 (PDT) Received: by mail-qt1-f178.google.com with SMTP id v29so9285257qtc.10 for ; Fri, 29 Oct 2021 16:14:12 -0700 (PDT) X-Received: by 2002:ac8:5706:: with SMTP id 6mr15076793qtw.95.1635549252466; Fri, 29 Oct 2021 16:14:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Li Yang Date: Fri, 29 Oct 2021 18:14:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop. To: Eugene Bordenkircher Cc: "linux-usb@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "balbi@kernel.org" , "gregkh@linuxfoundation.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Fri, Oct 29, 2021 at 4:27 PM Eugene Bordenkircher wrote: > > Typing Greg's email correct this time. My apologies. > > Eugene > > -----Original Message----- > From: Eugene Bordenkircher > Sent: Friday, October 29, 2021 10:14 AM > To: linux-usb@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Cc: leoyang.li@nxp.com; balbi@kernel.org; gregkh@linuxfoundataion.org > Subject: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop. > > Hello all, > > We've discovered a situation where the FSL udc driver (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over the request queue, but the queue has been corrupted at some point so it loops infinitely. I believe we have narrowed into the offending code, but we are in need of assistance trying to find an appropriate fix for the problem. The identified code appears to be in all versions of the Linux kernel the driver exists in. > > The problem appears to be when handling a USB_REQ_GET_STATUS request. The driver gets this request and then calls the ch9getstatus() function. In this function, it starts a request by "borrowing" the per device status_req, filling it in, and then queuing it with a call to list_add_tail() to add the request to the endpoint queue. Right before it exits the function however, it's calling ep0_prime_status(), which is filling out that same status_req structure and then queuing it with another call to list_add_tail() to add the request to the endpoint queue. This adds two instances of the exact same LIST_HEAD to the endpoint queue, which breaks the list since the prev and next pointers end up pointing to the wrong things. This ends up causing a hard loop the next time nuke() gets called, which happens on the next setup IRQ. > I agree with you that this looks problematic. This is probably introduced by f79a60b8785 "usb: fsl_udc_core: prime status stage once data stage has primed" that it didn't consider that the status_req has been re-used for the DATA phase. I think the proper fix should be having a separate request allocated for the data phase after the above change. > I'm not sure what the appropriate fix to this problem is, mostly due to my lack of expertise in USB and this driver stack. The code has been this way in the kernel for a very long time, which suggests that it has been working, unless USB_REQ_GET_STATUS requests are never made. This further suggests that there is something else going on that I don't understand. Deleting the call to ep0_prime_status() and the following ep0stall() call appears, on the surface, to get the device working again, but may have side effects that I'm not seeing. > > I'm hopeful someone in the community can help provide some information on what I may be missing or help come up with a solution to the problem. A big thank you to anyone who would like to help out. > > Eugene From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C23E7C433F5 for ; Fri, 29 Oct 2021 23:14:49 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BF66960F92 for ; Fri, 29 Oct 2021 23:14:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BF66960F92 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nxp.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Hgytv1dlLz3cPS for ; Sat, 30 Oct 2021 10:14:47 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=209.85.219.47; helo=mail-qv1-f47.google.com; envelope-from=pku.leo@gmail.com; receiver=) Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4HgytL2mvBz2ynS for ; Sat, 30 Oct 2021 10:14:16 +1100 (AEDT) Received: by mail-qv1-f47.google.com with SMTP id b11so3980280qvm.7 for ; Fri, 29 Oct 2021 16:14:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BDRvnZUE4sqi81I5tqAPBqMdjUr4Q5ab25TOPbUu00E=; b=KgHuOp9CZSPZjAySf8Id55ysspajfzPHhNxxbBwiIEz1RlxsgSbJBFFW9jtsqiHwoV jMAgp6JMFcuGCzFuZiY6DJagCSPWLpnGVPUiow8Uhhgv09Xt3q6zvRWCKxKZv3RXsxQ0 6b56OqfxVup/ismI4g5di52H7WrgzrsO1ZoVbvazzog2zOBQcIwIfVybPD8l72EgF6lk U+QWWFNCoYd8vuKIVbzq4IgycmgqPlacv1p+CnuXjUSbqYsXkD02ZaDnvjjc/u0JvTr0 +1smr4Id8VP7bi/Ll81hZf1YZs35cyaCHgvU29TK4tlOkD0uSQQIfwFQ6yiAeFI4mEXx GGCg== X-Gm-Message-State: AOAM532y5ERA9pvQhtLH+GHronkBtA69aYJjLbErsQ0SeJVs/hNe2YYv pacvgGPmm+5UHRcbmxwUaWqE50hBf+I= X-Google-Smtp-Source: ABdhPJxGOQTZnMcWCeU5elfg5NE7WQTIS9vVZknsCSgE+J7JGyPU9Mer3e7FFb9dgRYrP2dO68CJzg== X-Received: by 2002:a0c:d60d:: with SMTP id c13mr13772296qvj.26.1635549253377; Fri, 29 Oct 2021 16:14:13 -0700 (PDT) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com. [209.85.160.181]) by smtp.gmail.com with ESMTPSA id w185sm4916460qkd.30.2021.10.29.16.14.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 16:14:13 -0700 (PDT) Received: by mail-qt1-f181.google.com with SMTP id 19so9036597qtt.7 for ; Fri, 29 Oct 2021 16:14:12 -0700 (PDT) X-Received: by 2002:ac8:5706:: with SMTP id 6mr15076793qtw.95.1635549252466; Fri, 29 Oct 2021 16:14:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Li Yang Date: Fri, 29 Oct 2021 18:14:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop. To: Eugene Bordenkircher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "balbi@kernel.org" , "linux-usb@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "gregkh@linuxfoundation.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Oct 29, 2021 at 4:27 PM Eugene Bordenkircher wrote: > > Typing Greg's email correct this time. My apologies. > > Eugene > > -----Original Message----- > From: Eugene Bordenkircher > Sent: Friday, October 29, 2021 10:14 AM > To: linux-usb@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Cc: leoyang.li@nxp.com; balbi@kernel.org; gregkh@linuxfoundataion.org > Subject: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to u= nrecoverable loop. > > Hello all, > > We've discovered a situation where the FSL udc driver (drivers/usb/gadget= /udc/fsl_udc_core.c) will enter a loop iterating over the request queue, bu= t the queue has been corrupted at some point so it loops infinitely. I bel= ieve we have narrowed into the offending code, but we are in need of assist= ance trying to find an appropriate fix for the problem. The identified cod= e appears to be in all versions of the Linux kernel the driver exists in. > > The problem appears to be when handling a USB_REQ_GET_STATUS request. Th= e driver gets this request and then calls the ch9getstatus() function. In = this function, it starts a request by "borrowing" the per device status_req= , filling it in, and then queuing it with a call to list_add_tail() to add = the request to the endpoint queue. Right before it exits the function howe= ver, it's calling ep0_prime_status(), which is filling out that same status= _req structure and then queuing it with another call to list_add_tail() to = add the request to the endpoint queue. This adds two instances of the exac= t same LIST_HEAD to the endpoint queue, which breaks the list since the pre= v and next pointers end up pointing to the wrong things. This ends up caus= ing a hard loop the next time nuke() gets called, which happens on the next= setup IRQ. > I agree with you that this looks problematic. This is probably introduced by f79a60b8785 "usb: fsl_udc_core: prime status stage once data stage has primed" that it didn't consider that the status_req has been re-used for the DATA phase. I think the proper fix should be having a separate request allocated for the data phase after the above change. > I'm not sure what the appropriate fix to this problem is, mostly due to m= y lack of expertise in USB and this driver stack. The code has been this w= ay in the kernel for a very long time, which suggests that it has been work= ing, unless USB_REQ_GET_STATUS requests are never made. This further sugge= sts that there is something else going on that I don't understand. Deletin= g the call to ep0_prime_status() and the following ep0stall() call appears,= on the surface, to get the device working again, but may have side effects= that I'm not seeing. > > I'm hopeful someone in the community can help provide some information on= what I may be missing or help come up with a solution to the problem. A b= ig thank you to anyone who would like to help out. > > Eugene