From: <Tudor.Ambarus@microchip.com>
To: <regressions@leemhuis.info>, <peda@axentia.se>,
<Nicolas.Ferre@microchip.com>, <alexandre.belloni@bootlin.com>
Cc: <du@axentia.se>, <Patrice.Vilchez@microchip.com>,
<Cristian.Birsan@microchip.com>,
<Ludovic.Desroches@microchip.com>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<gregkh@linuxfoundation.org>, <saravanak@google.com>
Subject: Re: Regression: memory corruption on Atmel SAMA5D31
Date: Mon, 11 Apr 2022 06:21:24 +0000 [thread overview]
Message-ID: <4a1e8827-1ff0-4034-d96e-f561508df432@microchip.com> (raw)
In-Reply-To: <0879d887-6558-bb9f-a1b9-9220be984380@leemhuis.info>
On 4/9/22 16:02, Thorsten Leemhuis wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
>
> Can somebody please provide a status update what the outcome of this
> thread? It started as a regression report, that's why I'm tracking it --
Hi, Thorsten,
There are some concurrency bugs in the at-hdmac (DMA) driver, I'm handling them
and will come with a resolution. Disabling the DMA showed the bug is no more
reproducible.
> but seems nothing happened for a while. Was it fixed? Did it fall
> through the cracks? Or did it turn out that this is not a regression? If
Not yet sure if it's a regression or not, as the bugs are there since the
beginning. Maybe they are just harder to reproduce.
> the latter: please feel free to include a paragraph like "#regzbot
> invalid: a few words why this is invalid in the lengths of a mail subject"
>
Will come with a follow up after I fix the DMA bugs.
Cheers,
ta
> Ciao, Thorsten
>
> #regzbot poke
>
> On 10.03.22 11:40, Peter Rosin wrote:
>> On 2022-03-10 10:58, Peter Rosin wrote:
>>> [bringing this threadlet back to the lists, hope that's ok]
>>>
>>> On 2022-03-10 09:27, Nicolas Ferre wrote:
>>>> From that article:
>>>> https://lwn.net/Articles/885941/
>>>>
>>>> I read:
>>>>
>>>> "Koschel included a patch fixing a bug in the USB subsystem where the
>>>> iterator passed to this macro was used after the exit from the macro,
>>>> which is a dangerous thing to do. Depending on what happens within the
>>>> list, the contents of that iterator could be something surprising, even
>>>> in the absence of speculative execution. Koschel fixed the problem by
>>>> reworking the code in question to stop using the iterator after the loop. "
>>>>
>>>> USB subsystem, "struct list_head *next, *prev;"... Some keywords present
>>>> there... worth a try?
>>>>
>>>> Regards,
>>>> Nicolas
>>>
>>> gr_udc.c is not built with the config that is in use, which is sad because
>>> it looked like a good candidate.
>>
>> at91_usba_udc.c, which is included, has the same pattern. But alas, doing
>> the equivalent patch there does not fix things either. I.e. (whitespace
>> damaged)
>>
>> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> @@ -863,6 +863,7 @@ static int usba_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
>> struct usba_request *req;
>> unsigned long flags;
>> u32 status;
>> + bool found = false;
>>
>> DBG(DBG_GADGET | DBG_QUEUE, "ep_dequeue: %s, req %p\n",
>> ep->ep.name, _req);
>> @@ -870,11 +871,13 @@ static int usba_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
>> spin_lock_irqsave(&udc->lock, flags);
>>
>> list_for_each_entry(req, &ep->queue, queue) {
>> - if (&req->req == _req)
>> + if (&req->req == _req) {
>> + found = true;
>> break;
>> + }
>> }
>>
>> - if (&req->req != _req) {
>> + if (!found) {
>> spin_unlock_irqrestore(&udc->lock, flags);
>> return -EINVAL;
>> }
>>
>> The test started out with 3 good hashes though, so I got my hopes up. But
>> no, it's about the same failure rate as usual. I have the feeling that I
>> will never again trust a single sha256sum...
>>
>> Cheers,
>> Peter
>
next prev parent reply other threads:[~2022-04-11 6:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 0:29 Regression: memory corruption on Atmel SAMA5D31 Peter Rosin
2022-03-03 3:02 ` Saravana Kannan
2022-03-03 9:17 ` Peter Rosin
2022-03-04 3:55 ` Saravana Kannan
2022-03-04 6:57 ` Peter Rosin
2022-03-04 10:57 ` Peter Rosin
2022-03-04 11:12 ` Tudor.Ambarus
2022-03-04 12:38 ` Peter Rosin
2022-03-04 16:48 ` Tudor.Ambarus
2022-03-07 9:45 ` Tudor.Ambarus
2022-03-07 11:32 ` Peter Rosin
2022-03-07 20:32 ` Peter Rosin
2022-03-08 7:55 ` Nicolas Ferre
2022-03-09 8:30 ` Peter Rosin
[not found] ` <6d9561a4-39e4-3dbe-5fe2-c6f88ee2a4c6@axentia.se>
[not found] ` <ed24a281-1790-8e24-5f5a-25b66527044b@microchip.com>
[not found] ` <d563c7ba-6431-2639-9f2a-2e2c6788e625@axentia.se>
[not found] ` <e5a715c5-ad9f-6fd4-071e-084ab950603e@microchip.com>
2022-03-10 9:58 ` Peter Rosin
2022-03-10 10:40 ` Peter Rosin
2022-04-09 13:02 ` Thorsten Leemhuis
2022-04-11 6:21 ` Tudor.Ambarus [this message]
2022-05-17 14:50 ` Peter Rosin
2022-05-18 6:21 ` Tudor.Ambarus
2022-05-18 7:51 ` Peter Rosin
2022-06-20 7:04 ` Thorsten Leemhuis
2022-06-20 8:43 ` Tudor.Ambarus
2022-06-20 14:22 ` Tudor.Ambarus
2022-06-21 7:00 ` Peter Rosin
2022-06-21 10:46 ` Peter Rosin
2022-06-27 12:26 ` Tudor.Ambarus
2022-06-27 16:53 ` Tudor.Ambarus
2022-06-30 5:20 ` Peter Rosin
2022-06-30 9:23 ` Tudor.Ambarus
2022-06-30 10:20 ` Tudor.Ambarus
2022-07-13 16:01 ` Tudor.Ambarus
2022-07-28 7:45 ` Tudor.Ambarus
2022-07-28 8:39 ` Tudor.Ambarus
2022-07-29 20:09 ` Peter Rosin
2022-07-30 11:37 ` Peter Rosin
2022-07-31 3:44 ` Tudor.Ambarus
2022-03-04 20:06 ` Saravana Kannan
2022-03-04 8:00 ` Thorsten Leemhuis
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=4a1e8827-1ff0-4034-d96e-f561508df432@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=Cristian.Birsan@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Patrice.Vilchez@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=du@axentia.se \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=regressions@leemhuis.info \
--cc=saravanak@google.com \
/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;
as well as URLs for NNTP newsgroup(s).