Message ID | 20230228214934.9321-1-asmaa@nvidia.com |
---|---|
Headers | show |
Series | gpio: Restrict usage of GPIO chip irq members before initialization | expand |
On 2/28/23 2:49 PM, Asmaa Mnebhi wrote: > BugLink: https://bugs.launchpad.net/bugs/2007581 > > SRU Justification: > > [Impact] > > GPIO chip irq members are exposed before they could be completely > initialized and this leads to race conditions. > > One such issue was observed for the gc->irq.domain variable which > was accessed through the pwr-mlxbf.c driver in gpiochip_to_irq() before > it could be initialized by gpiochip_add_irqchip(). This resulted in > Kernel NULL pointer dereference. This is a well known issue in the linux community > and was fixed via 2 commits: > 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 > and > 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 (since the previous commit caused a regression) > > This race condition is intermittent and hard to reproduce. > > [Fix] > > * Backport: 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 to fix the bug at stake > * Backport: 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 to fix a regression introduced by the previous commit > > [Test Case] > > * Check that the gpio-mlxbf2.c driver is loaded with no kernel panic > * check that all drivers dependent on gpio-mlxbf2.c driver are loaded (mlxbf-gige and pwr-mlxbf) > * do 5000 reboots to make sure this race condition no longer happens > > [Regression Potential] > > This could cause some regression with the use of gpio interrupts so it is important to test the dependent > drivers mlxbf-gige and pwr-mlxbf. Trigger power reset interrupt to test pwr-mlxbf and bring down/up the > oob_net0 interface to test mlxbf-gige. > > Mario Limonciello (1): > gpio: Request interrupts after IRQ is initialized > > Shreeya Patel (1): > gpio: Restrict usage of GPIO chip irq members before initialization > > drivers/gpio/gpiolib.c | 19 +++++++++++++++++++ > include/linux/gpio/driver.h | 9 +++++++++ > 2 files changed, 28 insertions(+) > Acked-by: Tim Gardner <tim.gardner@canonical.com> Your backport explanation is a little sparse. Fortunately there was nothing more then simple context adjustments.
Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> On Tue, Feb 28, 2023 at 10:50 PM Asmaa Mnebhi <asmaa@nvidia.com> wrote: > > BugLink: https://bugs.launchpad.net/bugs/2007581 > > SRU Justification: > > [Impact] > > GPIO chip irq members are exposed before they could be completely > initialized and this leads to race conditions. > > One such issue was observed for the gc->irq.domain variable which > was accessed through the pwr-mlxbf.c driver in gpiochip_to_irq() before > it could be initialized by gpiochip_add_irqchip(). This resulted in > Kernel NULL pointer dereference. This is a well known issue in the linux community > and was fixed via 2 commits: > 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 > and > 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 (since the previous commit caused a regression) > > This race condition is intermittent and hard to reproduce. > > [Fix] > > * Backport: 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 to fix the bug at stake > * Backport: 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 to fix a regression introduced by the previous commit > > [Test Case] > > * Check that the gpio-mlxbf2.c driver is loaded with no kernel panic > * check that all drivers dependent on gpio-mlxbf2.c driver are loaded (mlxbf-gige and pwr-mlxbf) > * do 5000 reboots to make sure this race condition no longer happens > > [Regression Potential] > > This could cause some regression with the use of gpio interrupts so it is important to test the dependent > drivers mlxbf-gige and pwr-mlxbf. Trigger power reset interrupt to test pwr-mlxbf and bring down/up the > oob_net0 interface to test mlxbf-gige. > > Mario Limonciello (1): > gpio: Request interrupts after IRQ is initialized > > Shreeya Patel (1): > gpio: Restrict usage of GPIO chip irq members before initialization > > drivers/gpio/gpiolib.c | 19 +++++++++++++++++++ > include/linux/gpio/driver.h | 9 +++++++++ > 2 files changed, 28 insertions(+) >
Applied to focal:linux-bluefield/master-next. Thanks. -- Best regards, Bartlomiej On Tue, Feb 28, 2023 at 10:50 PM Asmaa Mnebhi <asmaa@nvidia.com> wrote: > > BugLink: https://bugs.launchpad.net/bugs/2007581 > > SRU Justification: > > [Impact] > > GPIO chip irq members are exposed before they could be completely > initialized and this leads to race conditions. > > One such issue was observed for the gc->irq.domain variable which > was accessed through the pwr-mlxbf.c driver in gpiochip_to_irq() before > it could be initialized by gpiochip_add_irqchip(). This resulted in > Kernel NULL pointer dereference. This is a well known issue in the linux community > and was fixed via 2 commits: > 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 > and > 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 (since the previous commit caused a regression) > > This race condition is intermittent and hard to reproduce. > > [Fix] > > * Backport: 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 to fix the bug at stake > * Backport: 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 to fix a regression introduced by the previous commit > > [Test Case] > > * Check that the gpio-mlxbf2.c driver is loaded with no kernel panic > * check that all drivers dependent on gpio-mlxbf2.c driver are loaded (mlxbf-gige and pwr-mlxbf) > * do 5000 reboots to make sure this race condition no longer happens > > [Regression Potential] > > This could cause some regression with the use of gpio interrupts so it is important to test the dependent > drivers mlxbf-gige and pwr-mlxbf. Trigger power reset interrupt to test pwr-mlxbf and bring down/up the > oob_net0 interface to test mlxbf-gige. > > Mario Limonciello (1): > gpio: Request interrupts after IRQ is initialized > > Shreeya Patel (1): > gpio: Restrict usage of GPIO chip irq members before initialization > > drivers/gpio/gpiolib.c | 19 +++++++++++++++++++ > include/linux/gpio/driver.h | 9 +++++++++ > 2 files changed, 28 insertions(+) >