Hello,

Boris Brezillon <boris.brezillon@collabora.com> wrote on Mon, 21 Oct
2019 10:01:05 +0200:

> On Fri, 18 Oct 2019 16:36:43 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
> > Any write with either dd or flashcp to a device driven by the
> > spear_smi.c driver will pass through the spear_smi_cpy_toio()
> > function. This function will get called for chunks of up to 256 bytes.
> > If the amount of data is smaller, we may have a problem if the data
> > length is not 4-byte aligned. In this situation, the kernel panics
> > during the memcpy:
> > 
> >     # dd if=/dev/urandom bs=1001 count=1 of=/dev/mtd6
> >     spear_smi_cpy_toio [620] dest c9070000, src c7be8800, len 256
> >     spear_smi_cpy_toio [620] dest c9070100, src c7be8900, len 256
> >     spear_smi_cpy_toio [620] dest c9070200, src c7be8a00, len 256
> >     spear_smi_cpy_toio [620] dest c9070300, src c7be8b00, len 233
> >     Unhandled fault: external abort on non-linefetch (0x808) at 0xc90703e8
> >     [...]
> >     PC is at memcpy+0xcc/0x330  
> 
> Can you find out which instruction is at memcpy+0xcc/0x330? For the
> record, the assembly is here [1].

The full disassembled file is attached, here is the failing part:

7:			ldmfd	sp!, {r5 - r8}
  b8:	e8bd01e0 	pop	{r5, r6, r7, r8}
	UNWIND(		.fnend				) @ end of second stmfd block

	UNWIND(		.fnstart			)
			usave	r4, lr			  @ still in first stmdb block
8:			movs	r2, r2, lsl #31
  bc:	e1b02f82 	lsls	r2, r2, #31
			ldr1b	r1, r3, ne, abort=21f
  c0:	14d13001 	ldrbne	r3, [r1], #1
			ldr1b	r1, r4, cs, abort=21f
  c4:	24d14001 	ldrbcs	r4, [r1], #1
			ldr1b	r1, ip, cs, abort=21f
  c8:	24d1c001 	ldrbcs	ip, [r1], #1
			str1b	r0, r3, ne, abort=21f
  cc:	14c03001 	strbne	r3, [r0], #1
			str1b	r0, r4, cs, abort=21f
  d0:	24c04001 	strbcs	r4, [r0], #1
			str1b	r0, ip, cs, abort=21f
  d4:	24c0c001 	strbcs	ip, [r0], #1

			exit	r4, pc
  d8:	e8bd8011 	pop	{r0, r4, pc}


So the fault is triggered on a strbne instruction.

> > 
> > Workaround this issue by using the alternate _memcpy_toio() method
> > which at least does not present the same problem.
> > 
> > Fixes: f18dbbb1bfe0 ("mtd: ST SPEAr: Add SMI driver for serial NOR flash")
> > Cc: stable@vger.kernel.org
> > Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>  
> 
> I don't remember suggesting that as a final solution. I probably
> suggested to test with _memcpy_toio() to see if using a byte accessor
> was fixing the problem, but it's definitely not the right solution
> (using byte access with a memory barrier for 256 bytes buffers is likely
> to cause a huge perf penalty).
> 
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > 
> > Hello,
> > 
> > This patch could not be tested with a mainline kernel (only compiled)
> > but was tested with a stable 4.14.x kernel. I have really no idea why
> > memcpy fails in this situation that's why I propose this workaround
> > but I bet there is something deeper not working.
> > 
> > Thanks,
> > Miquèl
> > 
> >  drivers/mtd/devices/spear_smi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/devices/spear_smi.c b/drivers/mtd/devices/spear_smi.c
> > index 986f81d2f93e..d888625a3244 100644
> > --- a/drivers/mtd/devices/spear_smi.c
> > +++ b/drivers/mtd/devices/spear_smi.c
> > @@ -614,7 +614,7 @@ static inline int spear_smi_cpy_toio(struct spear_smi *dev, u32 bank,
> >  	ctrlreg1 = readl(dev->io_base + SMI_CR1);
> >  	writel((ctrlreg1 | WB_MODE) & ~SW_MODE, dev->io_base + SMI_CR1);
> >  
> > -	memcpy_toio(dest, src, len);
> > +	_memcpy_toio(dest, src, len);
> >  
> >  	writel(ctrlreg1, dev->io_base + SMI_CR1);
> >    
> 
> [1]https://elixir.bootlin.com/linux/v5.4-rc2/source/arch/arm/lib/memcpy.S


Thanks,
Miquèl