From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 4D3883AA1B2; Tue, 18 Aug 2026 15:52:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787068378; cv=none; b=Ey0VjxB+1BdbuAiaymhCbE0at8CfjyQM7zM3XhLz4zkJC4PtIh1ZUBG0ZW1cphONX5wcZpg3OkWN5tHktuKlvVFOJX62t6Ozv2kczKbh4oP5Jvtaz3ij8csjGIUTLTEM615x2xo6TNqpTluKQP8WOcUYHkYdSP874mPdfz+8yEY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787068378; c=relaxed/simple; bh=am7ybGL9Q8oSMs4hacQktmAWvyUXUl+luPF1azoUW6E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iv3IytoaqGle5n1KeL8n3ZmMg3x6m5l9r4vFUT1GLsoILZC0SkMIQ9dlL5L22tJAfRcHFhTHQEoQZWJEBfKGzc/3hDQkAWg9SyuwYy4Yp1bPPRLquTkUDcoqEWWoMSI3VOLnLTIKZNLJcqlsWLaWLAtytTZzutrPEkJ8qQRXG9E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jifPou5a; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jifPou5a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E347C1F00A3A; Tue, 18 Aug 2026 15:52:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787068376; bh=/np37PKAyOIhfidNFuVWtwBk/OqeOF98enEzZHm8JxM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jifPou5aokYHS88kaWIzuzheElhyiCJ8ZVv4x84tAOoMGGeH2r88FXhMLAAYpe6xk 6YlecvQXcpLmHIfr3AyCFCfdOKYz3bhBM3H9UPpKS/WeclWWC8U5ltuWetFWz1Qu0T OAUH4xVkKy/7wjy8DOHnhcCJLjMUkOyj/HS+43m2mxpgaVfr5iD8itGeKyDscSf861 LZ9SMgaFt9ZLrlQTSMfPlVQKlXMo8j/u9Hlt6jUKCbuD2jmgemTZLkmKcaMqgiaG3a 3NzVJBxgOadGQZsDhLRHMLC28GpK1LfrSwMtmD9DfWIv2+fKCWc67i0W1rTWrPO/Br 7EyFhxyxi0ZcQ== Received: from johan by xi.lan with local (Exim 4.99.4) (envelope-from ) id 1wwM7S-00000000v7D-3TLZ; Tue, 18 Aug 2026 17:52:54 +0200 Date: Tue, 18 Aug 2026 17:52:54 +0200 From: Johan Hovold To: =?utf-8?B?w5ZtZXI=?= Mete Kaya Cc: linux-mmc@vger.kernel.org, ulfh@kernel.org, cjb@laptop.org, tony.olech@elandigitalsystems.com, linux-kernel@vger.kernel.org, syzbot+0e06aa1bdc6495bac24b@syzkaller.appspotmail.com Subject: Re: [PATCH v2] mmc: vub300: fix sleeping function called from invalid context Message-ID: References: <20260818143658.61667-1-omermetekaya0@gmail.com> Precedence: bulk X-Mailing-List: linux-mmc@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: On Tue, Aug 18, 2026 at 05:08:43PM +0200, Johan Hovold wrote: > On Tue, Aug 18, 2026 at 05:36:56PM +0300, Ömer Mete Kaya wrote: > > syzbot reports: > > > > BUG: sleeping function called from invalid context at kernel/workqueue.c:4487 > > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/1 > > ... > > > > __might_resched > > __cancel_work_sync > > mmc_free_host+0x19/0x30 [drivers/mmc/core/host.c:700] > > call_timer_fn+0x192/0x5e0 [kernel/time/timer.c:1748] > > run_timer_softirq > > ... > > > > vub300_inactivity_timer_expired() runs in softirq (timer) context. > > When the USB interface had already gone away (->interface == NULL, > > cleared by vub300_disconnect() or the probe() error path), the timer > > handler dropped the object's last kref via > > kref_put(&vub300->kref, vub300_delete). If that was the last > > reference, vub300_delete() ran from softirq context and called > > mmc_free_host(), which calls cancel_delayed_work_sync() - a sleeping > > function, illegal from softirq/timer context. > > > > Root cause: inactivity_timer is armed in probe() and continuously > > re-armed via mod_timer(), but - unlike sg_transfer_timer, which is > > explicitly deleted after each use - it is never stopped when the > > device is torn down, so it can still fire after ->interface has > > been cleared. > > > > Fix this by decoupling inactivity_timer from the object's kref > > entirely: drop the kref_get() taken on its behalf in probe(); make > > vub300_inactivity_timer_expired() a no-op when ->interface is NULL > > instead of dropping a reference; and in both vub300_disconnect() and > > the probe() err_stop_io path, call > > timer_delete_sync(&vub300->inactivity_timer) right after clearing > > ->interface and before the final kref_put(). Since ->interface is > > already NULL at that point, any concurrently running timer instance > > takes the no-op branch, so timer_delete_sync() is guaranteed to > > return with the timer stopped for good - removing any race with the > > final kref_put()/vub300_delete()/mmc_free_host(). Before this > > patch, a successful probe() left two references on the kref (one > > from kref_init(), one from the timer's kref_get()); after it, only > > the initial kref_init() reference remains, matching the single > > kref_put() in vub300_disconnect() and err_stop_io. > > > > While auditing the driver for the same class of bug, also switch > > sg_transfer_timer's two timer_delete() call sites (in > > __command_read_data() and __command_write_data()) to > > timer_delete_sync(), since usb_sg_wait() returning does not > > guarantee a concurrently running vub300_sg_timed_out() has finished. > > __command_write_data() additionally only deleted the timer on the > > success path, leaking an armed timer on the cmd->error path; the > > (now synchronous) delete is moved before that check so it always > > runs. > > > > Reported-by: syzbot+0e06aa1bdc6495bac24b@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=0e06aa1bdc6495bac24b > > Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") > > This is not the commit that introduced the issue. See my reply to [2]. > > > Assisted-by: Claude:claude-sonnet-4-6 > > Signed-off-by: Ömer Mete Kaya > > --- > > v2: I used an LLM to help structure and polish the English commit > > message. I did not know > > this required an Assisted-by tag until Johan pointed it out - added > > now. > > So you didn't use an LLM to write the proposed fix itself? The commit > message and comments in the code makes it look that way. > > Also note that the syzbot LLM created a similar fix the day before you > posted yours: > > [1] https://lore.kernel.org/all/49982079-95f4-4e8c-bbbc-bcb127e2f378@mail.kernel.org/ Sorry, that was supposed to say: [1] https://lore.kernel.org/all/397da4bd-97e2-4367-b3f4-d69e0f58dd91@mail.kernel.org/ Apparently the bot produced two different fixes for the same issue... > and there are at least two further proposals: > > [2] https://lore.kernel.org/all/20260816153809.7067-1-jakovnovak30@gmail.com/ > [3] https://lore.kernel.org/all/20260818064800.3886851-1-tao1.yu@intel.com/ Johan