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-next>] [day] [month] [year] [list]
Message-Id: <1412767415-6624-1-git-send-email-srinivas.kandagatla@linaro.org>
Date:	Wed,  8 Oct 2014 12:23:35 +0100
From:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:	linux-mmc@...r.kernel.org
Cc:	Chris Ball <chris@...ntf.net>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: [RFC PATCH 0/2] mmc: Fix prepared resource handling at bkops

Hi All,

During recent eMMC stress testing on IFC6410 board we always hit below crash in few mins.

Initial investigations showed that the mmci driver gets confused sometimes when
handling CMD8 as part of blkops request. The reason looks straight forward,
mmci driver caches the dma descriptor and channel for the prepared request,
so if a new blocking request like CMD8 arrives, it would think that the request
is already prepared as dma_desc_current and dma_current looks valid. As a result
the driver does not prepare the dma channel for CMD8, so at the end the driver
notices that fifo has still some bytes and driver crashes. 

Also the problem seems to be partly in the core as well, which is sending a
blocking command after preparing another request.

These two patches changes the way the prepared request is handled in the core during bkops.
After applying these two patches I see no crashes.

Am not sure if someone else encountered such issue, also I would like to know your opinion
on the overall approach of fixing this issue.

  
    mmci-pl18x 12400000.sdcc: error during DMA transfer!
    Unable to handle kernel paging request at virtual address 40000000
    pgd = c0204000
    [40000000] *pgd=00000000
    Internal error: Oops: 805 [#1] SMP ARM
    Modules linked in: ipv6 ath6kl_sdio ath6kl_core
    CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W      3.17.0-rc7-linaro-multi-v7 #1
    task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000
    PC is at v7_dma_inv_range+0x34/0x4c
    LR is at __dma_page_dev_to_cpu+0x80/0x100
    pc : [<c021efc0>]    lr : [<c021af18>]    psr: 400f0193
    sp : c0c93e20  ip : c0c9a478  fp : c08ea538
    r10: c0c9f548  r9 : 00000002  r8 : e97d9000
    r7 : 00000200  r6 : c0c9d504  r5 : c0db0880  r4 : 00000000
    r3 : 0000003f  r2 : 00000040  r1 : 40000200  r0 : 40000000
    Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    Control: 10c5787d  Table: a9ef406a  DAC: 00000015
    Process swapper/0 (pid: 0, stack limit = 0xc0c92250)
    Stack: (0xc0c93e20 to 0xc0c94000)
    3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002
    3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4
    3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534
    3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080
    3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc
    3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190
    3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080
    3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff
    3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
    3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
    3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44
    3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38
    3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4
    3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c
    3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000
    [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100)
    [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84)
    [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74)
    [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c)
    [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114)
    [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134)
    [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64)
    [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8)
    [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c)
    [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90)
    [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68)
    [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54)
    Exception stack(0xc0c93f28 to 0xc0c93f70)
    3f20:                   00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
    3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
    3f60: c04bd630 c04bd5bc 200f0013 ffffffff
    [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c)
    [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c)
    [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0)
    [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238)
    [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390)
    Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36)
    ---[ end trace cf6cb3f6432c9834 ]---
    Kernel panic - not syncing: Fatal exception in interrup

--srini

Srinivas Kandagatla (2):
  mmc: core: fix prepared requests while doing bkops
  mmc: mmci: fix mmci_post_request

 drivers/mmc/core/core.c | 12 +++++++++++-
 drivers/mmc/host/mmci.c |  7 +++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

-- 
1.9.1

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ