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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 6 Feb 2009 15:52:35 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	David Miller <davem@...emloft.net>
Cc:	anemo@....ocn.ne.jp, maciej.sosnowski@...el.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] net_dma: call dmaengine_get only if NET_DMA enabled

On Fri, Feb 6, 2009 at 3:09 PM, David Miller <davem@...emloft.net> wrote:
> From: Dan Williams <dan.j.williams@...el.com>
> Date: Fri, 6 Feb 2009 14:15:02 -0700
>
>> [ please cc netdev on net_dma patches ]
>>
>> On Fri, Feb 6, 2009 at 9:02 AM, Atsushi Nemoto <anemo@....ocn.ne.jp> wrote:
>> > The commit 649274d993212e7c23c0cb734572c2311c200872 ("net_dma:
>> > acquire/release dma channels on ifup/ifdown") added unconditional call
>> > of dmaengine_get() to net_dma.  The API should be called only if
>> > NET_DMA was enabled.
>> >
>> > Signed-off-by: Atsushi Nemoto <anemo@....ocn.ne.jp>
>>
>> Acked-by: Dan Williams <dan.j.williams@...el.com>
>>
>> I was looking to avoid ifdefs in this path by making
>> dmaengine_{get,put} a nop in the DMAENGINE=n case.  However, the
>> current code with DMAENGINE=y NET_DMA=n will pin channels even though
>> the network stack is not using them.
>
> I don't want to apply this patch at all.
>
> What is the purpose of keeping the ugly ifdefs in dmaengine.h if we're
> just going to pollute the networking code with the ifdefs anyways?
>
> Make the NOP versions in linux/dmaengine.h actually work.
>
> The NET_DMA stuff is the one thing which is polluting up the networking
> stack with ugly ifdefs, I'm not adding new ones.

Yes, it has been on the todo list for a while, but I eventually want
the net case to look more like the raid case.  I.e. have one code path
that picks async versus sync at runtime, with the option to compile
out async support with header file ifdefs only.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ