From: Randy Dunlap <hidden> Date: 2012-01-25 18:09:01
On 01/24/2012 07:19 PM, Stephen Rothwell wrote:
Hi all,
There will be no linux-next tomorrow (2012/01/26) due to a public holiday.
Changes since 20120124:
My fixes tree contains:
powerpc: make PSERIES_IDLE bool
nvme build still fails on i386. (patch is around)
lib/crc32.c build still fails for some configs (Darrick Wong
posted a patch for this.)
sunrpc/stats.h usage fails when CONFIG_PROC_FS is not enabled
(I posted a patch for this one.)
back to net/sock.h and jump_label:
(on i386:)
/next/linux-next-20120125/include/net/sock.h:953:2: error: implicit declaration of function 'static_branch'
/next/linux-next-20120125/include/linux/jump_label.h:43:29: error: conflicting types for 'static_branch'
Full randconfig file is attached.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Wed, Jan 25, 2012 at 20:07, Randy Dunlap [off-list ref] wrote:
back to net/sock.h and jump_label:
(on i386:)
/next/linux-next-20120125/include/net/sock.h:953:2: error: implicit declaration of function 'static_branch'
/next/linux-next-20120125/include/linux/jump_label.h:43:29: error: conflicting types for 'static_branch'
Full randconfig file is attached.
Without having to add randomness, also in m68k/allmodconfig, now in Linus'
tree :-(
http://kisskb.ellerman.id.au/kisskb/buildresult/5491860/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Jan 25, 2012 at 20:07, Randy Dunlap [off-list ref] wrote:
quoted
back to net/sock.h and jump_label:
(on i386:)
/next/linux-next-20120125/include/net/sock.h:953:2: error: implicit declaration of function 'static_branch'
/next/linux-next-20120125/include/linux/jump_label.h:43:29: error: conflicting types for 'static_branch'
Full randconfig file is attached.
Glauber are you actually going to fix this or are you going to ignore
this bug report for another couple days?!?!
Frankly, I'm so sick and tired of all of these socket mem cgroup
regressions, this is way out of control and every "fix" seems to add
more build or runtime regressions.
Glauber, this has to stabilize soon or I will revert every single one
of your changes, and it will take a nuclear war and a multi-month
audit of your code to get those changes into the tree again.
From: Glauber Costa <hidden> Date: 2012-01-26 20:32:09
On 01/26/2012 10:43 PM, David Miller wrote:
From: Geert Uytterhoeven<geert@linux-m68k.org>
Date: Thu, 26 Jan 2012 18:18:28 +0100
quoted
On Wed, Jan 25, 2012 at 20:07, Randy Dunlap[off-list ref] wrote:
quoted
back to net/sock.h and jump_label:
(on i386:)
/next/linux-next-20120125/include/net/sock.h:953:2: error: implicit declaration of function 'static_branch'
/next/linux-next-20120125/include/linux/jump_label.h:43:29: error: conflicting types for 'static_branch'
Full randconfig file is attached.
Glauber are you actually going to fix this or are you going to ignore
this bug report for another couple days?!?!
Dave,
I am going to work on it right now, with no further delays, as I've been
doing with all the reports I've got. I didn't receive any report
about this one for some reason, and that's why I didn't say anything.
So thanks for nagging.
Frankly, I'm so sick and tired of all of these socket mem cgroup
regressions, this is way out of control and every "fix" seems to add
more build or runtime regressions.
Glauber, this has to stabilize soon or I will revert every single one
of your changes, and it will take a nuclear war and a multi-month
audit of your code to get those changes into the tree again.
So for the normal scenarios with my code disabled, aside for one problem
in day1, all of the failures were build problems.
To be quite honest, the interactions between configs are being quite
"funny", and spanning more problems than I anticipated.
What I am doing here, is building the patches against a couple of
randconfigs, and some more targeted ones before I send them to you.
If you have any other advise on how to handle this, I'd be happy to take
them.
On the specifics of this bug, I verified this config compiles okay in
your tree + my patches at the day I last sent them. I also verified it
breaks on the tree today.
The reason seems to be that some other patch tweaked with the header
files in an unrelated patch, and the static_branch definition that was
getting to us in sock.h, is no longer getting there.
Including it explicitly fixes it here. I will again pass through a
battery of randconfigs on my own, and send you a fix.
Sorry again for the trouble.
From: Stephen Rothwell <hidden> Date: 2012-01-26 21:46:40
On Fri, 27 Jan 2012 00:31:13 +0400 Glauber Costa [off-list ref] wrote:
On the specifics of this bug, I verified this config compiles okay in
your tree + my patches at the day I last sent them. I also verified it
breaks on the tree today.
The reason seems to be that some other patch tweaked with the header
files in an unrelated patch, and the static_branch definition that was
getting to us in sock.h, is no longer getting there.
Including it explicitly fixes it here. I will again pass through a
battery of randconfigs on my own, and send you a fix.
Which is one of the reasons we have Rule 1 in Documentation/SubmitChecklist:
1: If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones
that you use.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Glauber Costa <hidden> Date: 2012-01-26 21:48:19
On 01/27/2012 01:46 AM, Stephen Rothwell wrote:
On Fri, 27 Jan 2012 00:31:13 +0400 Glauber Costa[off-list ref] wrote:
quoted
On the specifics of this bug, I verified this config compiles okay in
your tree + my patches at the day I last sent them. I also verified it
breaks on the tree today.
The reason seems to be that some other patch tweaked with the header
files in an unrelated patch, and the static_branch definition that was
getting to us in sock.h, is no longer getting there.
Including it explicitly fixes it here. I will again pass through a
battery of randconfigs on my own, and send you a fix.
Which is one of the reasons we have Rule 1 in Documentation/SubmitChecklist:
1: If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones
that you use.
I understand that. I wasn't saying I am not to blame, just why this
wasn't catched in any test of mine before.
The fix is on its way.