From: Liang Yang <liang.yang@amlogic.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Matthew Wilcox <willy@infradead.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<akpm@linux-foundation.org>, <mhocko@suse.com>,
<rppt@linux.ibm.com>, <linux-amlogic@lists.infradead.org>,
<linux@armlinux.org.uk>, <linux-mtd@lists.infradead.org>
Subject: Re: 32-bit Amlogic (ARM) SoC: kernel BUG in kfree()
Date: Mon, 25 Mar 2019 18:04:17 +0800 [thread overview]
Message-ID: <5cad2529-8776-687e-58d0-4fb9e2ec59b1@amlogic.com> (raw)
In-Reply-To: <CAFBinCA6oK5UhDAt9kva5qRisxr2gxMF26AMK8vC4b1DN5RXrw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]
Hi Martin,
On 2019/3/23 5:07, Martin Blumenstingl wrote:
> Hi Matthew,
>
> On Thu, Mar 21, 2019 at 10:44 PM Matthew Wilcox <willy@infradead.org> wrote:
>>
>> On Thu, Mar 21, 2019 at 09:17:34PM +0100, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> I am experiencing the following crash:
>>> ------------[ cut here ]------------
>>> kernel BUG at mm/slub.c:3950!
>>
>> if (unlikely(!PageSlab(page))) {
>> BUG_ON(!PageCompound(page));
>>
>> You called kfree() on the address of a page which wasn't allocated by slab.
>>
>>> I have traced this crash to the kfree() in meson_nfc_read_buf().
>>> my observation is as follows:
>>> - meson_nfc_read_buf() is called 7 times without any crash, the
>>> kzalloc() call returns 0xe9e6c600 (virtual address) / 0x29e6c600
>>> (physical address)
>>> - the eight time meson_nfc_read_buf() is called kzalloc() call returns
>>> 0xee39a38b (virtual address) / 0x2e39a38b (physical address) and the
>>> final kfree() crashes
>>> - changing the size in the kzalloc() call from PER_INFO_BYTE (= 8) to
>>> PAGE_SIZE works around that crash
>>
>> I suspect you're doing something which corrupts memory. Overrunning
>> the end of your allocation or something similar. Have you tried KASAN
>> or even the various slab debugging (eg redzones)?
> KASAN is not available on 32-bit ARM. there was some progress last
> year [0] but it didn't make it into mainline. I tried to make the
> patches apply again and got it to compile (and my kernel is still
> booting) but I have no idea if it's still working. for anyone
> interested, my patches are here: [1] (I consider this a HACK because I
> don't know anything about the code which is being touched in the
> patches, I only made it compile)
>
> SLAB debugging (redzones) were a great hint, thank you very much for
> that Matthew! I enabled:
> CONFIG_SLUB_DEBUG=y
> CONFIG_SLUB_DEBUG_ON=y
> and with that I now get "BUG kmalloc-64 (Not tainted): Redzone
> overwritten" (a larger kernel log extract is attached).
>
> I'm starting to wonder if the NAND controller (hardware) writes more
> than 8 bytes.
> some context: the "info" buffer allocated in meson_nfc_read_buf is
> then passed to the NAND controller IP (after using dma_map_single).
>
> Liang, how does the NAND controller know that it only has to send
> PER_INFO_BYTE (= 8) bytes when called from meson_nfc_read_buf? all
> other callers of meson_nfc_dma_buffer_setup (which passes the info
> buffer to the hardware) are using (nand->ecc.steps * PER_INFO_BYTE)
> bytes?
>
NFC_CMD_N2M and CMDRWGEN are different commands. CMDRWGEN needs to set
the ecc page size (1KB or 512B) and Pages(2, 4, 8, ...), so
PER_INFO_BYTE(= 8) bytes for each ecc page.
I have never used NFC_CMD_N2M to transfer data before, because it is
very low efficient. And I do a experiment with the attachment and find
on overwritten on my meson axg platform.
Martin, I would appreciate it very much if you would try the attachment
on your meson m8b platform.
>
> Regards
> Martin
>
>
> [0] https://lore.kernel.org/patchwork/cover/913212/
> [1] https://github.com/xdarklight/linux/tree/arm-kasan-hack-v5.1-rc1
>
[-- Attachment #2: nand_debug.diff --]
[-- Type: text/plain, Size: 1104 bytes --]
diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
old mode 100644
new mode 100755
index e858d58..905ef39
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -527,11 +527,12 @@ static void meson_nfc_dma_buffer_release(struct nand_chip *nand,
static int meson_nfc_read_buf(struct nand_chip *nand, u8 *buf, int len)
{
struct meson_nfc *nfc = nand_get_controller_data(nand);
- int ret = 0;
+ int ret = 0, i;
u32 cmd;
u8 *info;
- info = kzalloc(PER_INFO_BYTE, GFP_KERNEL);
+ info = kzalloc(2 * PER_INFO_BYTE, GFP_KERNEL);
+ memset(info, 0xFD, 2 * PER_INFO_BYTE);
ret = meson_nfc_dma_buffer_setup(nand, buf, len, info,
PER_INFO_BYTE, DMA_FROM_DEVICE);
if (ret)
@@ -543,6 +544,12 @@ static int meson_nfc_read_buf(struct nand_chip *nand, u8 *buf, int len)
meson_nfc_drain_cmd(nfc);
meson_nfc_wait_cmd_finish(nfc, 1000);
meson_nfc_dma_buffer_release(nand, len, PER_INFO_BYTE, DMA_FROM_DEVICE);
+
+ for (i = 0; i < 2 * PER_INFO_BYTE; i++){
+ printk("0x%x ", info[i]);
+ }
+ printk("\n");
+
kfree(info);
return ret;
next prev parent reply other threads:[~2019-03-25 10:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 20:17 Martin Blumenstingl
2019-03-21 21:44 ` Matthew Wilcox
2019-03-22 21:07 ` Martin Blumenstingl
2019-03-25 10:04 ` Liang Yang [this message]
2019-03-25 18:31 ` Martin Blumenstingl
2019-03-27 8:53 ` Liang Yang
2019-03-28 18:03 ` Martin Blumenstingl
2019-03-29 7:44 ` Liang Yang
2019-04-05 4:30 ` Martin Blumenstingl
2019-04-10 11:08 ` Liang Yang
2019-04-10 17:54 ` Martin Blumenstingl
2019-04-11 3:00 ` Liang Yang
2019-06-08 20:00 ` Martin Blumenstingl
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=5cad2529-8776-687e-58d0-4fb9e2ec59b1@amlogic.com \
--to=liang.yang@amlogic.com \
--cc=akpm@linux-foundation.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=martin.blumenstingl@googlemail.com \
--cc=mhocko@suse.com \
--cc=rppt@linux.ibm.com \
--cc=willy@infradead.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