linux-kernel - Re: [PATCH v1 1/2] at_hdmac: check and return DMA

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: <Y2pJJb6KwwcAMZw8@smile.fi.intel.com>
Date:   Tue, 8 Nov 2022 14:18:45 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Tudor.Ambarus@...rochip.com
Cc:     vkoul@...nel.org, Nicolas.Ferre@...rochip.com,
        linux-arm-kernel@...ts.infradead.org, dmaengine@...r.kernel.org,
        linux-kernel@...r.kernel.org, Ludovic.Desroches@...rochip.com
Subject: Re: [PATCH v1 1/2] at_hdmac: check and return DMA_PAUSED status when
 suitable

On Tue, Nov 08, 2022 at 11:50:19AM +0000, Tudor.Ambarus@...rochip.com wrote:
> On 11/8/22 09:49, Andy Shevchenko wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > device_tx_status() may return DMA_PAUSED status when driver supports it.
> 
> Yeah, but you haven't described the why. And that's because dma_cookie_status()
> currently considers just DMA_COMPLETE and DMA_IN_PROGRESS for the status of the
> cookie, so the controller drivers are forced to query the DMA_PAUSED state
> themselves.

At last without this change it's inconvenient and requires a lot of additional
(unneeded) code to be written by the caller. Moreover, it's racy. If you query
status twice in a raw, it may be well changed (for example from PAUSED to
IN_PROGRESS or COMPETE).

I will add a word summarizing this.

> Also, I noticed that Vinod prefers that you use the full paragraph in the commit
> message, and not a continuation of the patch title, so you may want to reword
> the commit message.

Yes, I will fix that.

...

> > +       if (!txstate) {
> > +               if (test_bit(ATC_IS_PAUSED, &atchan->status))
> 
> there's a helper function that you can use instead: atc_chan_is_paused()

Will use it.

> > +                       return DMA_PAUSED;
> > +               return DMA_ERROR;
> 
> return dma_status please

Will squash the patch.

> > +       }

...

> > +       if (test_bit(ATC_IS_PAUSED, &atchan->status))
> 
> The status may change after spin_unlock_irqrestore(). Should the residue
> be in sync with the dma status? If yes, you should check the status while
> holding the lock.

You should tell me actually. Because I'm a bit puzzled why we need a spin lock
_and_ atomic bit operations together.

> > +               dma_status = DMA_PAUSED;

...

Thank you for the review.

-- 
With Best Regards,
Andy Shevchenko