linux-kernel - Re: [RFC PATCH 0/2] mmc: Fix prepared resource handling at bkops

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] [day] [month] [year] [list]
Message-ID: <CAPDyKFohtJCWaG272gt08WFd1BafBX5DTfJtNM9Gz7okNs7D+g@mail.gmail.com>
Date:	Mon, 27 Oct 2014 14:01:25 +0100
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:	linux-mmc <linux-mmc@...r.kernel.org>,
	Chris Ball <chris@...ntf.net>,
	Russell King <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/2] mmc: Fix prepared resource handling at bkops

On 8 October 2014 13:23, Srinivas Kandagatla
<srinivas.kandagatla@...aro.org> wrote:
> 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
>

Thanks! Applied for next!

I also fixed a minor misspelling in commit messages for which
checkpatch complained about.

Kind regards
Uffe
--
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/