Russel was out of the loop, re-adding him as he may have interesting
thoughts about this. Sorry for the double e-mail.
Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote on Tue, 22 Oct 2019
09:44:51 +0200:
> Hello,
>
> Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote on Mon, 21 Oct
> 2019 10:01:05 +0200:
>
> > On Fri, 18 Oct 2019 16:36:43 +0200
> > Miquel Raynal <miquel.raynal@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> > > Suggested-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxx>
> > > ---
> > >
> > > 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
Attachment:
memcpy-disassemble
Description: Binary data
______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
