Subject: Re: [PATCH] gpio: Initialize gc->irq.domain before setting gc->to_irq
To:     Gabriel Krisman Bertazi <krisman@collabora.com>,
        linus.walleij@linaro.org, andy.shevchenko@gmail.com,
        sebastian.reichel@collabora.com
Cc:     brgl@bgdev.pl, linux-gpio@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel@collabora.com,
        Emil Velikov <emil.velikov@collabora.com>
References: <20211108214148.9724-1-shreeya.patel@collabora.com>
 <YYp8JzxfLK2u0fU4@arch-x1c3> <87tugdxkj6.fsf@collabora.com>
From:   Shreeya Patel <shreeya.patel@collabora.com>
Message-ID: <d7d8bd97-3c12-bf04-a0ad-e0f391158d01@collabora.com>
Date:   Thu, 25 Nov 2021 16:26:45 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <87tugdxkj6.fsf@collabora.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk


On 16/11/21 1:23 am, Gabriel Krisman Bertazi wrote:
> 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.

I do not see any locking mechanism used for protecting the use of gc 
members before they are
initialized. We faced a very similar problem with gc->to_irq as well 
where we had to return EPROBE_DEFER until it was initialized and ready 
to be used.

Linus, do you have any suggestion on what would be the correct way to 
fix this issue of race in registration of gc members?


Thanks,
Shreeya Patel
>