public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Marcello Sylvester Bauer <marcello.bauer@9elements.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	x86@kernel.org,
	syzbot+c793a7eca38803212c61@syzkaller.appspotmail.com,
	syzbot+5127feb52165f8ab165b@syzkaller.appspotmail.com,
	oe-lkp@lists.linux.dev, bp@alien8.de,
	dave.hansen@linux.intel.com, syzkaller-bugs@googlegroups.com
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>,
	Frederic Weisbecker <frederic@kernel.org>,
	Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>,
	gregkh@linuxfoundation.org, hpa@zytor.com, mingo@redhat.com,
	stern@rowland.harvard.edu, Alan Stern <stern@rowland.harvard.edu>,
	Matthias Stoeckl <matthias.stoeckl@secunet.com>
Subject: Re: Needed help: dummy_hcd: Fix stalls/inconsistent_lock_state due to hrtimer migration
Date: Mon, 24 Jun 2024 15:19:23 +0200	[thread overview]
Message-ID: <87y16u8omc.ffs@tglx> (raw)
In-Reply-To: <0eee9b08bf1f1889b3455099a68f9eed7f71c50e.camel@9elements.com>

On Mon, Jun 24 2024 at 12:25, Marcello Sylvester Bauer wrote:
> I need some help evaluating and fixing a regression due to migration to
> hztimer scheduler in dummy_hcd.
>
> About two months ago I was investigating poor performance for the mass
> storage gadget (g_mass_storage) due to slow timings in the loopback hcd
> driver (dummy_hcd). One of the reasons was that dummy_hcd used the old
> timer API, where the interval is tied to the internal kernel timer
> frequency. So I submitted the patch to migrate to the hrtimer API[^1],
> which was quickly approved.
>
> Since then, syzbot[^2][^3] and intel's kernel test bot[^4] are
> detecting rcu stalls/inconsistent_lock_state due to my patch, and I'm
> trying to figure out how to fix it.
>
> Both bots indicate that the problem is around the usb_hcd_giveback_urb
> function call and it's locking mechanism. 
>
> My patch just replaces the timer API calls without changing anything
> else in the code, so I'm not sure if my patch is actually the root
> cause here. And following the instructions to reproduce syzbot
> regressions[^5] even with the provided assets (bzImage, disk image,
> repro.c) it is quite inconsistent to cause this stall. I have also
> tried to follow Alex Stern's advice, but have not been able to cause a
> stall manually.
>
> So I don't know what to do next. Can someone with more expertise in
> timers look into this?
> Any hints or help in investigating or fixing this regression would be
> greatly appreciated.

The main difference between the timer list timer and the hrtimer is that
the timer list timer callback runs in soft interrupt context, but the
hrtimer callback runs in hard interrupt context.

I really don't know whether it matters, but you can make the hrtimer
expire in soft interrupt context with HRTIMER_MODE_REL_SOFT instead of
HRTIMER_MODE_REL. If you have a reproducer then that should tell you
quickly.

Thanks,

        tglx



  reply	other threads:[~2024-06-24 13:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16 19:17 [syzbot] [usb?] INFO: rcu detected stall in schedule_timeout (6) syzbot
2024-05-16 22:01 ` syzbot
2024-06-04 12:05   ` Marcello Sylvester Bauer
2024-06-04 14:20     ` Alan Stern
2024-06-24 10:25     ` Needed help: dummy_hcd: Fix stalls/inconsistent_lock_state due to hrtimer migration Marcello Sylvester Bauer
2024-06-24 13:19       ` Thomas Gleixner [this message]
2024-05-16 22:28 ` [syzbot] [usb?] INFO: rcu detected stall in schedule_timeout (6) Hillf Danton
2024-05-17  0:18   ` syzbot
2024-06-25  9:02 ` [syzbot] " syzbot
2024-06-25 10:24 ` syzbot
2024-07-08 10:56 ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y16u8omc.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=anna-maria@linutronix.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=frederic@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=marcello.bauer@9elements.com \
    --cc=matthias.stoeckl@secunet.com \
    --cc=mingo@redhat.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=stern@rowland.harvard.edu \
    --cc=syzbot+5127feb52165f8ab165b@syzkaller.appspotmail.com \
    --cc=syzbot+c793a7eca38803212c61@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox