All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Adrian Larumbe <adrian.martinezlarumbe@imgtec.com>
Cc: dmaengine@vger.kernel.org, michal.simek@xilinx.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] xilinx_dma: Fix read-after-free bug when terminating transfers
Date: Wed, 14 Jul 2021 10:40:02 +0530	[thread overview]
Message-ID: <YO5xqrys1az1UDeP@matsya> (raw)
In-Reply-To: <20210706234338.7696-3-adrian.martinezlarumbe@imgtec.com>

On 07-07-21, 00:43, Adrian Larumbe wrote:
> When user calls dmaengine_terminate_sync, the driver will clean up any
> remaining descriptors for all the pending or active transfers that had
> previously been submitted. However, this might happen whilst the tasklet is
> invoking the DMA callback for the last finished transfer, so by the time it
> returns and takes over the channel's spinlock, the list of completed
> descriptors it was traversing is no longer valid. This leads to a
> read-after-free situation.
> 
> Fix it by signalling whether a user-triggered termination has happened by
> means of a boolean variable.

Applied after adding subsystem name, thanks

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Adrian Larumbe <adrian.martinezlarumbe@imgtec.com>
Cc: dmaengine@vger.kernel.org, michal.simek@xilinx.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] xilinx_dma: Fix read-after-free bug when terminating transfers
Date: Wed, 14 Jul 2021 10:40:02 +0530	[thread overview]
Message-ID: <YO5xqrys1az1UDeP@matsya> (raw)
In-Reply-To: <20210706234338.7696-3-adrian.martinezlarumbe@imgtec.com>

On 07-07-21, 00:43, Adrian Larumbe wrote:
> When user calls dmaengine_terminate_sync, the driver will clean up any
> remaining descriptors for all the pending or active transfers that had
> previously been submitted. However, this might happen whilst the tasklet is
> invoking the DMA callback for the last finished transfer, so by the time it
> returns and takes over the channel's spinlock, the list of completed
> descriptors it was traversing is no longer valid. This leads to a
> read-after-free situation.
> 
> Fix it by signalling whether a user-triggered termination has happened by
> means of a boolean variable.

Applied after adding subsystem name, thanks

-- 
~Vinod

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-14  5:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-06 23:43 [PATCH 0/2] Add support for MEMCPY_SG transfers Adrian Larumbe
2021-07-06 23:43 ` Adrian Larumbe
2021-07-06 23:43 ` [PATCH 1/2] dmaengine: xilinx_dma: Restore support for memcpy SG transfers Adrian Larumbe
2021-07-06 23:43   ` Adrian Larumbe
2021-07-14  4:58   ` Vinod Koul
2021-07-14  4:58     ` Vinod Koul
2021-07-26 22:14     ` Adrian Larumbe
2021-07-26 22:14       ` Adrian Larumbe
2021-07-29  4:19       ` Vinod Koul
2021-07-29  4:19         ` Vinod Koul
2021-07-06 23:43 ` [PATCH 2/2] xilinx_dma: Fix read-after-free bug when terminating transfers Adrian Larumbe
2021-07-06 23:43   ` Adrian Larumbe
2021-07-14  5:10   ` Vinod Koul [this message]
2021-07-14  5:10     ` Vinod Koul
2021-11-01 18:08 ` [PATCH 0/3] Add support for MEMCPY_SG transfers Adrian Larumbe
2021-11-01 18:08   ` Adrian Larumbe
2021-11-01 18:08   ` [PATCH 1/3] dmaengine: Add documentation for new memcpy scatter-gather function Adrian Larumbe
2021-11-01 18:08     ` Adrian Larumbe
2021-11-01 18:08   ` [PATCH 2/3] dmaengine: Add core function and capability check for DMA_MEMCPY_SG Adrian Larumbe
2021-11-01 18:08     ` Adrian Larumbe
2021-11-01 18:08   ` [PATCH 3/3] dmaengine: Add consumer for the new DMA_MEMCPY_SG API function Adrian Larumbe
2021-11-01 18:08     ` Adrian Larumbe
2021-11-02 10:33   ` [PATCH 0/3] Add support for MEMCPY_SG transfers Michal Simek
2021-11-02 10:33     ` Michal Simek
2021-11-22  6:08   ` Vinod Koul
2021-11-22  6:08     ` 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=YO5xqrys1az1UDeP@matsya \
    --to=vkoul@kernel.org \
    --cc=adrian.martinezlarumbe@imgtec.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=michal.simek@xilinx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.