[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <033a01da9490$6c517490$44f45db0$@trustnetic.com>
Date: Mon, 22 Apr 2024 16:38:17 +0800
From: Jiawen Wu <jiawenwu@...stnetic.com>
To: "'Bartosz Golaszewski'" <bartosz.golaszewski@...aro.org>,
<andriy.shevchenko@...ux.intel.com>
Cc: <brgl@...ev.pl>,
<elder@...aro.org>,
<geert+renesas@...der.be>,
<linus.walleij@...aro.org>,
<linux-gpio@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
<paulmck@...nel.org>,
<warthog618@...il.com>,
<wsa@...-dreams.de>
Subject: RE: [PATCH v3 00/24] gpio: rework locking and object life-time control
On Sat, April 20, 2024 5:29 AM, Bartosz Golaszewski wrote:
> On Fri, 19 Apr 2024 at 09:04, Jiawen Wu <jiawenwu@...stnetic.com> wrote:
> >
> > Hi Bartosz Golaszewski,
> >
> > I ran into a kernel crash problem when I pull the latest net-next.git, and
> > finally it was found that is caused by this patch series merged.
> >
> > The kernel crashed because I got gpio=0 when I called irq_find_mapping()
> > and then struct irq_data *d=null, as my driver describes:
> >
> > int gpio = irq_find_mapping(gc->irq.domain, hwirq);
> > struct irq_data *d = irq_get_irq_data(gpio);
> >
> > txgbe_gpio_irq_ack(d);
> >
> > The deeper positioning is this line in __irq_resolve_mapping().
> >
> > data = rcu_dereference(domain->revmap[hwirq]);
> >
> > So, is it the addition of SRCU infrastructure that causes this issue?
> >
>
> This is irq-specific RCU that I did not add in the GPIO series. Please
> provide us with more information. Bisect to the exact commit causing
> the issue and post the kernel log (we don't know what kind of crash
> you trigger and what the stack trace is).
>
> Bart
>
Hi Bartosz & Andy,
Thanks for your replies.
I'm sorry for the misunderstanding, and glad this patch doesn't cause any
problems. I thought the issue was in this patch because of my mistake.
It's actually caused by other patches. :)
Powered by blists - more mailing lists