linux-kernel - Re: [PATCH v2 17/26] selftests/resctrl: Replace file write with volatile variable

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 for Android: free password hash cracker in your pocket

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

Message-ID: <7e373b7a-3d62-5eb1-c11f-70dd62293b97@linux.intel.com>
Date:   Thu, 7 Dec 2023 17:03:11 +0200 (EET)
From:   Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To:     Reinette Chatre <reinette.chatre@...el.com>
cc:     linux-kselftest@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
        Shaopeng Tan <tan.shaopeng@...fujitsu.com>,
        Maciej Wieczór-Retman 
        <maciej.wieczor-retman@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 17/26] selftests/resctrl: Replace file write with
 volatile variable

On Tue, 28 Nov 2023, Reinette Chatre wrote:
> On 11/20/2023 3:13 AM, Ilpo Järvinen wrote:
> > The fill_buf code prevents compiler optimizating the entire read loop
> > away by writing the final value of the variable into a file. While it
> > achieves the goal, writing into a file requires significant amount of
> > work within the innermost test loop and also error handling.
> > 
> > A simpler approach is to take advantage of volatile. Writing to a
> > variable through a volatile pointer is enough to prevent compiler from
> > optimizing the write away, and therefore compiler cannot remove the
> > read loop either.
> > 
> > Add a volatile 'value_sink' into resctrl_tests.c and make fill_buf to
> > write into it. As a result, the error handling in fill_buf.c can be
> > simplified.
> > 
> 
> The subject and changelog describes the need for a volatile variable.
> The patch introduces two volatile variables. Could you please elaborate
> why two volatile variables are needed?

Well, the other "volatile variable" is a pointer to a volatile variable.

I've seen gcc to kill a static volatile int so I prefer to not take 
change with its optimizer. Thus, I placed the sink into different 
compilation unit and just present a pointer to the actual "volatile" 
variable.

I guess the sink could be marked as plain int instead but this being 
trickery to begin with I don't see much value either way. It's still
a trick.

I'll alter the changelog's wording though, "a volatile variable" is
not accurate as it's "a pointer to a volatile variable".

-- 
 i.