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: <CAOesGMhGT30QN2LeVp2sgzY0BjbguW=iw3x1PH8RVB-Rj-GZNQ@mail.gmail.com>
Date:	Wed, 4 Jun 2014 09:23:43 -0700
From:	Olof Johansson <olof@...om.net>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	John Stultz <john.stultz@...aro.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: build failure after merge of the tip tree

On Wed, Jun 4, 2014 at 3:49 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Wed, 4 Jun 2014, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>>
>> drivers/clocksource/versatile.c: In function 'versatile_sched_clock_init':
>> drivers/clocksource/versatile.c:37:2: error: implicit declaration of function 'setup_sched_clock' [-Werror=implicit-function-declaration]
>>
>> Caused by commit c04ae71c9c26 ("sched_clock: Remove deprecated
>> setup_sched_clock() API") from the tip tree.  The usage was only added
>> to Linus' tree today by commit 220e2a8d22cd ("clocksource: Sched clock
>> source for Versatile Express") (but this commit has been in linux-next
>> since May 22 at least).
>>
>> I have reverted the tip tree commit for today.
>
> Dammit. Why the heck can ARM folks not route their stuff through the
> relevant maintainers? Because ARM is a different universe with
> different rules or what?

We talked about this as late as February this year. It's has been a
long-standing issue that we've struggled with how we should manage.

When I talked to you about it (irqchip drivers at the time), you said
you were in general fine with us merging driver patches when someone
times out waiting on you to review/merge a patch. My concern at the
time is that while we can look at the code of the patch and review
that, we don't have the larger picture of what's going on in the
subsystem. Which is what caused problems here, I'd say.

So, we'll dial back and stop taking these patches through our tree
without an explicit ack or shared branch from you (or Daniel on
clocksource). Not a problem at all.

> Of course this crap is already in Linus next branch, so it essentially
> blocks me from sending my pending timers/core branch.

We obviously never intended to cause any problems like these, and I
apologize for that. On the other hand, it would have been a lot easier
to handle had the code on your end landed a bit sooner than in the
middle of the merge window.

> Patch below. Linus, can you please apply this?
>
> I've ranted about this before. It's not the first time that ARM breaks
> stuff I maintain.
>
> Again: Send your stuff against drivers/clocksource and drivers/irqchip
> to the maintainers.
>
> I'm happy to provide you a separate branch to pull that stuff from me,
> if you have dependencies on that, but I really don't want to see any
> of this again, ever.
>
> Yours seriously grumpy

Not much I can say besides what's above and that I owe you a few beers
at the next conference.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ