linux-kernel - Re: dmaengine.c: question about device_alloc_chan

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:	Thu, 18 Sep 2008 21:20:56 -0700
From:	"Dan Williams" <dan.j.williams@...el.com>
To:	"Haavard Skinnemoen" <haavard.skinnemoen@...el.com>
Cc:	"Timur Tabi" <timur@...escale.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: dmaengine.c: question about device_alloc_chan_resources

On Thu, Sep 18, 2008 at 7:45 AM, Haavard Skinnemoen
<haavard.skinnemoen@...el.com> wrote:
> Timur Tabi <timur@...escale.com> wrote:
>> Haavard Skinnemoen wrote:
>>
>> > Wouldn't it be better if the dmaengine layer made sure it didn't pass
>> > the same channel several times to a client?
>>
>> Wouldn't that require it to keep track of which clients have already seen which
>> channels?  It might make more sense, but it's probably easier the current way.
>
> I guess so. What would be even more simple is to simply prevent other
> clients from taking a channel once someone has acked it, which would be
> perfect for my purposes, but perhaps not everyone else's...

Does not seem too bad to have something like a DMA_EXCL flag in
dma_chan to tell the core not to show this channel to any other
clients.

>
> How common is for several clients to use the same channel anyway
> though? Wouldn't you risk stalling the network stack if the md subsystem
> has submitted a large xor operation on the same channel that the
> network stack was about to use?

It's analogous to running the network stack on the same cpu as md.
Yes, they effect each other but the operations are short-lived and can
interleave.  One potential problem could be bouncing the channel lock
across multiple cpu's.  This is mitigated if net_dma is changed to use
async_memcpy(), but it's not a priority.  iop_adma and mv_xor live on
single cpu platforms where net_dma is already turned off due to the
expense of get_user_pages().

--
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/