Re: [RFC PATCH nand-next 0/2] meson-nand: support for older SoCs

[Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx>]

Hi Liang,

On Wed, Mar 20, 2019 at 4:32 AM Liang Yang <liang.yang@xxxxxxxxxxx> wrote:
>
> Hi Martin,
>
> Thanks for your time.
> On 2019/3/20 4:27, Martin Blumenstingl wrote:
> > Hello Liang,
> >
> > On Sat, Mar 16, 2019 at 11:55 AM Martin Blumenstingl
> > <martin.blumenstingl@xxxxxxxxxxxxxx> wrote:
> > [...]
> >>> Martin, Now i am not sure whether NFC driver leads to kernel panic when
> >>> calling kmem_cache_alloc_trace.
> >> thank you for confirming that it works for you on GXL
> >>
> >> I'm not sure that this is a NFC driver problem.
> >> after enabling CONFIG_SLAB_FREELIST_HARDENED in my kernel config the
> >> crash moves. it's now crashing in slub.c's kfree() at
> >> BUG_ON(!PageCompound(page));
> > I added some debug prints in meson_nfc_read_buf() to get some details
> > about the info buffer before the crash,
> > format is: meson_nfc_read_buf <virtual address> <physical address>
> >
> > during my first test three different addresses are used:
> > - meson_nfc_read_buf e9e6c640 0x29e6c640 (works fine)
> > - meson_nfc_read_buf e9e6c680 0x29e6c680 (works fine)
> > - meson_nfc_read_buf ee39a34b 0x2e39a34b (crashes during kfree)
> >
> > so I tried playing around with the allocation size (see the attached
> > patch) and changed it to:
> >    kzalloc(PER_INFO_BYTE + 64, GFP_KERNEL)
> > this results in the following addresses being used:
> > - meson_nfc_read_buf e9ea4280 0x29ea4280 (works fine)
> > - meson_nfc_read_buf e9ea4300 0x29ea4300 (works fine)
> > (there is no crash anymore)
> >
> > Liang, are there any special requirements on the "info address" like
> > the alignment?
> It must be 4 bytes alignment. i have met it previously when debugging
> NFC driver on AXG platform, but it is not specified on spec. Now i am
> confused that how to get the no aligned address "xe39a34b" when using
> kmalloc; i think it should return the aligned address. doesn't it?
thank you for confirming the 4-byte alignment requirement!
I have no explanation for the unaligned address returned by kzalloc().
I'll ask on the linux-mm mailing list if they have a hint why this
happens.

> > also do you know why the PER_INFO_BYTE buffer is allocated dynamically
> > in meson_nfc_read_buf() instead of allocating it at initialization?
> > I'm not saying that it should be changed! I'm curious because there's
> > per-meson_nfc_nand_chip info and data buffers which are allocated at
> > initialization time.
> > NAND scan or initialization is divided into three stages:
> nand_scan_ident->nand_attach->nand_scan_tail. info and data buffer which
> depend on the result of nand_scan_ident are allocated on nand_attach; so
> nand_scan_ident can not use the info buffer on meson_nfc_nand_chip.
thank you for the explanation!

> Allocating a fixed size info buffer before nand_scan_ident and attach it
> on the struct meson_nfc; Or considering not use dma for reading data
> less than 8 bytes. Both can reduce kmalloc and kfree calling. Thanks.
both suggestions sound reasonable.
however, I will search for the root cause of the unaligned address
first before changing the Meson NFC driver.

[...]
> > [    2.227374] ------------[ cut here ]------------
> > [    2.231968] WARNING: CPU: 1 PID: 1 at
> > drivers/mtd/nand/raw/nand_base.c:5503 nand_scan_with_ids+0x1718/0x171c
> > [    2.241760] No oob scheme defined for oobsize 1280
> > ...
> > (the "No oob scheme defined for oobsize 1280" message is expected)
> >
> miss mtd_set_ooblayout(mtd, &meson_ooblayout_ops) on function
> meson_nand_attach_chip.
thank you for the suggestion. I didn't have time to test this on my
board yet but I'll let you know about my results during the weekend.
Does the missing mtd_set_ooblayout() call also affect GXL or AXG boards?


Regards
Martin

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/