public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] dmaengine: pl330: Check if the DMA descriptor is NULL
Date: Mon, 21 Jul 2014 10:22:05 +0200	[thread overview]
Message-ID: <53CCCDAD.5080001@metafoo.de> (raw)
In-Reply-To: <53CC032C.4000105@collabora.co.uk>

On 07/20/2014 07:58 PM, Javier Martinez Canillas wrote:
> Hello Lars-Peter,
>
> On 07/20/2014 04:18 PM, Lars-Peter Clausen wrote:
>> On 07/19/2014 03:21 AM, Javier Martinez Canillas wrote:
>>> Commit 6079d38 ("dmaengine: pl330: Remove useless xfer_cb indirection")
>>> removed the __callback() function which created an unnecessary level of
>>> indirection to execute the tranfer callback .xfer_cb
>>>
>>> Unfortunately the commit also changed the semantics slightly since that
>>> function used to check if the request was not NULL before attempting to
>>> execute the callback function. Not checking this could lead to a kernel
>>> NULL pointer dereference error.
>>
>> This should not happen, but I guess it can happen when terminal_all() is
>
> I should had mentioned before that this patch is not trying to fix a theoretical
> issue but a kernel oops when booting linux next-20140718 on a Exynos5420 SoC
> based Chromebook 2 machine.
>
> I'm sending as an attachment the complete kernel crash log but the problem
> happens when the spi_master .unprepare_transfer_hardware function handler in the
> spi-s3c64xx driver tries to release a DMA channel:
>
> s3c64xx_spi_unprepare_transfer() ->
> dma_release_channel() ->
> dma_chan_put() ->
> chan->device->device_free_chan_resources() ->
> pl330_free_chan_resources() ->
> pl330_release_channel() ->
> dma_pl330_rqcb()
>
>> called. (It's wrong to try to complete a descriptor from terminal_all() in
>> the first place, but that's a different issue)
>
> If this should not really happen and this patch is only a workaround since the
> bug is elsewhere, please give me some hints and I'll try to fix it properly. I'm
> not familiar with the PL330 DMA controller but just found what was the NULL
> pointer being dereferenced and looked at your changes to see what was different now.

I think the patch is fine as a quick workaround since it is simple and the 
previous commit broke previously working code.

The long term fix is to stop calling dma_pl330_rqcb() from 
pl330_release_channel(). The first thing is you wouldn't expect any transfer 
to be active when the channel is released. And even if it was by accident we 
should not call the descriptor callback, but rather but it just back onto 
the descriptor pool.

- Lars


  reply	other threads:[~2014-07-21  8:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-19  1:21 [PATCH 1/1] dmaengine: pl330: Check if the DMA descriptor is NULL Javier Martinez Canillas
2014-07-20 14:18 ` Lars-Peter Clausen
2014-07-20 17:58   ` Javier Martinez Canillas
2014-07-21  8:22     ` Lars-Peter Clausen [this message]
2014-07-21  8:44       ` Javier Martinez Canillas
2014-07-22 16:09 ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CCCDAD.5080001@metafoo.de \
    --to=lars@metafoo.de \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=javier.martinez@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox