Hi all,
[I have been asked to provide a summary of changes before the biolerplate

so here goes (please tell me if this is what you want or not).  I am not

going to try to describe the changes in the individual trees, just the

interactions between them.]
Changes since next-20080410:
I no longer revert "x86: phase out forced inlining".

There is a new conflict in arch/s390/lib/uaccess_pt.c between the s390 and

	kvm trees.

There is a new trivial white space conflict in arch/ia64/kernel/mca.c.

I no longer need to revert "wusb: add the wireless usb stack to Linux".
Today's Next/Trees file is lying: the x86-latest and sched-latest trees

did not merge/build correctly so have not been included.
----------------------------------------------------------------------------
I have created today's linux-next tree at

git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git

(tar balls at

http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
You can see which trees have been included by looking in the Next/Trees

file in the source.  There are also quilt-import.log and merge.log files

in the Next directory.  Between each merge, the tree was built with

a ppc64_defconfig for powerpc and an allmodconfig for x86_64.
There were a few merge conflicts (fairly trivial) and couple of build

failures (notified).  There is a know build failure with powerpc

allyesconfig.  Below is a summary of the state of the merge.
We are up to 55 trees, more are welcome (even if they are currently

empty).  Thanks to those who have contributed, and to those who haven't,

please do.
Status of my local build tests will be at

http://kisskb.ellerman.id.au/linux-next.  If maintainers want to give

advice about cross compilers/configs that work, we are always open to add

more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests

at http://l4x.org/k/ and the guys at http://test.kernel.org/.
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au
M...
[ message continues ]

Has the printk format warning in arch/x86/mm/ioremap.c already been fixed

somewhere else (and not in linux-next merges)?
---

From: Randy Dunlap <randy.dunlap@oracle.com>
Fix printk formats in x86/mm/ioremap.c:
next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'

next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'

next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>

---

 arch/x86/mm/ioremap.c |    5 +++--

 1 file changed, 3 insertions(+), 2 deletions(-)
--- next-20080410.orig/arch/x86/mm/ioremap.c

+++ next-20080410/arch/x86/mm/ioremap.c

@@ -134,7 +134,7 @@ static void __iomem *__ioremap(resource_
 	if (!phys_addr_valid(phys_addr)) {

 		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",

-		       phys_addr);

+		       (unsigned long long)phys_addr);

 		WARN_ON_ONCE(1);

 		return NULL;

 	}

@@ -187,7 +187,8 @@ static void __iomem *__ioremap(resource_

 		     new_prot_val == _PAGE_CACHE_WB)) {

 			pr_debug(

 		"ioremap error for 0x%llx-0x%llx, requested 0x%lx, got 0x%lx\n",

-				phys_addr, phys_addr + size,

+				(unsigned long long)phys_addr,

+				(unsigned long long)(phys_addr + size),

 				prot_val, new_prot_val);

 			free_memtype(phys_addr, phys_addr + size);

 			return NULL;

--

is there really no way to solve this more cleanly than a forced cast? It

is a totally uninteresting warning that we pass in a narrower type to

printk(). It cannot ever cause any bugs or problems. Why does gcc warn

about it?
	Ingo

--

I haven't seen any other decent solutions.  This is what we do
No idea about that part.
---

~Randy

--

You can define macros and use them in the format string.

In this case

		printk(KERN_WARNING "ioremap: invalid physical address %" PRIRESOURCESZ "\n",

		       phys_addr);

(see the PRI* macros in

http://www.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html

and e.g. glibc inttypes.h to see how it is defined).  Other alternative is

custom format length modifiers, but unfortunately there is no easy way ATM

to teach GCC about them.
	Jakub

--

Hi,

I tried this.
In this particular case, phys_addr is a type(def) of resource_size_t,

so we still get gcc warnings:
next-20080410/arch/x86/mm/ioremap.c: In function '__ioremap':

next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'

next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
so we still need to cast phys_addr either to (unsigned long) or

(unsigned long long).  Rigth?  or am I missing something?  if so, what?
Thanks,

---

~Randy

--

Er...  That's kinda obvious - vararg function getting the wrong-sized

argument is *NOT* a harmless situation.  And yes, it's certainly a bug -

gcc manages to recover by using the knowledge of printf() formats (i.e.

it guesses that we want a long long and does conversion), but try to

do

	char *s = "%llx %c";

	printf(s, 1, '.');

and watch the show...

--

well, gcc does not "recover", we _gave_ it the format string as a

constant, and do so in 99.9% of the cases. It is a totally

well-specified thing.
so yes, this warning is bogus.
You are right that passing in a non-constant string to printf is

inherently dangerous though, and i'd suggest we warn about _that_ very

prominently.
but the constant noise from gcc about printf formats, where the

conversion is very clear and could be done implicitly, only hinders us

and only teaches people to _ignore_ gcc warnings - which is actually

very dangerous.
the only warning from gcc in this area should be where the format

results in information _loss_ (i.e. the format has a narrower type than

we pass into it) - there a warning is very much needed - and the

programmer should then fix the bug or add a cast.
	Ingo

--

It is an undefined behaviour according to any variant of C standard.

Sorry, printf() is not magic and it does _not_ have special calling
No, sorry.  That kind of mismatch is simply not a valid C.  Plain as that,

read the standard and you'll see.
Fundamentally, printf() is a function like any other vararg one.  So

explicitly typed arguments *are* the right thing to do.
What is not right is the lack of ability to define new conversions.  If

we could do that, we would kill the absolute majority of casts - and

remain within normal C limits...

--

... but reality called in and gcc added printf format checks as a gcc

extension and even modifies the code to make it safe when the user gets

it "wrong".
why? Because vararg is a dangerous concept as specified and strong but

meaningful type checking should be enforced across such places. And our

goal is to build better software and avoid bugs that can be avoided, not 
sure. I dont actually care that much how it's solved - via extending the

concept of varargs or via working it around where it hurts most. What

matters is that the current situation is suboptimal. The present

"solution" uglifies the code and more ugly code is always more

dangerous.
But it's even worse: bogus warnings also reduce the psychological

threshold to adding stupid casts - if you have to add casts in a printk

that looks senseless then why not circumvent _other_ warnings that look

senseless?
Excessive false positives are actively harmful to software quality

because they teach people to ignore warnings.
	Ingo

--

GCC format string checking is only about warnings, GCC never modifies

the arguments passed to make them match the format string conversions.
	Jakub

--

Actually, how hard would it be to allow new modifiers recognized by

format string checking?  Hell, even being able to teach it that (in this

family of functions) "%<d>u" should expect dma_addr_t, "%016<64>x" -

u64, etc. would solve all the problems.  Ideally we'd need something

for things like IPv4 address (__be32 expected), IPv6 address (taking

__be32 *), etc.
No magic, usual calling conventions - it'd still remain a valid C.

We can do that in sparse and just tell gcc to STFU about these warnings,

of course, but that's kind of things that is probably wanted by userland

projects as well...
BTW, ISTR FreeBSD folks carrying gcc patches in their tree for something

with similar purpose - project-specific format modifiers/specifiers.

No idea how hard it would be to generalize, though - never looked at

those in details...

--

From: Al Viro <viro@ZenIV.linux.org.uk>
You might be thinking of:
	http://www.stack.nl/~marcolz/FreeBSD/gcc-printf.patch

--

trace selftest build fails when CONFIG_RT_MUTEXES=n:
next-20080410/kernel/trace/trace_selftest.c:413: error: implicit declaration of function 'rt_mutex_setprio'

make[3]: *** [kernel/trace/trace.o] Error 1
Possible fixes:
kernel/trace/Kconfig: SCHED_TRACER can depend on RT_MUTEXES

or there can be a stub for rt_mutex_setprio() when RT_MUTEXES=n
And kernel/trace/trace_selftest.c still needs #include <sched.h> added to it.
---

~Randy

--

Hello Stephen,
	The commit b818da52 makes my sparc64 box simply unable to boot.

You should probably take a look at other arches as well. The story is here:
http://lkml.org/lkml/2008/3/28/465

http://lkml.org/lkml/2008/4/1/248
	Mariusz

--

Hi Greg,
On Thu, 10 Apr 2008 21:34:00 +0200 Mariusz Kozlowski <m.kozlowski@tuxland.p=
This patch has remained unchanged since first imported into linux-next in

March 6.
So, the question is: What are the consequences of reverting it?  I am not

in a position to judge, but if it causes boxes to simply not boot, then

it would be a major regression in 2.6.26 and simply cannot be included

there.
I will revert it at the end of today's tree and hope that there is some

resolution before the merge window opens.
Of course, there is still the question of the other architectures ...
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

Yes, I haven't caught up with my emails, but yes, this will not go

upstream for those arches that have had problems with it (like sparc64).

I'll fix my tree up first thing Monday morning for this issue.
Sorry for taking so long with it, been stuck doing other things...
thanks,
greg k-h

--

Hi Greg,
Thanks.  I will look for it tomorrow.
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

Hi Stephen,
When booting the x86_64 boxes with the next-20080409 and 20080410 kernels

the kernel bug is hit. The same bug was reported for the April 9  kernel

at http://lkml.org/lkml/2008/4/10/63 (this kernel was compiled with

CONFIG_CC_STACKPROTECTOR is not set)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000

IP: [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130

PGD 32dc2e067 PUD 32dd6a067 PMD 0

Oops: 0000 [1] SMP

last sysfs file: /sys/kernel/uevent_seqnum

CPU 0

Modules linked in: sg

Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080410-autotest #1

RIP: 0010:[<ffffffff802869b1>]  [<ffffffff802869b1>] kmem_cache_alloc+0x41/0x130

RSP: 0000:ffff810bfe4abef8  EFLAGS: 00010046

RAX: 0000000000000000 RBX: ffff81090e4aa050 RCX: 0000000000405017

RDX: 00007ffffb4c05b8 RSI: 00000000000000d0 RDI: 0000000000000000

RBP: 0000000000000292 R08: 0000000000586f00 R09: 0000000000586f20

R10: 0000000000586f08 R11: 0000000000000246 R12: 00000000000000d0

R13: 0000000000000000 R14: 0000000000405150 R15: 0000000000000000

FS:  000000000058b850(0063) GS:ffffffff8067f000(0000) knlGS:0000000000000000

CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b

CR2: 0000000000000000 CR3: 000000090d0e6000 CR4: 00000000000006e0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

Process init (pid: 1, threadinfo ffff810bfe4aa000, task ffff81090e4aa050)

Stack:  0000000000000000 ffff81090e4aa050 ffff81090e4aa050 0000000000000001

 0000000000405110 ffffffff80212f96 0000000000000292 ffff81090e4aa050

 00007ffffb4c05a8 ffffffff8020cb79 0000000000000000 ffffffff804da339

Call Trace:

 [<ffffffff80212f96>] init_fpu+0x96/0xf0

 [<ffffffff8020cb79>] math_state_restore+0x19/0x60

 [<ffffffff804da339>] error_exit+0x0/0x51
Code: 48 89 6c 24 10 49 89 fd 9c 5d fa 65 48 8b 04 25 00 00 00 00 f7 40 14 00 00 00 12 0f 85 b6 00 00 00 65 8b 04 25 24 00 00 00 89 c0 <49> 8b 54 c5 00 8b 02 85 ...
[ message continues ]

I noticed in another thread, that you are using gcc 4.1.1. I think

both 4.1.0 and 4.1.1 has some issues with weak symbols. Can you please

try gcc 4.1.2 and see if that fixes your issue.
When I go back to 4.1.0, I am bitten by smilar oops. But not with 4.1.2.
thanks,

suresh

--

Hi,
When I tried reproducing the problem on another machine with gcc 4.1.2, the goes into a loop with

the following call trace. Will try and reproduce on the same machine, which was causing the panic.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 2.6.25-rc8-next-20080411-autokern1 (root@elm3b63.beaverton.ibm.com) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-41)) #1 SMP PREEMPT Mon Apr 14 08:31:54 EDT 2008

.

.

.

<snip>

.

.

[    3.059347] request_module: runaway loop modprobe binfmt-464c

[    3.065238] request_module: runaway loop modprobe binfmt-464c

[    3.071106] request_module: runaway loop modprobe binfmt-464c

[    3.077242] request_module: runaway loop modprobe binfmt-464c

[    3.085556] request_module: runaway loop modprobe binfmt-464c

[    3.169430] khelper used greatest stack depth: 2884 bytes left

[    3.224149] khelper used greatest stack depth: 2864 bytes left

[    3.358136] khelper used greatest stack depth: 2844 bytes left

[    3.384146] khelper used greatest stack depth: 2780 bytes left

[    3.692012] khelper used greatest stack depth: 2744 bytes left

[    4.470665] khelper used greatest stack depth: 2716 bytes left

[    4.714540] khelper used greatest stack depth: 2700 bytes left

[    5.632645] khelper used greatest stack depth: 2616 bytes left

[   37.306789] khelper used greatest stack depth: 2596 bytes left

[  279.173966] INFO: task swapper:1 blocked for more than 240 seconds.

[  279.180375] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[  279.188421] swapper       D 00000001  2376     1      0

[  279.196385]        f7844cc0 00000046 f7844c78 00000001 c06ed24c f7880000 f7846000 f7846190

[  279.205829]        c4ab1700 00000007 00000000 fffeddc1 c0511054 373dd61a 000000ab ffffffff

[  279.215036]        ffffffff ffffffff ffffffff 00000000 00000000 00000000 7fffffff 7fffffff

[  279.224236] Call Trace:

[  279.227087]  [<c03c2c36>] schedule_timeout+0x16/0x8b

[  279.233650]  [<c023f674&g...
[ message continues ]

Very nice, thanks for the summary, I appreciate it.
greg k-h

--

Hi Stephen,
The next-20080410 kernel panics while bootup over the PowerMac G5 box, while

loading the ATA driver.
[    3.704000] Faulting instruction address: 0xc0000000000222a8

[    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]

[    3.704000] SMP NR_CPUS=32 NUMA PowerMac

[    3.704000] Modules linked in:

[    3.704000] NIP: c0000000000222a8 LR: c00000000021cd10 CTR: 0000000000000100

[    3.704000] REGS: c0000002760db070 TRAP: 0300   Not tainted  (2.6.25-rc8-next-20080410-autokern1)

[    3.704000] MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 44000042  XER: 20000000

[    3.704000] DAR: a0001000822fa000, DSISR: 0000000040000000

[    3.704000] TASK = c0000002760d7100[1] 'swapper' THREAD: c0000002760d8000 CPU: 0

[    3.704000] GPR00: 0000000000000100 c0000002760db2f0 c000000000498310 a0001000822fa000

[    3.704000] GPR04: c000000274806a00 0000000000000100 0000000000000201 c00000000000fed4

[    3.704000] GPR08: c0000002760daf20 c0000000003ee0d8 c0000000004f1428 0000000000000000

[    3.704000] GPR12: 0000000000000000 c0000000003fa700 0000000000000000 0000000000000000

[    3.704000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000

[    3.704000] GPR20: 0000000000000001 0000000000000027 0000000000000027 0000000000000000

[    3.704000] GPR24: c0000000004f1400 0000000000000000 0000000000000201 c0000000004f1490

[    3.704000] GPR28: a0001000822fa000 0000000000000200 c00000000044cf50 c000000274806a00

[    3.704000] NIP [c0000000000222a8] ._insw_ns+0x10/0x30

[    3.704000] LR [c00000000021cd10] .ata_input_data+0x1f4/0x264

[    3.704000] Call Trace:

[    3.704000] [c0000002760db2f0] [c0000002760d7100] 0xc0000002760d7100 (unreliable)

[    3.704000] [c0000002760db3b0] [c00000000021fc34] .try_to_identify+0x298/0x690

[    3.704000] [c0000002760db470] [c000000000220168] .do_probe+0x13c/0x2f0

[    3.704000] [c0000002760db510] [c00000000022059c] .ide_probe_port+0x280/0x670

[    3.704000] [c0000002760db5e0] [c000000000220d84] .ide_device_add_all+0x2f8/0x670

[...
[ message continues ]

Hi,
On Thu, Apr 10, 2008 at 12:24 PM, Kamalesh Babulal
Could you please add printk() for 'hwif->host_flags', 'mmio' and 'io_32bit'

to ide-iops.c::ata_input_data() so we know more on what is going on?
Thanks,

Bart

--

No longer needed - please test the hot-fix below instead:
---

thanks to Andrew for noticing me about the gcc warning
 drivers/ide/ppc/pmac.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ide/ppc/pmac.c

===================================================================

--- a/drivers/ide/ppc/pmac.c

+++ b/drivers/ide/ppc/pmac.c

@@ -941,7 +941,7 @@ static const struct ide_port_info pmac_p

 	.port_ops		= &pmac_ide_port_ops,

 	.host_flags		= IDE_HFLAG_SET_PIO_MODE_KEEP_DMA |

 				  IDE_HFLAG_POST_SET_MODE |

-				  IDE_HFLAG_UNMASK_IRQS,

+				  IDE_HFLAG_UNMASK_IRQS |

 				  IDE_HFLAG_MMIO,

 	.pio_mask		= ATA_PIO4,

 	.mwdma_mask		= ATA_MWDMA2,
--

Thanks, the kernel panic is solved after applying the patch.
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

--

Thanks.
I integrated the fix with the guilty patch and pushed it to IDE tree

(Andrew, you may drop the revert-patch now).
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Subject: [PATCH] ide: add IDE_HFLAG_MMIO host flag (take 2)
* Add IDE_HFLAG_MMIO host flag and set it for hosts which use

  default_hwif_mmiops().
v2:

* Fix kernel panic in pmac host driver (',' should be '|').
  Thanks to Kamalesh for reporting it + testing the fix

  and to Andrew for hinting me about the source of the issue.
Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

Cc: Andrew Morton <akpm@linux-foundation.org>

Cc: Stephen Rothwell <sfr@canb.auug.org.au>

Cc: Andy Whitcroft <apw@shadowen.org>

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

---

 drivers/ide/arm/icside.c          |    2 +-

 drivers/ide/arm/palm_bk3710.c     |    1 +

 drivers/ide/arm/rapide.c          |    1 +

 drivers/ide/legacy/ide_platform.c |    4 +++-

 drivers/ide/mips/swarm.c          |    1 +

 drivers/ide/pci/sgiioc4.c         |    1 +

 drivers/ide/pci/siimage.c         |    1 +

 drivers/ide/ppc/pmac.c            |    1 +

 include/linux/ide.h               |    2 ++

 9 files changed, 12 insertions(+), 2 deletions(-)
Index: b/drivers/ide/arm/icside.c

===================================================================

--- a/drivers/ide/arm/icside.c

+++ b/drivers/ide/arm/icside.c

@@ -481,7 +481,7 @@ static const struct ide_port_info icside

 	.init_dma		= icside_dma_off_init,

 	.port_ops		= &icside_v6_no_dma_port_ops,

 	.dma_ops		= &icside_v6_dma_ops,

-	.host_flags		= IDE_HFLAG_SERIALIZE,

+	.host_flags		= IDE_HFLAG_SERIALIZE | IDE_HFLAG_MMIO,

 	.mwdma_mask		= ATA_MWDMA2,

 	.swdma_mask		= ATA_SWDMA2,

 };

Index: b/drivers/ide/arm/palm_bk3710.c

===================================================================

--- a/drivers/ide/arm/palm_bk3710.c

+++ b/drivers/ide/arm/palm_bk3710.c

@@ -342,6 +342,7 @@ static const struct ide_port_ops palm_bk

 static c...
[ message continues ]

Regards,
	Jeff
--

On Thu, 10 Apr 2008 06:45:28 -0400
Jeff - we may in the kernel world use IDE v ATA to distinguish between

the two drivers but both are still ATA drives and I don't think its too

fair to respond this way, especially to someone who has gone to the

trouble of capturing a very good trace.
Alan

--

Sure.  The main goal was to copy Bart and linux-ide.  That was just an

aside.
	Jeff
--

Hi Jeff,
Looking at the boot log before the kernel oops, I suspected it to be the ide driver causing

the kernel oops, I am trying reproduce the crash with debug info compiled into the kernel.
[    2.236136] Uniform Multi-Platform E-IDE driver

[    2.248211] ide-pmac 0001:03:0d.0: enabling device (0014 -> 0016)

[    3.284006] ide0: Found Apple K2 ATA-6 controller, bus ID 3, irq 39

[    3.700012] Unable to handle kernel paging request for data at address 0xa0001000822fa000

[    3.704000] Faulting instruction address: 0xc0000000000222a8

[    3.704000] Oops: Kernel access of bad area, sig: 11 [#1]

[    3.704000] SMP NR_CPUS=32 NUMA PowerMac

--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

--