From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 011D437997A for ; Wed, 14 Jan 2026 08:11:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768378269; cv=none; b=o3vJO/tv+YUnwaWvEacmvIIFivEjWMDd+aFytwVSqZv00LLnFs0sKaKzHzxHoOlBOBqwWaBZ3w2CznCCNYk12x6aTd07+X56ETHMpdhKnL0nvd/wdtR50g0nsT2Rlh004QG+3cVHV+zAg8jUy02wbDavKTBKTOz+kjnvokp+XhA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768378269; c=relaxed/simple; bh=Hb7ceaTeivR5urdB5AA77JIF1//DwtyGxzQxlMKUbUs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=B/8MUVLeQLtXbHSCJCwISVFN/nfVx/ALRLhOf7NJOqXxPmAh9MvdFMkn/qMOiUXUJ83GnS3ckA0FY411lpiZ7W6j6Tz9sVu7L9/cRou02reYCDuZHmZaB/Ty9mB0Q6FverFW5qjwkoaLW02SIx8lnpV1cqcbYn2d5N7sk6QTBZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=e/7U1NoD; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="e/7U1NoD" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2a08cb5e30eso17355555ad.1 for ; Wed, 14 Jan 2026 00:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768378266; x=1768983066; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=UrBOS5eH8s+cAF+LrmXQgQpKlTUB93zAcRN2powL0Ws=; b=e/7U1NoDK7HbTyqriwmGy4tTNR/uUsWwYAxvCk06AkQF8MtKFHJtB2Ybzf3Y0PJHy7 43MIkph++ybxTT15a9Nqy4vm891N3ripIaeItDJcrAyGW1cJ8hQu8iFpK56fu4SE5mn6 WAGnxutim6C+mc1hWJjBzigeyCBz6yawPqYO5Wfcnc5Qd7OywHICmJHVWZMS3x98b0PA UhpUNpWfpmoNUf3/wFtPEka0CQxf9NbzHmo/uYSy4tL7uIwe13H8NqJTFlVI/7IPIowZ RyQvYyIk2RHlrosLiRaLPkS8NNXl7pZW+TXCUiwRP5bCbu/fBUjZwRO1ywmCvuIl7agY vBYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768378266; x=1768983066; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=UrBOS5eH8s+cAF+LrmXQgQpKlTUB93zAcRN2powL0Ws=; b=YVoPAn6jDegFLYJFJz2VfXQumAoFy3hJGSm8YbfkWG80QfNonZRKPz68rXxf5Mb62G emSKiPtOhw6SUWtUHTTS6n3eThc46FQyCn0eU81/ohwL+cAm+qgCLtD+KCSwpHoN51F3 1LSPPxOSjZKHz5VpzkDIEXY83l7vHynChQyVekx4hDBBdJ5c8kl8UXGASJ+H3M4gb9Sh pq7T8T3O52obaKfQ/5QsmgJtAI+izcrIZFZpZuuXfTkwn+5915sQ2I8MWvwek0ecciY2 58k8xhImyba2fLKtBV6L6fewB7MMfWw2bve6Q/iNMnzGEXQPkVvtdvJT/8E98qkOd88H UZyQ== X-Forwarded-Encrypted: i=1; AJvYcCXWwV/oNa/zPPdVvJiIe59CU9lyF6vi51DMmw+UD13HuKFxlTs8T0XBCjsZnyyZ4hByeISaSBSPWzEs7lU=@vger.kernel.org X-Gm-Message-State: AOJu0YxVTyjk13xwSL+xSA1NpQkooR/VbXFbEetpW0sYob+ep9we58xZ EvDAKCB7EcKmy9fiGwPPWJLHS4YGaurY1SgsqSORpLjWU9bURtVKZxKu X-Gm-Gg: AY/fxX6U3qMSIY20GZ16TA0JPIjoiK4SEL3TP9fAndNBVXVwWGZ9k3LsTXZaBmc8z0P H9MXyTkg9UxVHi1WoUyirwLSjrWak2tkK9119MFgTt5Z71lvOWBjspBKxzatLhrsF5CoB6xGiX7 Dm6NU9Uooa2vLJAgzBNAZGjD+B34RdpJSYijFufMOWfNMlENV+3EcsSWR8dhf2+MCO7lb2QkiQD 6P0G9DSzdBJVjzpzQAotYrYNRHcr4CoDlbMEdFjmR/JoR8hKq72VoMKds63q9NcJZjVRPIK3pB5 bmHHgfvHiGvqz1VC9sNZ2L1nrsNu2LI+eaO6L/yOMamk6syXyLGZAENaArWsdopseeH5rOv3lt4 fHfHdxP0mvoiHFzxw4WD6NDkuTGzzuwaAFb9cfU5hWohU1PYB+UpEgTFhIUJcINUQchPMDnWpql JthTeOgtBRbQ== X-Received: by 2002:a17:90b:58cb:b0:338:3156:fc3f with SMTP id 98e67ed59e1d1-3510913ccd3mr1305979a91.4.1768378265722; Wed, 14 Jan 2026 00:11:05 -0800 (PST) Received: from MiniPC.. ([47.246.98.222]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35109d88f0esm1199575a91.5.2026.01.14.00.11.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 00:11:05 -0800 (PST) From: weipeng To: oneukum@suse.com Cc: anna-maria@linutronix.de, coderlogicwei@gmail.com, frederic@kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, syzkaller-bugs@googlegroups.com, tglx@linutronix.de Subject: Re: [syzbot] [usb?] INFO: task hung in i2c_tiny_usb_disconnect Date: Wed, 14 Jan 2026 16:11:00 +0800 Message-Id: <20260114081100.830758-1-coderlogicwei@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On 2026-01-13 20:23, Oliver Neukum wrote: > what prevents the following sequence: > > i2c_tiny_usb_disconnect() -> module unload -> i2c_tiny_usb_release() > > As far as I can tell, this can happen and you'd execute already > freed memory. Hi, I got it. It can be solved by using wait_for_completion in the module exit function to wait for all the i2c_tiny_usb_release() to be done. But after think twice, I think it is not a good idea. Because that would be too complicated for a driver. Almost all the usb drivers does not do like this. They just call release functions in the disconnect() rather than put all the release works to another task. So I think the key point is not the disconnect(). The key point is the i2c subsystem: > void i2c_del_adapter(struct i2c_adapter *adap) > { > ... > /* wait until all references to the device are gone > * > * FIXME: This is old code and should ideally be replaced by an > * alternative which results in decoupling the lifetime of the struct > * device from the i2c_adapter, like spi or netdev do. Any solution > * should be thoroughly tested with DEBUG_KOBJECT_RELEASE enabled! > */ > init_completion(&adap->dev_released); > device_unregister(&adap->dev); > wait_for_completion(&adap->dev_released); > ... > } The i2c_del_adapter() will wait for all the users to put the reference of the adapter. It is not a good idea. We can't control the users. So the i2c_del_adapter() can wait for any time. Best Regards weipeng