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

dann frazier dann.frazier at canonical.com
Mon May 23 10:27:53 PDT 2022


[ + Lorenzo ]
On Sat, May 21, 2022 at 08:56:55AM +0100, Robin Murphy wrote:
> 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/

Ah, thanks for the pointer Robin! I'll likely propose this for stable
once it lands (unless there's a reason not to?). My assumption is that
this is a bug unrelated to the new memcpy/memmove implementation, and
that this the new code just made it easier to trip. If that's the
case, I'll plan to propose it for the older stable trees as well.

  -dann

> 
> > [ 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 ]---



More information about the linux-arm-kernel mailing list