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 >
WARNING: multiple messages have this Message-ID (diff)
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 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-11 6:21 UTC|newest] Thread overview: 77+ 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 3:02 ` Saravana Kannan 2022-03-03 9:17 ` Peter Rosin 2022-03-03 9:17 ` Peter Rosin 2022-03-04 3:55 ` Saravana Kannan 2022-03-04 3:55 ` Saravana Kannan 2022-03-04 6:57 ` Peter Rosin 2022-03-04 6:57 ` Peter Rosin 2022-03-04 10:57 ` Peter Rosin 2022-03-04 10:57 ` Peter Rosin 2022-03-04 11:12 ` Tudor.Ambarus 2022-03-04 11:12 ` Tudor.Ambarus 2022-03-04 12:38 ` Peter Rosin 2022-03-04 12:38 ` Peter Rosin 2022-03-04 16:48 ` Tudor.Ambarus 2022-03-04 16:48 ` Tudor.Ambarus 2022-03-07 9:45 ` Tudor.Ambarus 2022-03-07 9:45 ` Tudor.Ambarus 2022-03-07 11:32 ` Peter Rosin 2022-03-07 11:32 ` Peter Rosin 2022-03-07 20:32 ` Peter Rosin 2022-03-07 20:32 ` Peter Rosin 2022-03-08 7:55 ` Nicolas Ferre 2022-03-08 7:55 ` Nicolas Ferre 2022-03-09 8:30 ` Peter Rosin 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 9:58 ` Peter Rosin 2022-03-10 10:40 ` Peter Rosin 2022-03-10 10:40 ` Peter Rosin 2022-04-09 13:02 ` Thorsten Leemhuis 2022-04-09 13:02 ` Thorsten Leemhuis 2022-04-11 6:21 ` Tudor.Ambarus [this message] 2022-04-11 6:21 ` Tudor.Ambarus 2022-05-17 14:50 ` Peter Rosin 2022-05-17 14:50 ` Peter Rosin 2022-05-18 6:21 ` Tudor.Ambarus 2022-05-18 6:21 ` Tudor.Ambarus 2022-05-18 7:51 ` Peter Rosin 2022-05-18 7:51 ` Peter Rosin 2022-06-20 7:04 ` Thorsten Leemhuis 2022-06-20 7:04 ` Thorsten Leemhuis 2022-06-20 8:43 ` Tudor.Ambarus 2022-06-20 8:43 ` Tudor.Ambarus 2022-06-20 14:22 ` Tudor.Ambarus 2022-06-20 14:22 ` Tudor.Ambarus 2022-06-21 7:00 ` Peter Rosin 2022-06-21 7:00 ` Peter Rosin 2022-06-21 10:46 ` Peter Rosin 2022-06-21 10:46 ` Peter Rosin 2022-06-27 12:26 ` Tudor.Ambarus 2022-06-27 12:26 ` Tudor.Ambarus 2022-06-27 16:53 ` Tudor.Ambarus 2022-06-27 16:53 ` Tudor.Ambarus 2022-06-30 5:20 ` Peter Rosin 2022-06-30 5:20 ` Peter Rosin 2022-06-30 9:23 ` Tudor.Ambarus 2022-06-30 9:23 ` Tudor.Ambarus 2022-06-30 10:20 ` Tudor.Ambarus 2022-06-30 10:20 ` Tudor.Ambarus 2022-07-13 16:01 ` Tudor.Ambarus 2022-07-13 16:01 ` Tudor.Ambarus 2022-07-28 7:45 ` Tudor.Ambarus 2022-07-28 7:45 ` Tudor.Ambarus 2022-07-28 8:39 ` Tudor.Ambarus 2022-07-28 8:39 ` Tudor.Ambarus 2022-07-29 20:09 ` Peter Rosin 2022-07-29 20:09 ` Peter Rosin 2022-07-30 11:37 ` Peter Rosin 2022-07-30 11:37 ` Peter Rosin 2022-07-31 3:44 ` Tudor.Ambarus 2022-07-31 3:44 ` Tudor.Ambarus 2022-03-04 20:06 ` Saravana Kannan 2022-03-04 20:06 ` Saravana Kannan 2022-03-04 8:00 ` Thorsten Leemhuis 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.