From: Jiri Slaby <jirislaby@kernel.org>
To: Dave Jiang <dave.jiang@intel.com>, vkoul@kernel.org
Cc: Swathi Kovvuri <swathi.kovvuri@intel.com>,
peter.ujfalusi@ti.com,
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] dmaengine: check device and channel list for empty
Date: Thu, 9 Jul 2020 07:35:36 +0200 [thread overview]
Message-ID: <852318ec-9e18-3dee-a91d-1cf4dddb8906@kernel.org> (raw)
In-Reply-To: <b9e8f171-6961-b483-c698-18a89e58f361@intel.com>
On 07. 07. 20, 17:42, Dave Jiang wrote:
> On 7/6/2020 11:05 PM, Jiri Slaby wrote:
>> On 26. 06. 20, 20:09, Dave Jiang wrote:
>>> Check dma device list and channel list for empty before iterate as the
>>> iteration function assume the list to be not empty. With devices and
>>> channels now being hot pluggable this is a condition that needs to be
>>> checked. Otherwise it can cause the iterator to spin forever.
>>
>> Could you be a little bit more specific how this can spin forever? I.e.
>> can you attach a stacktrace of such a behaviour?
>
> I can't seem to find the original splat that lead me to the conclusion
> of it's spinning forever. As I recall, the issue seems to produce
> different splats and not always consistent in being reproduced. Here's a
> partial splat that was tracked by the internal bug database. Since with
> the dma device and channel list being are hot added and removed, the
> device and channel lists can be empty. The list_entry() and friends
> expect the list to not be empty (according to header comment), I added
> the check to ensure that isn't the case before using them in dmaengine.
Yes, the comment states that as it is true: you receive a
wild/non-checkable pointer if you do list_entry on an empty list. BUT
have you actually read what I wrote:
>> As in the empty case, "&pos->member" is "head" (look into
>> list_for_each_entry) and the for loop should loop exactly zero times.
HERE ^^^^
> With the fix, we can no longer produce any of the splats. So maybe the
> above was a bad description of the issue.
No, not only the description, worse, the patch proper looks wrong.
> [ 4216.048375] ? dma_channel_rebalance+0x7b/0x250
> [ 4216.056360] dma_async_device_register+0x349/0x3a0
> [ 4216.064604] idxd_register_dma_device+0x90/0xc0 [idxd]
> [ 4216.073175] idxd_config_bus_probe.cold+0x7d/0x1fc [idxd]
So, the good part in the patch is the fixed locking in
dma_async_device_register. Otherwise it adds nonsense checks. So you
fixed the issue only by a chance, by a side effect as Peter pointed out.
Leaving aside that you broke dma_request_chan -- that could happen to
anybody.
Vinod, please drop/revert this patch. Then start over only with
dma_async_device_register fixed locking.
thanks,
--
js
next prev parent reply other threads:[~2020-07-09 5:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <159319496403.69045.16298280729899651363.stgit@djiang5-desk3.ch.intel.com>
2020-07-07 6:05 ` [PATCH v2] dmaengine: check device and channel list for empty Jiri Slaby
2020-07-07 8:50 ` Peter Ujfalusi
2020-07-07 15:45 ` Dave Jiang
2020-07-07 15:42 ` Dave Jiang
2020-07-09 5:35 ` Jiri Slaby [this message]
2020-07-09 15:23 ` Dave Jiang
2020-07-13 9:24 ` 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=852318ec-9e18-3dee-a91d-1cf4dddb8906@kernel.org \
--to=jirislaby@kernel.org \
--cc=dave.jiang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=swathi.kovvuri@intel.com \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox