linux-toradex.git/drivers/dma, branch v3.2.68

dma: mv_xor: Flush descriptors before activating a channel

2014-06-09T12:29:15+00:00

commit 5a9a55bf9157d3490b0c8c4c81d4708602c26e07 upstream.

We need to use writel() instead of writel_relaxed() when starting
a channel, to ensure all the descriptors have been flushed before
the activation.

While at it, remove the unneeded read-modify-write and make the
code simpler.

Signed-off-by: Lior Amsalem 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Dan Williams 
[bwh: Backported to 3.2: it was using __raw_readl() and __raw_writel()
 which are just as wrong]
Signed-off-by: Ben Hutchings

ioat: fix tasklet tear down

2014-04-01T23:58:55+00:00

commit da87ca4d4ca101f177fffd84f1f0a5e4c0343557 upstream.

Since commit 77873803363c "net_dma: mark broken" we no longer pin dma
engines active for the network-receive-offload use case.  As a result
the ->free_chan_resources() that occurs after the driver self test no
longer has a NET_DMA induced ->alloc_chan_resources() to back it up.  A
late firing irq can lead to ksoftirqd spinning indefinitely due to the
tasklet_disable() performed by ->free_chan_resources().  Only
->alloc_chan_resources() can clear this condition in affected kernels.

This problem has been present since commit 3e037454bcfa "I/OAT: Add
support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the
NET_DMA use case is deprecated we can revisit moving the driver to use
threaded irqs.  For now, just tear down the irq and tasklet properly by:

1/ Disable the irq from triggering the tasklet

2/ Disable the irq from re-arming

3/ Flush inflight interrupts

4/ Flush the timer

5/ Flush inflight tasklets

References:
https://lkml.org/lkml/2014/1/27/282
https://lkml.org/lkml/2014/2/19/672

Cc: Ingo Molnar 
Cc: Steven Rostedt 
Reported-by: Mike Galbraith 
Reported-by: Stanislav Fomichev 
Tested-by: Mike Galbraith 
Tested-by: Stanislav Fomichev 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Dan Williams 
[bwh: Backported to 3.2:
 - Adjust context
 - As there is no ioatdma_device::irq_mode member, check
   pci_dev::msix_enabled instead]
Signed-off-by: Ben Hutchings 
Acked-by: Dan Williams

dma: ste_dma40: don't dereference free:d descriptor

2014-04-01T23:58:53+00:00

commit e9baa9d9d520fb0e24cca671e430689de2d4a4b2 upstream.

It appears that in the DMA40 driver the DMA tasklet will very
often dereference memory for a descriptor just free:d from the
DMA40 slab. Nothing happens because no other part of the driver
has yet had a chance to claim this memory, but it's really
nasty to dereference free:d memory, so let's check the flag
before the descriptor is free and store it in a bool variable.

Reported-by: Dan Carpenter 
Signed-off-by: Linus Walleij 
Signed-off-by: Vinod Koul 
Signed-off-by: Ben Hutchings

net_dma: mark broken

2014-02-15T19:20:14+00:00

commit 77873803363c9e831fc1d1e6895c084279090c22 upstream.

net_dma can cause data to be copied to a stale mapping if a
copy-on-write fault occurs during dma.  The application sees missing
data.

The following trace is triggered by modifying the kernel to WARN if it
ever triggers copy-on-write on a page that is undergoing dma:

 WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120()
 ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9]
 Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca
 CPU: 24 PID: 2529 Comm: linbug Tainted: G        W    3.13.0-rc1+ #353
  00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70
  ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646
  ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349
 Call Trace:
  [] dump_stack+0x46/0x58
  [] warn_slowpath_common+0x8c/0xc0
  [] ? ftrace_pid_func+0x26/0x30
  [] warn_slowpath_fmt+0x46/0x50
  [] debug_dma_assert_idle+0xd2/0x120
  [] do_wp_page+0xd0/0x790
  [] handle_mm_fault+0x51c/0xde0
  [] ? copy_user_enhanced_fast_string+0x9/0x20
  [] __do_page_fault+0x19c/0x530
  [] ? _raw_spin_lock_bh+0x16/0x40
  [] ? trace_clock_local+0x9/0x10
  [] ? rb_reserve_next_event+0x64/0x310
  [] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma]
  [] do_page_fault+0xe/0x10
  [] page_fault+0x22/0x30
  [] ? __kfree_skb+0x51/0xd0
  [] ? copy_user_enhanced_fast_string+0x9/0x20
  [] ? memcpy_toiovec+0x52/0xa0
  [] skb_copy_datagram_iovec+0x5f/0x2a0
  [] tcp_rcv_established+0x674/0x7f0
  [] tcp_v4_do_rcv+0x2e5/0x4a0
  [..]
 ---[ end trace e30e3b01191b7617 ]---
 Mapped at:
  [] debug_dma_map_page+0xb9/0x160
  [] dma_async_memcpy_pg_to_pg+0x127/0x210
  [] dma_memcpy_pg_to_iovec+0x119/0x1f0
  [] dma_skb_copy_datagram_iovec+0x11c/0x2b0
  [] tcp_rcv_established+0x74a/0x7f0:

...the problem is that the receive path falls back to cpu-copy in
several locations and this trace is just one of the areas.  A few
options were considered to fix this:

1/ sync all dma whenever a cpu copy branch is taken

2/ modify the page fault handler to hold off while dma is in-flight

Option 1 adds yet more cpu overhead to an "offload" that struggles to compete
with cpu-copy.  Option 2 adds checks for behavior that is already documented as
broken when using get_user_pages().  At a minimum a debug mode is warranted to
catch and flag these violations of the dma-api vs get_user_pages().

Thanks to David for his reproducer.

Cc: Dave Jiang 
Cc: Vinod Koul 
Cc: Alexander Duyck 
Reported-by: David Whipple 
Acked-by: David S. Miller 
Signed-off-by: Dan Williams 
Signed-off-by: Ben Hutchings

drivers/dma/pl330.c: fix locking in pl330_free_chan_resources()

2013-07-27T04:34:27+00:00

commit da331ba8e9c5de72a27e50f71105395bba6eebe0 upstream.

tasklet_kill() may sleep so call it before taking pch->lock.

Fixes following lockup:

  BUG: scheduling while atomic: cat/2383/0x00000002
  Modules linked in:
    unwind_backtrace+0x0/0xfc
    __schedule_bug+0x4c/0x58
    __schedule+0x690/0x6e0
    sys_sched_yield+0x70/0x78
    tasklet_kill+0x34/0x8c
    pl330_free_chan_resources+0x24/0x88
    dma_chan_put+0x4c/0x50
  [...]
  BUG: spinlock lockup suspected on CPU#0, swapper/0/0
   lock: 0xe52aa04c, .magic: dead4ead, .owner: cat/2383, .owner_cpu: 1
    unwind_backtrace+0x0/0xfc
    do_raw_spin_lock+0x194/0x204
    _raw_spin_lock_irqsave+0x20/0x28
    pl330_tasklet+0x2c/0x5a8
    tasklet_action+0xfc/0x114
    __do_softirq+0xe4/0x19c
    irq_exit+0x98/0x9c
    handle_IPI+0x124/0x16c
    gic_handle_irq+0x64/0x68
    __irq_svc+0x40/0x70
    cpuidle_wrap_enter+0x4c/0xa0
    cpuidle_enter_state+0x18/0x68
    cpuidle_idle_call+0xac/0xe0
    cpu_idle+0xac/0xf0

Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Kyungmin Park 
Acked-by: Jassi Brar 
Cc: Vinod Koul 
Cc: Tomasz Figa 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

pch_dma: Use GFP_ATOMIC because called from interrupt context

2013-05-30T13:35:09+00:00

commit 5c1ef59168c485318e40ba485c1eba57d81d0faa upstream.

pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver "pch_uart.c").
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.

Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Vinod Koul 
Signed-off-by: Ben Hutchings

ioat: Fix DMA memory sync direction correct flag

2013-02-06T04:33:23+00:00

commit ac4989874af56435c308bdde9ad9c837a26f8b23 upstream.

ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated
for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug.
Fixed the dma_sync_single_for_device() call to use the correct direction.

[  226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550()
[  226.288948] Hardware name: ProLiant DL380p Gen8
[  226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE]
[  226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod
[  226.288967] Pid: 1055, comm: work_for_cpu Tainted: G        W    3.3.0-0.20.el7.x86_64 #1
[  226.288968] Call Trace:
[  226.288974]  [] warn_slowpath_common+0x7f/0xc0
[  226.288977]  [] warn_slowpath_fmt+0x46/0x50
[  226.288980]  [] check_sync+0x132/0x550
[  226.288983]  [] debug_dma_sync_single_for_device+0x3f/0x50
[  226.288988]  [] ? wait_for_common+0x72/0x180
[  226.288995]  [] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma]
[  226.288999]  [] ? kfree+0x259/0x270
[  226.289004]  [] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
[  226.289008]  [] ioat_probe+0x2f8/0x348 [ioatdma]
[  226.289011]  [] ioat3_dma_probe+0x1d5/0x2aa [ioatdma]
[  226.289016]  [] ioat_pci_probe+0x139/0x17c [ioatdma]
[  226.289020]  [] local_pci_probe+0x5c/0xd0
[  226.289023]  [] ? destroy_work_on_stack+0x20/0x20
[  226.289025]  [] do_work_for_cpu+0x18/0x30
[  226.289029]  [] kthread+0xb7/0xc0
[  226.289033]  [] kernel_thread_helper+0x4/0x10
[  226.289036]  [] ? _raw_spin_unlock_irq+0x30/0x50
[  226.289038]  [] ? retint_restore_args+0x13/0x13
[  226.289041]  [] ? kthread_worker_fn+0x1a0/0x1a0
[  226.289044]  [] ? gs_change+0x13/0x13
[  226.289045] ---[ end trace e1618afc7a606089 ]---
[  226.289047] Mapped at:
[  226.289048]  [] debug_dma_map_page+0x87/0x150
[  226.289050]  [] dma_map_page.constprop.18+0x70/0xb34 [ioatdma]
[  226.289054]  [] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma]
[  226.289058]  [] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
[  226.289061]  [] ioat_probe+0x2f8/0x348 [ioatdma]

Signed-off-by: Shuah Khan 
Signed-off-by: Vinod Koul 
Signed-off-by: Ben Hutchings

drivers/dma/dmaengine.c: lower the priority of 'failed to get' dma channel message

2012-10-17T02:49:34+00:00

commit 0eb5a35801df3c438ce3fc91310a415ea4452c00 upstream.

Do the same as commit a03a202e95fd ("dmaengine: failure to get a
specific DMA channel is not critical") to get rid of the following
messages during kernel boot:

  dmaengine_get: failed to get dma1chan0: (-22)
  dmaengine_get: failed to get dma1chan1: (-22)
  dmaengine_get: failed to get dma1chan2: (-22)
  dmaengine_get: failed to get dma1chan3: (-22)
  ..

Signed-off-by: Fabio Estevam 
Cc: Vinod Koul 
Cc: Dan Williams 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: also apply changes to this logging statement
 from commit 634332502366 ('dmaengine: Cleanup logging messages')]
Signed-off-by: Ben Hutchings

DMA: PL330: Check the pointer returned by kzalloc

2012-10-10T02:30:56+00:00

commit 61c6e7531d3b66b33187b8cdd700fd8ab93ffd62 upstream.

kzalloc could return NULL. Hence add a check to avoid
NULL pointer dereference.

Signed-off-by: Sachin Kamat 
Acked-by: Jassi Brar 
Signed-off-by: Vinod Koul 
[bwh: Backported to 3.2: adjust context and error label]
Signed-off-by: Ben Hutchings

dmaengine: at_hdmac: check that each sg data length is non-null

2012-10-10T02:30:53+00:00

commit c456797681db814f4f5b36909e8e94047bf53d9c upstream.

Avoid the construction of a malformed DMA request sent to
the DMA controller.
Log message is for debug only because this condition is unlikely to
append and may only trigger at driver development time.

Signed-off-by: Nicolas Ferre 
Signed-off-by: Vinod Koul 
Signed-off-by: Ben Hutchings