linux-kernel - Re: [RFC 1/1] sched: Skip redundant operations for proxy tasks needing return migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANDhNCqv0iFMJanxj4uTyOHGUGxfCqb18Ku+w5y9JFKRm0M=Rg@mail.gmail.com>
Date: Wed, 16 Apr 2025 17:24:29 -0700
From: John Stultz <jstultz@...gle.com>
To: hupu <hupu.gm@...il.com>
Cc: linux-kernel@...r.kernel.org, juri.lelli@...hat.com, peterz@...radead.org, 
	vschneid@...hat.com, mingo@...hat.com, vincent.guittot@...aro.org, 
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com, 
	mgorman@...e.de, hupu@...nssion.com
Subject: Re: [RFC 1/1] sched: Skip redundant operations for proxy tasks
 needing return migration

On Wed, Apr 16, 2025 at 5:23 PM John Stultz <jstultz@...gle.com> wrote:
>
> On Thu, Apr 10, 2025 at 2:51 AM hupu <hupu.gm@...il.com> wrote:
> >
> > Hi John:
> > Thank you for your feedback.
> >
> > On Thu, Apr 10, 2025 at 10:41 AM John Stultz <jstultz@...gle.com> wrote:
> > >
> > > Unfortunately this patch crashes pretty quickly in my testing. The
> > > first issue was proxy_needs_return() calls deactivate_task() w/
> > > DEQUEUE_NOCLOCK, which causes warnings when the update_rq_clock()
> > > hasn't been called. Preserving the update_rq_clock() line before
> > > checking proxy_needs_return() avoided that issue, but then I saw hangs
> > > during bootup, which I suspect is due to us shortcutting over the
> > > sched_delayed case.
> ...
> > This patch worked correctly on my QEMU-based test platform, it seems
> > our testing methods might differ. Could you please share the details
> > of your testing environment and methodology? I’ll try to replicate the
> > issue using the same approach.
>
> Usually I boot qemu with 64 cores, and have found stress testing
> running the following separate programs frequently uncovers issues:

Oh, also I enable locktorture and boot with:
"torture.random_shuffle=1 locktorture.writer_fifo=1
locktorture.torture_type=mutex_lock locktorture.nested_locks=8
locktorture.rt_boost=1 locktorture.rt_boost_factor=50
locktorture.stutter=0 "

thanks
-john