On 25/09/15 20:06, Jon Hunter wrote:
> On 25/09/15 07:58, Christopher Freeman wrote:
>> On 09-24 10:24 AM, Jon Hunter wrote:
[snip]
>>>> diff --git a/drivers/tty/serial/serial-tegra.c b/drivers/tty/serial/serial-tegra.c
>>>> index cf0133a..f9bd378 100644
>>>> --- a/drivers/tty/serial/serial-tegra.c
>>>> +++ b/drivers/tty/serial/serial-tegra.c
>>>> @@ -606,12 +606,6 @@ static void tegra_uart_rx_dma_complete(void *args)
>>>> tegra_uart_copy_rx_to_tty(tup, port, count);
>>>>
>>>> tegra_uart_handle_rx_pio(tup, port);
>>>> - if (tty) {
>>>> - spin_unlock_irqrestore(&u->lock, flags);
>>>> - tty_flip_buffer_push(port);
>>>> - spin_lock_irqsave(&u->lock, flags);
>>>> - tty_kref_put(tty);
>>>> - }
>>>> tegra_uart_start_rx_dma(tup);
>>>
>>> With this change, tegra_uart_start_rx_dma() is called within the context
>>> of the spinlock (I am sure this is intentional). However,
>>> tegra_uart_start_rx_dma() calls dmaengine_prep_slave_single() and this
>>> calls tegra_dma_prep_slave_sg(). The problem is that
>>> tegra_dma_prep_slave_sg() *may* call kzalloc() to allocate memory. The
>>> allocation only happens if there is not a free dma descriptor available
>>> and if tegra_dma_prep_slave_sg() has been called once, you may get lucky.
>>>
>> This has been the case before this change so we've been getting lucky a lot.
>> Noted though.
>
> Ah, yes you are right. Hmmm ... does not seem good.
Sorry, I am completely wrong here. Although tegra_dma_prep_slave_sg()
may call kzalloc() it does so with GFP_ATOMIC set. So we are ok.
Anyway, per our off-line discussions I will send out the alternative fix
that we have discussed.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
