linux-kernel - DMA Engine API usage

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>] [day] [month] [year] [list]

Message-ID: <g2h121039231004130155j70b61dedl6b07f149157fe48f@mail.gmail.com>
Date:	Tue, 13 Apr 2010 14:25:11 +0530
From:	melwyn lobo <linux.melwyn@...il.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	"linux-arm-kernel@...ts.infradead.org\"
	<linux-arm-kernel@...ts.infradead.org>, linux-kernel@...r.kernel.org\"" 
	<linux-kernel@...r.kernel.org>
Subject: DMA Engine API usage

Hello Dan,
I have some doubts regarding DMA API usage on its clients for example
MMC, ALSA, USB etc.

I am going to take example of the ALSA framework. Audio data transfer
is initiated in soc_pcm_trigger(). This is called in an atomic
context,
with spinlock held and irqs disabled. Here most drivers enable data
transfer from the MSP peripheral to the audio codec via tx_submit
implementation
of the DMA engine driver. This enqueues the transaction in an active
list which calls for using spinlocks with bottom half disabled.
It is in this function when spin_unlock_bh() is called the kernel
detects irq's disabled and generates a warning.
So the workaround here for ALSA drivers would be to use tasklet or
workqueues to defer calling this in an interruptible context, which
would
cause performance problems (the same function soc_pcm_trigger is
called for stoppping the transfer) in cases where the stream has to be
repeatedly
stopped and started.

So the core issue is use of spin_unlock_bh in an atomic context.
Workaround for removing the warnings would be:
1. Use spin_lock with irqsave and corresponding unlock function which
does not generate a warning in a similar situation.
   But this could be futile in one case where the tasklet is scheduled
from ksoftirqd which could lead to corruption.
   Also this means the interrupts would be disabled (on the local cpu)
till the function executed which is not something
   desirable.
2. Use local_irq_enable() before calling the DMA APIs and disable once
done. This is a crude solution and understandably undesirable and
dangerous.

The DMA Engine framework assumes that the channel interrupt handling
is done in a tasklet (dma_run_dependencies), which I believe is the
reason for the issue.

Regards,
M.
--
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/