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: <20200727152303.GA301827@e120877-lin.cambridge.arm.com>
Date:   Mon, 27 Jul 2020 16:23:03 +0100
From:   Vincent Donnefort <vincent.donnefort@....com>
To:     peterz@...radead.org
Cc:     mingo@...hat.com, vincent.guittot@...aro.org,
        linux-kernel@...r.kernel.org, dietmar.eggemann@....com,
        lukasz.luba@....com, valentin.schneider@....com
Subject: Re: [PATCH] sched/fair: provide u64 read for 32-bits arch helper

On Mon, Jul 27, 2020 at 02:38:01PM +0200, peterz@...radead.org wrote:
> On Mon, Jul 27, 2020 at 11:59:24AM +0100, vincent.donnefort@....com wrote:
> > From: Vincent Donnefort <vincent.donnefort@....com>
> > 
> > Introducing two macro helpers u64_32read() and u64_32read_set_copy() to
> > factorize the u64 vminruntime and last_update_time read on a 32-bits
> > architecture. Those new helpers encapsulate smp_rmb() and smp_wmb()
> > synchronization and therefore, have a small penalty in set_task_rq_fair()
> > and init_cfs_rq().
> > 
> > The choice of using a macro over an inline function is driven by the
> > conditional u64 variable copy declarations.
> > 
> >   #ifndef CONFIG_64BIT
> >      u64 [vminruntime|last_update_time]_copy;
> >   #endif
> 
> This lacks a *why*... why did you get up this morning and wrote us this
> patch.
> 
>

For 32-bit architectures, both min_vruntime and last_update_time are using
similar access. This patch is simply an attempt to unify their usage by
introducing two macros to rely on when accessing those. At the same time, it
brings a comment regarding the barriers usage, as per the kernel policy. So
overall this is just a clean-up without any functional changes.

-- 
Vincent.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ