From: Liang Yang <liang.yang@amlogic.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jianxin.pan@amlogic.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, linux-mtd@lists.infradead.org,
Miquel Raynal <miquel.raynal@bootlin.com>,
linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH nand-next 0/2] meson-nand: support for older SoCs
Date: Wed, 20 Mar 2019 11:33:52 +0800 [thread overview]
Message-ID: <8134890a-457d-7803-01a4-1832f925f65f@amlogic.com> (raw)
In-Reply-To: <CAFBinCA7LLK6K3ZqauJy2N-z5-kTfuTztmoSQ=Bk4A5Xagxddw@mail.gmail.com>
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@googlemail.com> 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?
> 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.
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.
>
> meson_nfc_read_buf debug log with PER_INFO_BYTE allocation:
> [ 2.032914] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.033005] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.037717] meson_nfc_read_buf: about to kfree info
> [ 2.042535] meson_nfc_read_buf: kfree'd info
> [ 2.046794] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.051552] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.056261] meson_nfc_read_buf: about to kfree info
> [ 2.061086] meson_nfc_read_buf: kfree'd info
> [ 2.065356] meson_nfc_read_buf e9e6c680 0x29e6c680
> [ 2.070102] meson_nfc_dma_buffer_setup 0x29e6c680
> [ 2.074810] meson_nfc_read_buf: about to kfree info
> [ 2.079635] meson_nfc_read_buf: kfree'd info
> [ 2.083978] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.088684] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.093334] meson_nfc_read_buf: about to kfree info
> [ 2.098199] meson_nfc_read_buf: kfree'd info
> [ 2.102446] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.107208] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.111883] meson_nfc_read_buf: about to kfree info
> [ 2.116765] meson_nfc_read_buf: kfree'd info
> [ 2.120996] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.125762] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.130433] meson_nfc_read_buf: about to kfree info
> [ 2.135294] meson_nfc_read_buf: kfree'd info
> [ 2.139545] Could not find a valid ONFI parameter page, trying
> bit-wise majority to recover it
> [ 2.148173] ONFI parameter recovery failed, aborting
> [ 2.153058] meson_nfc_read_buf e9e6c680 0x29e6c680
> [ 2.157831] meson_nfc_dma_buffer_setup 0x29e6c680
> [ 2.162527] meson_nfc_read_buf: about to kfree info
> [ 2.167369] meson_nfc_read_buf: kfree'd info
> [ 2.171611] meson_nfc_read_buf ee39a34b 0x2e39a34b
> [ 2.176383] meson_nfc_dma_buffer_setup 0x2e39a34b
> [ 2.181076] meson_nfc_read_buf: about to kfree info
> [ 2.185932] ------------[ cut here ]------------
> [ 2.190503] kernel BUG at mm/slub.c:3950!
> [ 2.194491] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> ...
>
> meson_nfc_read_buf debug log with PER_INFO_BYTE+64 allocation:
> [ 2.033019] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.033112] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.037847] meson_nfc_read_buf: about to kfree info
> [ 2.042642] meson_nfc_read_buf: kfree'd info
> [ 2.046909] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.051659] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.056374] meson_nfc_read_buf: about to kfree info
> [ 2.061192] meson_nfc_read_buf: kfree'd info
> [ 2.065461] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.070208] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.074922] meson_nfc_read_buf: about to kfree info
> [ 2.079742] meson_nfc_read_buf: kfree'd info
> [ 2.084087] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.088789] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.093440] meson_nfc_read_buf: about to kfree info
> [ 2.098303] meson_nfc_read_buf: kfree'd info
> [ 2.102553] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.107316] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.111990] meson_nfc_read_buf: about to kfree info
> [ 2.116870] meson_nfc_read_buf: kfree'd info
> [ 2.121103] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.125868] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.130540] meson_nfc_read_buf: about to kfree info
> [ 2.135400] meson_nfc_read_buf: kfree'd info
> [ 2.139652] Could not find a valid ONFI parameter page, trying
> bit-wise majority to recover it
> [ 2.148276] ONFI parameter recovery failed, aborting
> [ 2.153165] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.157938] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.162634] meson_nfc_read_buf: about to kfree info
> [ 2.167475] meson_nfc_read_buf: kfree'd info
> [ 2.171717] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.176489] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.181183] meson_nfc_read_buf: about to kfree info
> [ 2.186025] meson_nfc_read_buf: kfree'd info
> [ 2.190265] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde
> [ 2.196598] nand: Hynix NAND 8GiB 3,3V 8-bit
> [ 2.200840] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size:
> 16384, OOB size: 1280
> [ 2.208829] meson_nfc_read_buf e9ea4300 0x29ea4300
> [ 2.213581] meson_nfc_dma_buffer_setup 0x29ea4300
> [ 2.218291] meson_nfc_read_buf: about to kfree info
> [ 2.223115] meson_nfc_read_buf: kfree'd info
> [ 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.
>
> Regards
> Martin
>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2019-03-20 3:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 18:29 Martin Blumenstingl
2019-03-01 18:29 ` [RFC PATCH nand-next 1/2] dt-bindings: nand: meson: add support for more SoCs Martin Blumenstingl
2019-03-01 18:29 ` [RFC PATCH nand-next 2/2] mtd: rawnand: meson: support for older SoCs up to Meson8 Martin Blumenstingl
2019-03-04 4:56 ` [RFC PATCH nand-next 0/2] meson-nand: support for older SoCs Liang Yang
2019-03-05 22:12 ` Martin Blumenstingl
2019-03-07 13:09 ` Miquel Raynal
2019-03-07 13:36 ` Liang Yang
2019-03-12 9:06 ` Liang Yang
2019-03-16 10:55 ` Martin Blumenstingl
2019-03-19 20:27 ` Martin Blumenstingl
2019-03-20 3:33 ` Liang Yang [this message]
2019-03-20 20:48 ` Martin Blumenstingl
2019-03-21 12:10 ` Liang Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8134890a-457d-7803-01a4-1832f925f65f@amlogic.com \
--to=liang.yang@amlogic.com \
--cc=devicetree@vger.kernel.org \
--cc=jianxin.pan@amlogic.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=miquel.raynal@bootlin.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®