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]
Date:   Fri, 6 May 2022 10:21:30 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Sai Prakash Ranjan <quic_saipraka@...cinc.com>, arnd@...db.de,
        catalin.marinas@....com, rostedt@...dmis.org
Cc:     gregkh@...uxfoundation.org, linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        maz@...nel.org, quic_psodagud@...cinc.com, quic_tsoni@...cinc.com,
        will@...nel.org, Mathieu Poirier <mathieu.poirier@...aro.org>
Subject: Re: [PATCHv14 2/9] coresight: etm4x: Use asm-generic IO memory
 barriers

On 06/05/2022 04:02, Sai Prakash Ranjan wrote:
> Hi Suzuki,
> 
> On 5/6/2022 5:14 AM, Suzuki K Poulose wrote:
>> Hi,
>>
>> On 04/05/2022 12:28, Sai Prakash Ranjan wrote:
>>> Per discussion in [1], it was decided to move to using architecture
>>> independent/asm-generic IO memory barriers to have just one set of
>>> them and deprecate use of arm64 specific IO memory barriers in driver
>>> code. So replace current usage of __io_rmb()/__iowmb() in drivers to
>>> __io_ar()/__io_bw().
>>>
>>> [1] 
>>> https://lore.kernel.org/lkml/CAK8P3a0L2tLeF1Q0+0ijUxhGNaw+Z0fyPC1oW6_ELQfn0=i4iw@mail.gmail.com/ 
>>>
>>>
>>
>> Looking at the dis-assembly it looks like in effect they are slightly
>> different for arm64.
>>
>> i.e., before this patch we had
>>
>> "dmb osh{ld/st}"
>>
>> and after the patch we have :
>>
>> "dsb {ld/st}"
>>
>> Is this really what we want ? I don't think this is desirable.
>>
>> Suzuki
>>
> 
> No, this is not supposed to happen and I do not see how it could happen.
> __io_ar() is defined as __iormb() and __io_bw() is __iowmb().
> 
> I checked the disassembly in both case with MMIO trace off/on with 
> __etm4_cpu_save()
> as below and saw the same number of "dmb"s.
> 
> aarch64-linux-gnu-gdb -batch -ex "disassemble/rs __etm4_cpu_save" 
> vmlinux-without-mmio
> aarch64-linux-gnu-gdb -batch -ex "disassemble/rs __etm4_cpu_save" 
> vmlinux-with-mmio
> 
> Can you tell me how are you validating if I am missing something?

Apologies, I was missing the patch in this series, which adds
the arm64 definition for __io_ar/__io_bw. (hint: Please Cc
the affected subsystem in the Cover letter for the series, so
we know what the intention of the changes are).

With the patch1, yes this makes sense to me. Otherwise, __io_ar()
is default to rmb() which implies dsb ld.

With that said,

Reviewed-by: Suzuki K Poulose <suzuki.poulose@....com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ