mirror of https://lore.kernel.org/linux-amlogic/
 help / color / mirror / Atom feed
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

  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®