linux-kernel - Re: [Letux-kernel] BUG: drivers/pinctrl/core: races in pinctrl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Jun 2018 11:29:30 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel@...a-handheld.com,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [Letux-kernel] BUG: drivers/pinctrl/core: races in pinctrl_groups and deferred probing


> Am 18.06.2018 um 11:14 schrieb Tony Lindgren <tony@...mide.com>:
> 
> * Andy Shevchenko <andy.shevchenko@...il.com> [180618 08:25]:
>> On Sat, Jun 16, 2018 at 2:08 PM H. Nikolaus Schaller <hns@...delico.com> wrote:
>>> But it looks as if we still have duplicate assignments by deferred probing, i.e. some cleanup is
>>> missing (or is this intended behaviour?).
>> 
>>> But I think the fundamental problem is that the same driver assigns multiple slots if
>>> probing is deferred.
>> 
>> Indeed.
>> 
>> I think there is a simple way to clean up pinctrl stuff on failed probe. See
>> https://elixir.bootlin.com/linux/v4.18-rc1/source/drivers/base/dd.c#L416
>> 
>> We only bind pins, and do not perform any actions when failure happens later on.
> 
> Yup seems like a good approach. I'll take a look if we can just
> check if the function or group name already exists and return
> the existing selector in that case.

Ok, that would also solve the duplication issue.

On the other hand we still have a stale entry if the probing process
finally fails after several attempts.

This may happen if a driver with a valid DT entry is blacklisted in
/etc/modprobe.d/blacklist.conf. Then, the kernel will try to modprobe
it several times through udev until it gives up. The reason seems to
be that the deferred probing thread does not know why the driver did
not probe successfully.

BR and thanks,
Nikolaus

> 
> Regards,
> 
> Tony