From:   Gabriel Krisman Bertazi <krisman@collabora.com>
To:     Emil Velikov <emil.velikov@collabora.com>
Cc:     Shreeya Patel <shreeya.patel@collabora.com>,
        linus.walleij@linaro.org, brgl@bgdev.pl,
        linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        kernel@collabora.com
Subject: Re: [PATCH] gpio: Initialize gc->irq.domain before setting gc->to_irq
In-Reply-To: <YYp8JzxfLK2u0fU4@arch-x1c3> (Emil Velikov's message of "Tue, 9
        Nov 2021 13:48:23 +0000")
Organization: Collabora
References: <20211108214148.9724-1-shreeya.patel@collabora.com>
        <YYp8JzxfLK2u0fU4@arch-x1c3>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Date:   Mon, 15 Nov 2021 14:53:49 -0500
Message-ID: <87tugdxkj6.fsf@collabora.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Emil Velikov <emil.velikov@collabora.com> writes:

> Hi Shreeya, all,
>
> On 2021/11/09, Shreeya Patel wrote:
>> There is a race in registering of gc->irq.domain when
>> probing the I2C driver.
>> This sometimes leads to a Kernel NULL pointer dereference
>> in gpiochip_to_irq function which uses the domain variable.
>> 
>> To avoid this issue, set gc->to_irq after domain is
>> initialized. This will make sure whenever gpiochip_to_irq
>> is called, it has domain already initialized.
>> 
>
> What is stopping the next developer to moving the assignment to the
> incorrect place? Aka should we add an inline comment about this?

I agree with Emil.  The patch seems like a workaround that doesn't
really solve the underlying issue.  I'm not familiar with this code, but
it seems that gc is missing a lock during this initialization, to prevent
it from exposing a partially initialized gc->irq.

-- 
Gabriel Krisman Bertazi