[PATCH v2 6/8] arm64: Import latest memcpy()/memmove() implementation

Sat May 21 00:56:55 PDT 2022

On 2022-05-21 00:30, dann frazier wrote:
> On Tue, Jun 08, 2021 at 01:42:48PM +0100, Mark Rutland wrote:
>> On Tue, Jun 08, 2021 at 02:36:26PM +0200, Neil Armstrong wrote:
>>> On 08/06/2021 14:21, Marek Szyprowski wrote:
>>>> On 08.06.2021 13:37, Robin Murphy wrote:
>>>>> On 2021-06-08 12:15, Marek Szyprowski wrote:
>>>>>> This patch landed recently in linux-next as commit 285133040e6c ("arm64:
>>>>>> Import latest memcpy()/memmove() implementation"). Sadly it causes
>>>>>> serious issues on Khadas VIM3 board. Reverting it on top of linux
>>>>>> next-20210607 (together with 6b8f648959e5 and resolving the conflict in
>>>>>> the Makefile) fixes the issue. Here is the kernel log:
>>>>>>
>>>>>> Unable to handle kernel paging request at virtual address
>>>>>> ffff8000136bd204
>>>>>> Mem abort info:
>>>>>> ï¿½ ï¿½ ESR = 0x96000061
>>>>>> ï¿½ ï¿½ EC = 0x25: DABT (current EL), IL = 32 bits
>>>>>> ï¿½ ï¿½ SET = 0, FnV = 0
>>>>>> ï¿½ ï¿½ EA = 0, S1PTW = 0
>>>>>> Data abort info:
>>>>>> ï¿½ ï¿½ ISV = 0, ISS = 0x00000061
>>>>>
>>>>> That's an alignment fault, which implies we're accessing something
>>>>> which isn't normal memory.
>>
>> [...]
>>
>>>>>> I hope that the above log helps fixing the issue. IIRC the SDHCI driver
>>>>>> on VIM3 board uses internal SRAM for transferring data (instead of DMA),
>>>>>> so the issue is somehow related to that.
>>>>>
>>>>> Drivers shouldn't be using memcpy() on iomem mappings. Even if they
>>>>> happen to have got away with it sometimes ;)
>>>>>
>>>>> Taking a quick look at that driver,
>>>>>
>>>>> ï¿½ï¿½ï¿½ï¿½host->bounce_buf = host->regs + SD_EMMC_SRAM_DATA_BUF_OFF;
>>>>>
>>>>> is completely bogus, as Sparse will readily point out.
>>>
>>> My bad, what's the correct way to copy data to an iomem mapping ?
>>
>> We have memcpy_toio() and memcpy_fromio() for this.
> 
> ltp's read_all_sys test is triggering something similar which I
> bisected back to this commit - see below. Does this imply we need
> something like a memory_read_from_*io*_buffer()?

Should be fixed soon:

https://lore.kernel.org/lkml/20220407105120.1280-1-lorenzo.pieralisi@arm.com/

Thanks,
Robin.

> [ 2583.023514] Unable to handle kernel paging request at virtual address ffff80004a3003bf
> [ 2583.031456] Mem abort info:
> [ 2583.034259]   ESR = 0x96000021
> [ 2583.037317]   EC = 0x25: DABT (current EL), IL = 32 bits
> [ 2583.042632]   SET = 0, FnV = 0
> [ 2583.045689]   EA = 0, S1PTW = 0
> [ 2583.048834] Data abort info:
> [ 2583.051704]   ISV = 0, ISS = 0x00000021
> [ 2583.055542]   CM = 0, WnR = 0
> [ 2583.058512] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000401182231000
> [ 2583.065217] [ffff80004a3003bf] pgd=10000800001a2003, p4d=10000800001a2003, pud=100008000fa35003, pmd=100008001ddbd003, pte=0068000088230f13
> [ 2583.077751] Internal error: Oops: 96000021 [#22] SMP
> [ 2583.082710] Modules linked in: nls_iso8859_1 joydev input_leds efi_pstore arm_spe_pmu acpi_ipmi ipmi_ssif arm_cmn xgene_hwmon arm_dmc620_pmu arm_dsu_pmu cppc_cpufreq acpi_tad sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid cdc_ether hid usbnet mlx5_ib ib_uverbs ib_core uas usb_storage ast drm_vram_helper drm_ttm_helper ttm i2c_algo_bit drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops sha256_arm64 cec sha1_ce rc_core mlx5_core nvme drm psample xhci_pci nvme_core mlxfw xhci_pci_renesas tls aes_neon_bs aes_neon_blk aes_ce_blk crypto_simd cryptd aes_ce_cipher
> [ 2583.158313] CPU: 38 PID: 8392 Comm: read_all Tainted: G      D           5.13.0-rc3+ #15
> [ 2583.166394] Hardware name: WIWYNN Mt.Jade Server System B81.030Z1.0007/Mt.Jade Motherboard, BIOS 1.6.20210526 (SCP: 1.06.20210526) 2021/05/26
> [ 2583.179075] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
> [ 2583.185072] pc : __memcpy+0x168/0x260
> [ 2583.188735] lr : memory_read_from_buffer+0x58/0x80
> [ 2583.193524] sp : ffff80004321bb40
> [ 2583.196826] x29: ffff80004321bb40 x28: ffff07ffdd8bae80 x27: 0000000000000000
> [ 2583.203952] x26: 0000000000000000 x25: 0000000000000000 x24: ffff07ffd2bd5820
> [ 2583.211077] x23: ffff80004321bc30 x22: 00000000000003ff x21: ffff80004321bba8
> [ 2583.218201] x20: 00000000000003ff x19: 00000000000003ff x18: 0000000000000000
> [ 2583.225326] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [ 2583.232449] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [ 2583.239573] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
> [ 2583.246697] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
> [ 2583.253820] x5 : ffff07ffb7d93bff x4 : ffff80004a3003ff x3 : ffff07ffb7d93b80
> [ 2583.260945] x2 : ffffffffffffffef x1 : ffff80004a3003c0 x0 : ffff07ffb7d93800
> [ 2583.268069] Call trace:
> [ 2583.270504]  __memcpy+0x168/0x260
> [ 2583.273807]  acpi_data_show+0x5c/0x8c
> [ 2583.277464]  sysfs_kf_bin_read+0x78/0xa0
> [ 2583.281378]  kernfs_fop_read_iter+0xac/0x1e0
> [ 2583.285637]  new_sync_read+0xf0/0x184
> [ 2583.289290]  vfs_read+0x158/0x1e4
> [ 2583.292594]  ksys_read+0x74/0x100
> [ 2583.295898]  __arm64_sys_read+0x28/0x34
> [ 2583.299723]  invoke_syscall+0x78/0x100
> [ 2583.303466]  el0_svc_common.constprop.0+0x158/0x160
> [ 2583.308332]  do_el0_svc+0x34/0xa0
> [ 2583.311637]  el0_svc+0x2c/0x54
> [ 2583.314685]  el0_sync_handler+0xa4/0x130
> [ 2583.318596]  el0_sync+0x19c/0x1c0
> [ 2583.321903] Code: a984346c a9c4342c f1010042 54fffee8 (a97c3c8e)
> [ 2583.327989] ---[ end trace e19a85d1dd8510e5 ]---