linux-kernel - Re: [PATCH 8/8] serial: tegra: Correct error handling on DMA setup

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 May 2015 10:51:33 +0100
From:	Jon Hunter <jonathanh@...dia.com>
To:	Alexandre Courbot <gnurou@...il.com>
CC:	Laxman Dewangan <ldewangan@...dia.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>, <linux-serial@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 8/8] serial: tegra: Correct error handling on DMA setup


On 12/05/15 09:39, Alexandre Courbot wrote:
> On Tue, May 5, 2015 at 11:17 PM, Jon Hunter <jonathanh@...dia.com> wrote:
>> Function tegra_uart_dma_channel_allocate() does not check that
>> dma_map_single() mapped the DMA buffer correctly. Add a check for this
>> and appropriate error handling.
>>
>> Furthermore, if dmaengine_slave_config() (called by
>> tegra_uart_dma_channel_allocate()) fails, then memory allocated/mapped
>> is not freed/unmapped. Therefore, call tegra_uart_dma_channel_free()
>> instead of just dma_release_channel() if  dmaengine_slave_config() fails.
>>
>> Signed-off-by: Jon Hunter <jonathanh@...dia.com>
>> ---
>>  drivers/tty/serial/serial-tegra.c | 51 +++++++++++++++++++++------------------
>>  1 file changed, 28 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/tty/serial/serial-tegra.c b/drivers/tty/serial/serial-tegra.c
>> index 96378da9aefc..3b63f103f0c9 100644
>> --- a/drivers/tty/serial/serial-tegra.c
>> +++ b/drivers/tty/serial/serial-tegra.c
>> @@ -949,6 +949,28 @@ static int tegra_uart_hw_init(struct tegra_uart_port *tup)
>>         return 0;
>>  }
>>
>> +static void tegra_uart_dma_channel_free(struct tegra_uart_port *tup,
>> +               bool dma_to_memory)
>> +{
>> +       if (dma_to_memory) {
>> +               dmaengine_terminate_all(tup->rx_dma_chan);
>> +               dma_release_channel(tup->rx_dma_chan);
>> +               dma_free_coherent(tup->uport.dev, TEGRA_UART_RX_DMA_BUFFER_SIZE,
>> +                               tup->rx_dma_buf_virt, tup->rx_dma_buf_phys);
>> +               tup->rx_dma_chan = NULL;
>> +               tup->rx_dma_buf_phys = 0;
>> +               tup->rx_dma_buf_virt = NULL;
>> +       } else {
>> +               dmaengine_terminate_all(tup->tx_dma_chan);
>> +               dma_release_channel(tup->tx_dma_chan);
>> +               dma_unmap_single(tup->uport.dev, tup->tx_dma_buf_phys,
>> +                       UART_XMIT_SIZE, DMA_TO_DEVICE);
>> +               tup->tx_dma_chan = NULL;
>> +               tup->tx_dma_buf_phys = 0;
>> +               tup->tx_dma_buf_virt = NULL;
>> +       }
>> +}
>> +
>>  static int tegra_uart_dma_channel_allocate(struct tegra_uart_port *tup,
>>                         bool dma_to_memory)
>>  {
>> @@ -981,6 +1003,11 @@ static int tegra_uart_dma_channel_allocate(struct tegra_uart_port *tup,
>>                 dma_phys = dma_map_single(tup->uport.dev,
>>                         tup->uport.state->xmit.buf, UART_XMIT_SIZE,
>>                         DMA_TO_DEVICE);
>> +               if (dma_mapping_error(tup->uport.dev, dma_phys)) {
>> +                       dev_err(tup->uport.dev, "dma_map_single tx failed\n");
>> +                       dma_release_channel(dma_chan);
>> +                       return -ENOMEM;
> 
> Is -ENOMEM the error code we want to return here?

I think that it is appropriate as we are unable to map the memory we are
requesting. I did look at a few other drivers and several return -ENOMEM
here. I saw others return -EFAULT, but given this is memory related,
seems ok, unless you have a better suggestion.

> IIUC dma_buf will be leaked if an error occurs here because it has not
> been assigned to your structure and will therefore be ignored when
> tegra_uart_dma_channel_free() is called.

In the original code, if dmaengine_slave_config() failed, then yes there
would be a memory leak. That should no longer be the case.

> Since we have a "scrub" label at the end of this function, I think I'd
> also prefer if this block and the one before could jump to error
> labels as well for consistency.

Yes I see. I wondered if it would be better to just get rid of the
"scrub" label since it is only used in one place instead?

By the way, I got a notification from Greg that these are now queued in
his tty-testing branch [1]. Assuming these are ok, may be I could fix
that up in a follow-up patch?

> Otherwise, pretty nice series, comprehensive and easy to read.

Thanks!
Jon

[1]
http://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/log/?h=tty-testing

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