[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68b18065d8be905c25522bd3f5a9b46dbe3a976d.camel@sipsolutions.net>
Date: Wed, 25 Oct 2023 22:02:33 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Vincent Whitchurch <Vincent.Whitchurch@...s.com>,
"anton.ivanov@...bridgegreys.com" <anton.ivanov@...bridgegreys.com>,
"richard@....at" <richard@....at>
Cc: "linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kernel <kernel@...s.com>
Subject: Re: [PATCH] um: time-travel: fix time going backwards
On Wed, 2023-10-25 at 21:51 +0200, Johannes Berg wrote:
> On Wed, 2023-10-25 at 11:55 +0000, Vincent Whitchurch wrote:
> > On Mon, 2023-10-23 at 09:33 +0200, Johannes Berg wrote:
> > > Do you have a specific workload that tends to reproduce this?
> >
> > I've been seeing it when running roadtest, but it's easily reproducible
> > without that by using the attached config and the following program as
> > init.
> >
> > cp repro.config .config
> > make ARCH=um olddefconfig all
> > gcc -Wall -static -o repro repro.c
> > ./linux time-travel init=$PWD/repro rootfstype=hostfs
Ohhh.
Pure "time-travel" is actually something I hardly think about these
days, we mostly use time-travel=inf-cpu (or =ext).
That makes sense, here you actually *can* get interrupted. I'll need to
dig into what happens though.
johannes
Powered by blists - more mailing lists