linux-kernel - Re: [PATCH v3 0/5] Fix a whole host of nvmem registration/cleanup issues

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]

Message-ID: <Y72RXJqcGQ3G0gXu@shell.armlinux.org.uk>
Date:   Tue, 10 Jan 2023 16:25:00 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Hector Martin <marcan@...can.st>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Gaosheng Cui <cuigaosheng1@...wei.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Maxime Ripard <mripard@...nel.org>
Subject: Re: [PATCH v3 0/5] Fix a whole host of nvmem registration/cleanup
 issues

On Tue, Jan 03, 2023 at 08:56:32PM +0000, Russell King (Oracle) wrote:
> Really not interested in your politics. Not interested in fixing this
> problem.
> 
> I'll use these patches to fix the problem in my tree. I don't care about
> mainline.

Having thought this over, this was an unfair over-reaction for which
I'd like to apologise. It was proving to be a very stressful couple
of days.

> > Uhh. The series itself looks fine as far as fixing the problems, but I
> > fail to see how this is any better than my attempt as far as backporting
> > or commit atomicity goes. Patch #4 fixes the newer gpio leak bug *and*
> > half fixes the race condition bug,

There are two choices for patch for:

1. add gpiod_put().
2. make use of the gpiod_put() already present in the release function.

Either way, patch 5 depends on patch 4, and there's no way around that.
This does not mean that they can't be back ported though - patch 4
can be backported to the appropriate point, and further backported
merely by dropping one hunk - and thus it becomes a preparatory patch
for patch 5, and even more so, separates the conversion from
device_register() to device_initialize()+device_add() from the actual
fix itself (which in patch 5 merely moves device_add() and rearranges
the cleanup.)

However, where our patches differ is that my series fixes one problem
in one patch, rather than trying to address multiple problems in one
patch. As has been pointed out, this is a documented requirement in
the submitting-patches.rst document, which has been there for a very
long time. You had been pointed to this document already over this
point.

Therefore, I believe my series to be a technically better approach
which addresses several more issues while conforming to the "Solve
only one problem per patch." requirement which can be trivially
backported - and I truely believe that even patch 4 complies with
the requirement in submitting-patches.rst. I certainly do not
believe patch 4 is a kind of "partial" fix for the race condition,
since it in no way changes the presence of the race.

I hope that we can continue to work to get the Apple M1 supported more
fully in the future.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!