Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2678347pxp; Mon, 14 Mar 2022 02:28:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnG2lrlrUgJcdNFdfoK96XHHJM5JjW8C82LKW/4VvVt1i4ymB0rABkcESK0YYA3hv5YLUZ X-Received: by 2002:a05:6402:1c94:b0:418:540b:e486 with SMTP id cy20-20020a0564021c9400b00418540be486mr10967747edb.285.1647250130553; Mon, 14 Mar 2022 02:28:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647250130; cv=none; d=google.com; s=arc-20160816; b=hIJ/SWadcRxBQGT7SEC7LB4efkWoSBMElOUzDfeRcEKf1nKID1vcu0cnofLB2FIbMs evFbIzxGzDrzFKvhhkHvZHJaxPgrnPhzZw1H1jQsP+46jq8iq0GzjYC5/S76xZr48hHL xn9iAuQbNByMtLuMJUPAaORVmwfi5axOasqPpXel0HWk1fsCtL6QgEnnLz4wzxuWMXp0 8p1QP4PVXh0EEP9I42U9C/HNDjPlp51NJjxPKa3wL14bn/DOxZOvFSJ6+3xWkI9Hh2UC nkBY+xa4Qa3ZBzmFIVF0oU2X1mZbLDKS3G9GIs7m+0MG3u69Q9fFBsrqPO8Q1CF9anmS pb+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=eazqdUzalT+ij71jlP+2e5sLlUOVn3bZBK+mcZ4NQYE=; b=qw5yKoNrddIVBI7oGU5ZLDhbnzIo4qzeEU9CmJ8UG9aeOQmzP/WDNPO1l1kWlH4GNg SeFJqUxbavuU3s8lukYuXDUgRpundOXZwcCgXdeHrpTmcLH+d7vjWTpMSAuW+x+MxZHs 4cCwviOtG/UuvzXyMQzj+U5EOgy2FFFgl+OpHGeFbjfWYkHub/fBlyhcF9QJ+NcZsY+N A3TMZMoeX500GvMS3xdpj0Z841bkghF53oxcChcUzXqHdj+hdgx2d89gw+fXJTuCTH0E lMJcFrPvrKbTKE4TefmAW+OJCjZSisSoemIpWKG2WBUGGpKllJXuRZUe8TsYXEeKa91I FTrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bm21-20020a0564020b1500b004162c52e879si8438325edb.370.2022.03.14.02.28.25; Mon, 14 Mar 2022 02:28:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232140AbiCLQDe (ORCPT + 99 others); Sat, 12 Mar 2022 11:03:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230386AbiCLQDc (ORCPT ); Sat, 12 Mar 2022 11:03:32 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 1F383443F9 for ; Sat, 12 Mar 2022 08:02:27 -0800 (PST) Received: (qmail 1619048 invoked by uid 1000); 12 Mar 2022 11:02:26 -0500 Date: Sat, 12 Mar 2022 11:02:26 -0500 From: Alan Stern To: Pavel Skripkin Cc: syzbot , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, pavel.hofman@ivitera.com, rob@robgreener.com, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] memory leak in usb_get_configuration Message-ID: References: <000000000000351b8605d9d1d1bf@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 12, 2022 at 06:45:08PM +0300, Pavel Skripkin wrote: > > Unfortunately, that won't tell us where the extra reference is coming > > from. Here's one thing you could do if you want to continue your > > debugging: At the start of the probe routines for carl9170, usbtest, and > > spca501, add code to print in the kernel log the reference count value > > for the usb_device and usb_interface. Maybe you'll be able to see where > > the refcount goes up. > > > > Unfortunately refcount for dev and inf stays the same at the beginning of > each probe function: > > 6 for dev > 3 for inf Can you find out how those numbers compare with the values for actual working USB devices? Also, can you see what the device's refcount is just before the device_add() call in usb_new_device() and just before the put_device() call at the end of usb_disconnect() (both in drivers/usb/core/hub.c)? If they all are consistent with each then my guess that something is failing to drop a reference is probably wrong. Alan Stern