linux-kernel - Re: [PATCH v4 2/5] timers: Add the available mask in timer 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: <dfb2721b2619130a3b3ed45c3e6d18916faf5ccb.camel@redhat.com>
Date: Wed, 07 May 2025 15:54:32 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, 
 Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v4 2/5] timers: Add the available mask in timer migration



On Wed, 2025-05-07 at 15:40 +0200, Frederic Weisbecker wrote:
> Le Wed, May 07, 2025 at 02:46:39PM +0200, Gabriele Monaco a écrit :
> > 
> > I'm not so sure about this one though.
> > As far as I understand [1], is preventing the user from setting
> > different CPUs while doing isolcpus=nohz, and nohz_full= (which is
> > now
> > equivalent). But I seem to be able to do isolcpus=0-3 and
> > nohz_full=4-7
> > without any problem and I believe I'd hit the issue you're
> > mentioning.
> 
> Duh!
> 
> > (The same would work if I swap the masks as 0 cannot be nohz_full).
> 
> Unfortunately 0 can be nohz_full...

Well, I haven't found what enforces it, but I wasn't able to set 0 as
nohz_full, no matter what I tried on x86 and arm64. Not sure if 0 was
just by chance in this case (I'm guessing it has something to do with
tick_do_timer_cpu, I'm not quite familiar with this code).

I was trying to see if we can make some assumption in the tmigr but
what you propose (enforce fully housekeeping CPUs everywhere) seems
much neater.

> 
> > 
> >   # vng -a isolcpus=0-7 -a nohz_full=8-15 head
> > /sys/devices/system/cpu/{isolated,nohz_full}
> > 
> >   ==> /sys/devices/system/cpu/isolated <==
> >   0-7
> > 
> >   ==> /sys/devices/system/cpu/nohz_full <==
> >   8-15
> > 
> > (where probably some CPUs are set up to do housekeeping stuff
> > anyway,
> > but if we just look at the masks, we won't notice)
> > 
> > Then I assume this should not be allowed either, should it?
> > Or am I missing something here?
> 
> Exactly then. housekeeping_setup() already handles cases when
> there is no housekeeping left. I guess that section could be
> made aware of nohz_full + isolcpus not leaving any housekeeping left.
> 
> > 
> > > 
> > > But if nohz_full= is passed on boot and cpusets later create an
> > > isolated
> > > partition which spans the housekeeping set, then the isolated
> > > partition must
> > > be rejected.
> > 
> > Mmh, that would make things easier actually.
> > I assume there's no real use case for that kind of hybrid setup
> > with
> > half CPUs nohz_full and half domain isolated..
> 
> I guess we can accept nohz_full + isolated partition as long as a
> housekeeping
> CPU remains.

Yeah makes sense, I'll explore that.

Thanks,
Gabriele