From: David Daney <ddaney@caviumnetworks.com>
To: Manuel Lauss <manuel.lauss@googlemail.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>,
Manuel Lauss <manuel.lauss@gmail.com>
Subject: Re: [PATCH] MIPS: Alchemy: fix dbdma ring destruction memory debugcheck.
Date: Tue, 26 Jan 2010 10:45:42 -0800 [thread overview]
Message-ID: <4B5F3856.7020006@caviumnetworks.com> (raw)
In-Reply-To: <f861ec6f1001261040k79588f8fy9221ac31cdb3064b@mail.gmail.com>
Manuel Lauss wrote:
> David,
>
> On Tue, Jan 26, 2010 at 6:58 PM, Manuel Lauss
> <manuel.lauss@googlemail.com> wrote:
>> On Tue, Jan 26, 2010 at 6:44 PM, David Daney <ddaney@caviumnetworks.com> wrote:
>>> Manuel Lauss wrote:
>>>> DBDMA descriptors need to be located at 32-byte aligned addresses;
>>>> however kmalloc rarely delivers such addresses. The dbdma code
>>>> works around that by allocating 63 bytes and re-aligning the
>>>> descriptor base afterwards. Hoewever when freeing memory it does
>>>> not account for this adjustment and trips the kfree debugcheck:
>>>>
>>> Correct me if I am wrong, but don't kmalloc et al. return blocks aligned
>>> boundaries of the size rounded up the the next power of two? So if you
>>> need 32-byte aligned addresses, just use a size value of 32 or greater. You
>>> wouldn't have to add 63 and do masking and remember the membase value as you
>>> do in the patch.
>> The description is not completely correct (I suck a writing those):
>> It allocates a number
>> of descriptor entries (64 bytes each) specified by the driver in a single block:
>>
>> desc_base = (u32)kmalloc(entries * sizeof(au1x_ddma_desc_t),
>> GFP_KERNEL|GFP_DMA);
>> if (desc_base == 0)
>> return 0;
>>
>> if (desc_base & 0x1f) {
>>
>> So far the 3 users I have (mmc, spi, audio) always return true on the above
>> check (2 descriptors for audio for instance).
>
> ... but only if CONFIG_DEBUG_SLAB is enabled.
Oh no! I make this assumption in my drivers. If CONFIG_DEBUG_SLAB
causes it to not be true... Bad news.
David Daney
> You are correct in that
> kmalloc() returns aligned blocks with a non-debug slab allocator and this
> fix becomes superfluous. I'll try to confirm this with the other
> allocators and
> resend with a fixed description.
>
> Thank you for the pointer!
> Manuel Lauss
>
prev parent reply other threads:[~2010-01-26 18:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-26 17:34 [PATCH] MIPS: Alchemy: fix dbdma ring destruction memory debugcheck Manuel Lauss
2010-01-26 17:44 ` David Daney
2010-01-26 17:58 ` Manuel Lauss
2010-01-26 17:58 ` Manuel Lauss
2010-01-26 18:40 ` Manuel Lauss
2010-01-26 18:40 ` Manuel Lauss
2010-01-26 18:45 ` David Daney [this message]
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=4B5F3856.7020006@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=linux-mips@linux-mips.org \
--cc=manuel.lauss@gmail.com \
--cc=manuel.lauss@googlemail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.