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:   Fri, 28 Apr 2023 07:12:28 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Nipun Gupta <nipun.gupta@....com>,
        Nikhil Agarwal <nikhil.agarwal@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Saravana Kannan <saravanak@...gle.com>
Subject: Re: [GIT PULL] Driver core updates for 6.4-rc1

On Thu, Apr 27, 2023 at 04:31:39PM -0700, Linus Torvalds wrote:
> On Thu, Apr 27, 2023 at 7:21 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > Once again, a busy development cycle, with lots of changes happening in
> > the driver core in the quest to be able to move "struct bus" and "struct
> > class" into read-only memory, a task now complete with these changes.
> 
> Well, this also caused a build failure, and I didn't catch it during
> the merge, because it only happened on arm64.
> 
> The reason it only happens on arm64 is that it is in the CDX bus
> driver, and that one has
> 
>         depends on OF && ARM64
> 
> despite apparently building fine on x86-64 too if you were to just add
> a "|| COMPILE_TEST" to it.
> 
> And I did notice this build failure eventually, since I do arm64
> builds on my M2 Macbook Air. But while it's a perfectly cromulent
> laptop, it's not like it's a speed daemon. It takes something like ~75
> minutes for afull allmodconfig build, so certainly not between each
> pull request.
> 
> End result: my merge test builds are all done on x86-64, and the arm64
> test builds happen much less regularly (ie: typically a couple of
> times a day).
> 
> I did the obvious fixup, but I can only assume (and hope) that this
> was caught by somebody else during the merge window, and that
> 
> > All of these have been in linux-next for a while with no reported
> > problems.
> 
> was just a lie.

Sorry about that, on it's own, it was fine, but merged with the
char-misc tree, there was a build issue, I had forgotten all about that.
I know we had already resolved one issue with merging this tree with the
DRM tree by reworking the DRM tree in advance, and that had pushed this
instance out of my memory.

In the future, how do you want stuff like "when this is merged with that
tree, something needs to be done" type of things to be pointed out?
linux-next keeps resolution patches around, do you want just a pointer
to that to make things easier?

And thanks for the fixup, it looks correct.

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ