linux-kernel - Re: [PATCH] dmatest: properly handle duplicate DMA channels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 20 Sep 2008 14:40:40 -0700
From:	"Dan Williams" <dan.j.williams@...el.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Timur Tabi" <timur@...escale.com>, haavard.skinnemoen@...el.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmatest: properly handle duplicate DMA channels

On Fri, Sep 19, 2008 at 4:31 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Thu, 18 Sep 2008 10:21:19 -0500
> Timur Tabi <timur@...escale.com> wrote:
>
>> --- a/drivers/dma/dmatest.c
>> +++ b/drivers/dma/dmatest.c
>> @@ -321,10 +321,15 @@ static void dmatest_cleanup_channel(struct dmatest_chan *dtc)
>>
>>  static enum dma_state_client dmatest_add_channel(struct dma_chan *chan)
>>  {
>> -     struct dmatest_chan     *dtc;
>> +     struct dmatest_chan     *dtc, *_dtc;
>>       struct dmatest_thread   *thread;
>>       unsigned int            i;
>>
>> +     /* Have we already been told about this channel? */
>> +     list_for_each_entry_safe(dtc, _dtc, &dmatest_channels, node)
>> +             if (dtc->chan == chan)
>> +                     return DMA_DUP;
>> +
>>       dtc = kmalloc(sizeof(struct dmatest_chan), GFP_ATOMIC);
>>       if (!dtc) {
>>               pr_warning("dmatest: No memory for %s\n", chan->dev.bus_id);
>
> hm.  A few lines after that GFP_ATOMIC the driver does a GFP_KERNEL
> allocation.
>
> One of them is incorrect.  The interface is undocumented (natch), but I
> assume that GFP_KERNEL is the one to use here.
>

The interface is documented, although not the locking (natch), at
include/linux/dmaengine.h:229.  When I fix this up is there a
canonical location to document a callback interface rather than at the
callback's typedef?

Thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/