linux-kernel - Re: [PATCH v2 15/15] x86/lib/memcpy_64.S: Convert memcpy to ALTERNATIVE

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

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB0DA1C@AcuExch.aculab.com>
Date:	Fri, 27 Mar 2015 14:58:32 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 15/15] x86/lib/memcpy_64.S: Convert memcpy to
 ALTERNATIVE_2 macro

I've just 'fallen over' this 'optimisation' on a new Intel Atom processor.
AFAICT all the copy functions get patched to 'rep movsb'.

The problem arises when one of the buffers is uncached, in this
case the 'rep movsb' has to perform single byte transfers.

So memcpy_toio() and memcpy_fromio() need to use 'rep movsq'
otherwise the performance is horrid - especially over PCIe.

The same is true for any userspace code that is copying from
mmap()ed PCI memory space.

In my case I am using copy_to/from_user() to copy directly between
PCIe space and a user buffer. While not entirely portable it only
has to run on specific hardware where it works.

I know which copies in my code are problematic, but there isn't general
copy function that will DTRT.

(Keep me on the cc list).

	David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/