linux-kernel - Re: [PATCH] arm64: enable ARCH_WANT_RELAX

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:   Mon, 20 Mar 2017 11:52:15 +0000
From:   Will Deacon <will.deacon@....com>
To:     Ding Tianhong <dingtianhong@...wei.com>
Cc:     Robin Murphy <robin.murphy@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        alexander.duyck@...il.com, Mao Wenan <maowenan@...wei.com>
Subject: Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64

On Tue, Mar 14, 2017 at 10:06:48PM +0800, Ding Tianhong wrote:
> On 2017/3/13 21:31, Robin Murphy wrote:
> > On 13/03/17 12:03, Ding Tianhong wrote:
> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >> index 8c7c244..36249a3 100644
> >> --- a/arch/arm64/Kconfig
> >> +++ b/arch/arm64/Kconfig
> >> @@ -115,6 +115,7 @@ config ARM64
> >>  	select SPARSE_IRQ
> >>  	select SYSCTL_EXCEPTION_TRACE
> >>  	select THREAD_INFO_IN_TASK
> >> +	select ARCH_WANT_RELAX_ORDER
> > 
> > I'd say the first order of business is to rename this config option to
> > IXBGE_82599_WANT_RELAXED_ORDER so that it's not entirely misleading and
> 
> not only for 82599, including 82598, 82576....
> 
> > ambiguous. At first glance it looks far more like something scary to do
> > with memory barriers than a network driver option. Howcome this isn't
> > just in drivers/net/intel/Kconfig as a "default y if SPARC" bool anyway?
> 
> didn't see any essential differences, and I still need to get some Acked by arm maintainer.
> 
> > 
> 
> Yes, more memory barriers always affect the performance especially for
> some architecture not just like sparc, any optimization should be taken seriously
> especially for aarch64.

If this is a legitimate optimisation to apply (which nobody seems to be sure
about), then I'd *much* rather it was handled entirely in the driver and
predicated on CONFIG_ARM64. I can't select ARCH_WANT_RELAX_ORDER without
some notion of what on Earth that means, and whether or not other drivers
can also use that to infer some property about the arm64 ordering model.

Will