linux-kernel - Re: [GIT PULL] mtd: Fixes for v5.17-rc5

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] [day] [month] [year] [list]

Message-ID: <20220307173453.24a55573@xps13>
Date:   Mon, 7 Mar 2022 17:34:53 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-mtd@...ts.infradead.org, Richard Weinberger <richard@....at>,
        Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Michael Walle <michael@...le.cc>,
        Pratyush Yadav <p.yadav@...com>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] mtd: Fixes for v5.17-rc5

Hi Linus,

torvalds@...ux-foundation.org wrote on Sun, 6 Mar 2022 12:08:04 -0800:

> I'm about to release rc7, and I still don't have the build fix for MTD
> that has been pending in the mtd tree since Feb 19.
> 
> I'm talking about commit 7cf1de957a98 ("mtd: rawnand: omap2: Actually
> prevent invalid configuration and build error"). The lack of which
> still causes build errors on at least sparc64, and has since rc4.

I have received a robot error triggered because of COMPILE_TEST being
selected in a random config. Yes it should not happen, but no it does
not break sparc64 AFAIK. If it effectively does, then I deeply
apologize but I didn't receive this information myself.

I proposed a fix a month ago but it got rejected because people claimed
"nobody else used that solution until now so let's not try that". So we
went for another fix, which lead to the issue you complain about.

I then received another fix to queue on top of -rc4, which I did,
in a reasonable time frame. But then I had to wait for robots to
tell me if there is still a breakage with another random configuration,
and this may take about a week to happen.

Last week I was fine with the result and finally took the time to send
it to you on Friday. Yes, it could have been earlier. To be short, when
writing a short explanation for this PR, I realized the fix would
increase the kernel size for no reason on several architectures so I
asked if we could consider another way:
https://lore.kernel.org/linux-mtd/6c09de15-1ab2-5ca8-7003-69ff3f7c4dc5@kernel.org/T/#mec7f38108f189f4af5b865011d758a2afa6009c4

Thanks to the discussions we had today, there was actually a
misunderstanding regarding this dependency and the fix can go in as-is.

Should I have sent this fix anyway? I still think retaining the fix
was the good thing to do. Should I have done that earlier? Yes, I could
have saved a week in the best case. Was this fix urgent? I don't think
it was to the point of getting you (and now myself as well) frustrated.

> This is getting quite frustrating. These are basic errors that fail
> some very basic issues,

"select" dependencies are the source of many problems because of the
"I won't propagate the dependency any further" choice. Yes for many
simple situations Kconfig is well shaped but for any non trivial
situation it is not what I would call a "very basic issue".

> have fixes,

Not from my point of view, at least not while I was still in time to
send the fix.

> and the fixes for some inexplicable reason aren't actually propagated up.

The truth is, you personally cannot follow all the patches nor read
all the discussions. I am not blaming anybody for that. I understand
you have to ask. But I would personally appreciate if you could use a
more friendly tone; "getting quite frustrating", "basic errors, "very
basic issues", "inexplicable reason" are all superfluous.

Anyway, I am sorry for the inconvenience, I will provide this fix asap.

Thanks,
Miquèl