netdev - Re: [PATCH v3 6/6] IB/mlx5: Use __iowrite64

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] [day] [month] [year] [list]

Message-ID: <20250718200045.GG2250220@nvidia.com>
Date: Fri, 18 Jul 2025 17:00:45 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Will Deacon <will@...nel.org>,
	Alexander Gordeev <agordeev@...ux.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christian Borntraeger <borntraeger@...ux.ibm.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
	Vasily Gorbik <gor@...ux.ibm.com>,
	Heiko Carstens <hca@...ux.ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Leon Romanovsky <leon@...nel.org>,
	linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org,
	llvm@...ts.linux.dev, Ingo Molnar <mingo@...hat.com>,
	Bill Wendling <morbo@...gle.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>,
	Salil Mehta <salil.mehta@...wei.com>,
	Sven Schnelle <svens@...ux.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Yisen Zhuang <yisen.zhuang@...wei.com>,
	Arnd Bergmann <arnd@...db.de>,
	Leon Romanovsky <leonro@...lanox.com>, linux-arch@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Mark Rutland <mark.rutland@....com>,
	Michael Guralnik <michaelgur@...lanox.com>, patches@...ts.linux.dev,
	Niklas Schnelle <schnelle@...ux.ibm.com>,
	Jijie Shao <shaojijie@...wei.com>
Subject: Re: [PATCH v3 6/6] IB/mlx5: Use __iowrite64_copy() for write
 combining stores

On Fri, Jul 18, 2025 at 07:10:06PM +0100, Catalin Marinas wrote:
> On Tue, Jul 15, 2025 at 08:52:00AM -0300, Jason Gunthorpe wrote:
> > On Tue, Jul 15, 2025 at 11:15:25AM +0100, Will Deacon wrote:
> > > > Since STP was rejected alread we've only tested the Neon version. It
> > > > does make a huge improvement, but it still somehow fails to combine
> > > > rarely sometimes. The CPU is really bad at this :(
> > > 
> > > I think the thread was from last year so I've forgotten most of the
> > > details, but wasn't STP rejected because it wasn't virtualisable? 
> > 
> > Yes, that was the claim.
> > 
> > > In which case, doesn't NEON suffer from exactly the same (or possibly
> > > worse) problem?
> > 
> > In general yes, in specific no.
> 
> For a generic iowrite function, I wouldn't use STP or Neon since it may
> end up being used on emulated MMIO.

Yes, my feeling too
 
> BTW, for Neon, don't you need kernel_neon_begin/end()? This may have its
> own overhead and also BUG_ON for different contexts. Again, not suitable
> for a generic function.

Yes, exactly right.
 
> I can't think of any generic solution here, it may have to be a hack
> specific to mlx5. We can also add add support for ST64B and have some
> condition on system_supports_st64b() for future systems.

Ok, we will send the hack

> We can also add add support for ST64B and have some
> condition on system_supports_st64b() for future systems.

I have asked someone to work on the ST64B version so we can talk about
that then..

> Even if we could handle virtualisation, I wonder whether
> __iowrite64_copy() is the right function to implement 128-bit stores or
> the larger 64-byte atomic stores. At least the comment for the generic
> function suggests that it writes in 64-bit quantities. Some MMIO may
> only handle such writes. A function like memcpy_toio() is more generic,
> it doesn't imply any restrictions on the size of the writes (though I
> think it guarantees natural alignment for the stores).

IMHO the '64' here refers to the alignment and multiple, not
necessarily the transfer granule size. This could be clarified in the
kdocs. Also, IIRC, there were few users and they were all doing WC
stores which give large TLPs on the PCIe - meaning there is no size
restriction issue.

Last time around we didn't use memcpy_toio() because it has not
requirement on alignment, requiring more checks and things which
didn't see desirable. To use ST64B under iowrite64 we only have to
check if the destination is 64 byte aligned.

Jason