Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220530082552.46113-1-sander@svanheule.net>
In-Reply-To: <20220530082552.46113-1-sander@svanheule.net>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Wed, 1 Jun 2022 17:26:29 +0200
Message-ID: <CAHp75Vd_Z9MrqTzGKL+U1dCus3U09P3AeTBGx0J3LY56jHTDjQ@mail.gmail.com>
Subject: Re: [PATCH v1] gpio: realtek-otto: always honor empty CPU masks
To:     Sander Vanheule <sander@svanheule.net>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        INAGAKI Hiroshi <musashino.open@gmail.com>,
        Robert Marko <robimarko@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, May 30, 2022 at 3:57 PM Sander Vanheule <sander@svanheule.net> wrote:
>
> On uniprocessor builds, for_each_cpu(cpu, mask) will assume 'mask'
> always contains exactly one CPU, and ignore the actual mask contents.
> This causes the loop to run, even when it shouldn't on an empty mask,
> and tries to access an uninitialised pointer.

It's too noisy traceback, I believe you may squeeze it out and leave
something like ~5-6 lines only.

...

> This patch is more of a work-around than a real fix, and ensures the
> driver runs properly on uniprocessor builds. My tests were done using an
> SMP-enabled build on a single-core system, which is why is missed this
> erroneous behaviour.
>
> The real fix would be a modification of include/linux/cpumask.h, which
> may take longer to finalise, but I would rather have the issue in this
> driver fixed in the 5.19 release.

Hmm... I dunno that cpumask fix should be hard or easy, but I think
you may try it simultaneously, so we will win one way or the other.

-- 
With Best Regards,
Andy Shevchenko