linux-kernel - Re: [PATCH] i2c: at91: use dma safe buffers

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: <b80f9ff0-9fc5-7cc5-fb67-1192f3375e7b@microchip.com>
Date:   Thu, 7 Apr 2022 11:50:31 +0000
From:   <Codrin.Ciubotariu@...rochip.com>
To:     <michael@...le.cc>
CC:     <Nicolas.Ferre@...rochip.com>, <alexandre.belloni@...tlin.com>,
        <Claudiu.Beznea@...rochip.com>, <sumit.semwal@...aro.org>,
        <christian.koenig@....com>, <linux-i2c@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>,
        <linaro-mm-sig@...ts.linaro.org>, <stable@...r.kernel.org>
Subject: Re: [PATCH] i2c: at91: use dma safe buffers

On 05.04.2022 17:08, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
> the content is safe
> 
> Am 2022-04-05 15:58, schrieb Codrin.Ciubotariu@...rochip.com:
>> On 05.04.2022 14:09, Michael Walle wrote:
>>> Am 2022-04-05 12:02, schrieb Codrin.Ciubotariu@...rochip.com:
>>>> On 05.04.2022 12:38, Michael Walle wrote:
>>>>> Am 2022-04-05 11:23, schrieb Codrin.Ciubotariu@...rochip.com:
>>>>>>> +       if (dev->use_dma) {
>>>>>>> +               dma_buf = i2c_get_dma_safe_msg_buf(m_start, 1);
>>>>>>
>>>>>> If you want, you could just dev->buf = i2c_get_dma_safe...
>>>>>
>>>>> But where is the error handling in that case? dev->buf will
>>>>> be NULL, which is eventually passed to dma_map_single().
>>>>>
>>>>> Also, I need the dma_buf for the i2c_put_dma_safe_msg_buf()
>>>>> call anyway, because dev->buf will be modified during
>>>>> processing.
>>>>
>>>> You still:
>>>>       if (!dev->buf) {
>>>>               ret = -ENOMEM;
>>>>               goto out;
>>>>       }
>>>>
>>>> So, at91_do_twi_transfer()/dma_map_single() will not be called.
>>>
>>> Ahh, I misunderstood you. Yes, but as I said, I need the dma_buf
>>> temporary variable anyway, because dev->buf is modified, eg. see
>>> at91_twi_read_data_dma_callback().
>> at91_twi_read_data_dma_callback() is called as callback if
>> dma_async_issue_pending(dma->chan_rx) is called.
>> dma_async_issue_pending(dma->chan_rx) is called on
>> at91_twi_read_data_dma(), which is called in at91_do_twi_transfer(),
>> which we decided above to skip in case of error.
> 
> It is not about errors, you need the exact same pointer you
> got from i2c_get_dma_safe_msg_buf() to be passed to
> i2c_put_dma_safe_msg_buf(). And because (in some cases, it
> isn't really obvious) the dev->buf will be advanced a few
> bytes, I cannot pass dev->buf to i2c_put_dma_safe_msg_buf().

You are right, when dev->use_dma && (dev->buf_len <= AT91_I2C_DMA_THRESHOLD)

got it. Thanks!

Best regards,
Codrin