On Tue, Mar 15, 2022 at 2:32 PM Shreeya Patel <shreeya.patel@xxxxxxxxxxxxx> wrote: > On 15/03/22 4:30 pm, Andy Shevchenko wrote: > > On Tue, Mar 15, 2022 at 12:38 PM Shreeya Patel > > <shreeya.patel@xxxxxxxxxxxxx> wrote: > > > > Thanks for the update, my comments below. > > > >> gc irq members are exposed before they could be completely > > gc --> GPIO chip > > > >> initialized and this leads to race conditions. > > Any example here. like ~3-4 lines of the Oops in question? > > > >> One such issue was observed for the gc->irq.domain variable which > >> was accessed through the I2C interface in gpiochip_to_irq() before > >> it could be initialized by gpiochip_add_irqchip(). This resulted in > >> Kernel NULL pointer dereference. > >> > >> To avoid such scenarios, restrict usage of gc irq members before > > gc --> GPIO chip > > > >> they are completely initialized. > > ... > > > >> + /* > >> + * Using barrier() here to prevent compiler from reordering > >> + * gc->irq.gc_irq_initialized before initialization of above > >> + * gc irq members. > >> + */ > >> + barrier(); > >> + > >> + gc->irq.gc_irq_initialized = true; > > There are too many duplications. Why not simply call it 'initialized'? > > > >> - if (gc->to_irq) { > >> + if (gc->to_irq && gc->irq.gc_irq_initialized) { > > Why can't this check be added into gpiochip_to_irq() ? > > > > if (!gc->irq.initialized) > > return -ENXIO; > > > > ... > > > Because we don't want to return -ENXIO in case of race condition. > > It should return -EPROBE_DEFER similar to how we are doing when gc->to_irq > is NULL. > So in this case when both gc->to_irq = NULL and gc->irq.initialized = FALSE, > we will be returning -EPROBE_DEFER. This is not true. The return code relies on an IRQ chip which may be assigned (not NULL). > This will make sure that devices > like touchscreen > do not become fatal due to returning -ENXIO. So, then you need to move it to to_irq() and return there deferred probe with a good comment in the code. > >> + bool gc_irq_initialized; > > Can you move it closer to .init_hw so it will be weakly grouped by > > logic similarities? > > Also see above. > > Thanks for your comments, I'll make the necessary changes and send a v3. -- With Best Regards, Andy Shevchenko