Linus, please pull the latest x86 git tree from:
    git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
Find the shortlog attached below.
Most of the changes we have described here:
    http://lkml.org/lkml/2008/1/21/230
It's not a small merge, it consists of 908 commits from 96 individual

arch/x86 developers (!):
    671 files changed, 42791 insertions(+), 38967 deletions(-)
so here are a few highlevel comments as well, in addition to the

shortlog:
- a number of core files are changed as well: most notably percpu,

  debugging details, timers, the firewire remote debugging patch and ...

  the KGDB remote debugging stub in kernel/kgdb.c.
- we tested KGDB to be merge-worthy within the x86 architecture (the

  only supported architecture for now) and it's better to have

  kernel/kgdb.c than arch/x86/kernel/kgdb.c. The code is reasonably

  clean and the user-space exposure is small - the only real exposure is

  the decades-old remote GDB protocol. We are happy to fix up any

  further cleanliness comments that people might have - but we really

  wanted to start somewhere and get this thing moving. As an added

  bonus: finally a kernel debugger that can be read without puking too

  much ;-) [anyone remember KDB?]
- the core timer and genirq changes are pushed via x86.git for

  convenience reasons, we tested them inside x86.git for a long time.
- the module loader bits have been seen and acked by Rusty - work is

  going on in parallel to make those bits cleaner, but they are no

  merge-stopper for him now.
- the ptrace/regset bits from Roland are tied to x86 regset support and

  affect no other architecture. (but they enable easy regset merging for

  other architectures in the future)
- the lockbreak cleanup patches are tied to the ticket spinlocks and big

  ticket spinlocks - hence the changes to fs/*.
- the changes to agp drivers are mechanic, due to the CPA API cleanups

  and fixes. Behavior is not supposed to change, a num...
[ message continues ]

cc503c1b "x86: PIE executable randomization" doesn't boot on my Ubuntu

Feisty Fawn Intel Core2 system.
I get numerous segfaults before getting a (initramfs) busybox shell. A

similar bug was reported much earlier:
http://lkml.org/lkml/2007/7/20/421
Sadly, reverting this (or all of the PIE patches) results in a lot of

conflicts now with git-revert too failing, mainly in

arch/x86/mm/mmap_64.c.
--

Amit Shah

http://www.amitshah.net/

--

[ please, when you experience a problem and are able to identify the

commit that triggers it, don't forget to CC the author of the commit in

question -- me, in this case ]
As far as I remembers, Ubuntu uses klibc in initramfs, right?
What version of klibc do you have? There was a bug in klibc that causes

such behavior on PIE-randomization-enabled kernels, and has been fixed in

klibc-1.45 by commit [1]. Please make sure you have updated klibc version

that doesn't contain this bug.
[1] http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe...
--

Jiri Kosina

--

--

Amit Shah

http://www.amitshah.net/

--

so your problem was resolved by an updated klibc version?
	Ingo

--

Yes, it was. I downloaded the sources from the gutsy repo (which is version 1.5)
--

Amit Shah

http://www.amitshah.net/

--

The x86 tree was merged several times, but I don't see kgdb included in

latest mainline -git.
So just one question, will it be included or no?
Best regards,

	Maxim Levitsky

--

I won't even consider pulling it unless it's offered as a separate tree,

not mixed up with other things. At that point I can give a look.
That said, I explained to Ingo why I'm not particularly interested in it.

I don't think that "developer-centric" debugging is really even remotely

our problem, and that I'm personally a lot more interested in

infrastructure that helps normal users give better bug-reports. And kgdb

isn't even _remotely_ it.
So I'd merge a patch that puts oops information (or the whole console

printout) in the Intel management stuff in a heartbeat. That code is

likely much grottier than any kgdb thing will ever be (Intel really

screwed up the interface and made it some insane XML thing), but it's also

fundamentally more important - if it means that normal users can give oops

reports after they happened in X (or, these days, probably more commonly

during suspend/resume) and the machine just died.
kgdb? Not so interesting. We have many more hard problems happening at

user sites, not in developer hands.
		Linus

--

The other problem with the current kgdb code is that it has some serious

problems. e.g. it reinvents various kernel interfaces that already

exist -- one example is that it adds new notify_die()s just to reimplement

the standard __ex_table exceptions in a bogus way.

Couple of other issues. So even if it was a good idea to merge the

code is not really fully in merge shape anyways.
-Andi

--

/me was once wondering as well why kgdb installs a seconds way of

handling (its own) faults. Jason explained to me that this approach is

more robust against corruption along the normal fix-up path. Maybe he

can elaborate better than I why this is useful (or what real-life bug
If you recall the issues (and they are still present), it would be nice

to have them listed. kgdb suffered a lot from historic cruft, but we

already remove at least some of it over the last patching rounds.

Whatever remains should be addressed ASAP.
Jan
--

Siemens AG, Corporate Technology, CT SE 2

Corporate Competence Center Embedded Linux

--

I sent Jason a couple of mails last time when he posted (and before that the

previous maintainer when he tried to merge it).   All were

fairly "beratungsresistent".
If you're truly interested i can dig out the mails or do a fresh review.
Long ago I did a quite clean x86-64 kgdb for Linux 2.4 based on the

old 2.4 stub that dropped in without any strange other hooks

(except for a straight forward change to the serial code). It worked

just fine this way.
-Andi
--

Well, let's try it this way: Find below a patch against kgdb.git that

removes the special fault handling (this wouldn't be the first feature I

recently removed from kgdb :->). Light testing revealed no obvious

problems yet.
Jason, please tell us what problems this could cause. I just dug out the

reply you sent me regarding this last year, and you specifically

mentioned non-recoverable unaligned accesses by gdb on MIPS. Is this

still true? Is there no way to handle this particular arch separately

and leave the rest happily with what the kernel already provides?
Jan
----snip----
As the kernel already provides the infrastructure to carefully access

potentially bogus memory locations, kgdb does not need to maintain its

own, complex, arch-dependent mechanism.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
---

 arch/x86/kernel/Makefile      |    2

 arch/x86/kernel/kgdb-jmp_32.S |   74 ------------------------

 arch/x86/kernel/kgdb-jmp_64.S |   65 ---------------------

 arch/x86/kernel/kgdb.c        |    5 -

 include/asm-x86/kgdb.h        |    6 --

 include/linux/kgdb.h          |   27 ---------

 kernel/kgdb.c                 |  125 ++++--------------------------------------

 7 files changed, 16 insertions(+), 288 deletions(-)
Index: b/arch/x86/kernel/Makefile

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

--- a/arch/x86/kernel/Makefile

+++ b/arch/x86/kernel/Makefile

@@ -58,7 +58,7 @@ obj-$(CONFIG_MODULES)		+= module_$(BITS)

 obj-$(CONFIG_ACPI_SRAT) 	+= srat_32.o

 obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o

 obj-$(CONFIG_DOUBLEFAULT) 	+= doublefault_32.o

-obj-$(CONFIG_KGDB)		+= kgdb.o kgdb-jmp_$(BITS).o

+obj-$(CONFIG_KGDB)		+= kgdb.o

 obj-$(CONFIG_VM86)		+= vm86_32.o

 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
Index: b/arch/x86/kernel/kgdb-jmp_32.S

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

--- a/arch/x86/kernel/kgdb-jmp_32.S

+++ /dev/null

@@ -1,74 +0,0 @@

-/*

- * arch/x86/kernel/kgdb...
[ message continues ]

That is indeed horrible code. No way will I merge anything that has things

like that even in it's *history* (ie somebody needs to re-generate the

tree without code like that - some things should not be allowed to exist).
That said, while just using "probe_kernel_addr()" is certainly much

better, it's still really inefficient. If you actually want to do a "safe

memory copy", then the right way to do that is basically to do
	pagefault_disable();

	leftover = __copy_from_user_inatomic(dst, src, count);

	pagefault_enable();
	if (leftover)

		handle_the_fact_that_the_copy_didnt_complete();
which should even be reasonably efficient and should work in all contexts

(hardware interrupts disabled, spinlocks held, you name it).
So all those "kgdb_{get|set}_mem()" things seem bogus (they also have

insane calling semantics - return NULL or errptr? Why not just return an

integer error code?
		Linus

--

I concur.  I will collapse the entire kgdb tree back to the original few
Duly Noted.  Further cleanups are in progress.
Thanks,

Jason.

--

Hi Linus,
If you listen carefully you can hear dozens of Linux kernel developers

collectively holding their breath and thinking "Maybe Linus will

finally merge kgdb".  Yes, user bug reports are important.  Developer

efficiency is important too.
Regards,
Daniel

--

>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
Linus> I won't even consider pulling it unless it's offered as a

Linus> separate tree, not mixed up with other things. At that point I

Linus> can give a look.
Linus> That said, I explained to Ingo why I'm not particularly

Linus> interested in it.  I don't think that "developer-centric"

Linus> debugging is really even remotely our problem, and that I'm

Linus> personally a lot more interested in infrastructure that helps

Linus> normal users give better bug-reports. And kgdb isn't even

Linus> _remotely_ it.
Linus> So I'd merge a patch that puts oops information (or the whole

Linus> console printout) in the Intel management stuff in a

Linus> heartbeat. 
How about we put in some sort of console logging tool so we can buffer

and log the console output better?  Currently if I have both a serial

and tty console defined, my GDM prompter looses the mouse until I goto

the XDMCP chooser and back again.  
I'm pretty sure it's a GDM problem, since Xdm doesn't have this issue

at all.  Haven't had time to chase it though.
In any case, having some way to log oopses better would be really

nice.  Not sure how we could do it reliably for suspend/resume needs

on laptops without dedicated management hardware like the ILOM stuff

on Intel/Sun boxes.  
Dunno... just viocing my desires...

John

--

Hm.  Dumping oops information plus perhaps even a memory dump to a USB

key sounds like it would be highly useful - lots of storage capacity,

readily available, and can be plugged into just about any system.
I don't know if the backdoor debugging mode in EHCI can be used for

that.  Either way, this would have to be done *very* carefully to avoid

clobbering USB devices not intended for this purpose.
	-hpa

--

If the machine can be hooked up over FireWire to another Linux box, you can

use the OHCI1394 controller's "physical DMA" feature to get lots if info:
What you need:
- An OHCI1394-compliant (nearly all are) FireWire port in the oopsing system

- A second Linux system (with other tools also other OS) with any FireWire port

- A FireWire cable which connects the two ports (there are two kinds of plugs)

- ftp://ftp.suse.de/private/bk/firewire/tools/firescope-0.2.2.tar.bz2
What you do:
1 - You boot both systems and connect them with the FireWire cable

2 - You initialize FireWire on both systems and ensure that 'physical DMA'

    is enabled in the OHCI1394-compliant FireWire controller of the oopsing

    machine.

3 - You transfer the System.map of the debugged kernel to the second system.
    - Everything after this point does not need the cooperation of the CPU

      of the debugged system, the PCI bus needs to be working and unlocked,

      but the CPU(s) of the debugged system can otherwise do anything or

      nothing at all anymore.
4 - You trigger the oops/crash/hang, but leave the debugged machine turned on.

5 - You install firescope (URL in the list above) on the second machine and

    run it for example with:
       firescope -A System.map-of-debugged-kernel
6) you press Ctrl-D (this is just one way to do it)
What you get are the contents of the printk buffer containing the messages

which the kernel logged into the in-memory printk buffer (such as oopses)

- directly from the other machine's RAM over remote DMA (which is called

  "physical DMA" in FireWire language)
Of course you can put firescope into "auto update mode" and just watch or

log the printk buffer as it gets messages on the remote system - in real time.
--------------------------------------------------------------------------
There is new code in mainline now to debug early boot issues:
If the oops/hang/crash happens early in boot, before the normal ohci1394 kernel

driver can initialize the ...
[ message continues ]

...
To be precise, firewire-sbp2 tells firewire-ohci to open up the physical

response unit (which implements the remote DMA feature) for the target

node from when it tries the SBP-2 login until when it completes the

SBP-2 logout or the target is plugged out.  Let's call it filtered

physical DMA.
A mode which doesn't require the physical response unit could be

implemented in firewire-sbp2, but this would come with a considerable

overhead regarding code, runtime CPU usage due to huge interrupt

handling load, and additional runtime memory footprint.
The older sbp2 driver relies on unfiltered physical DMA, hence is less

secure.  There can be a mode selected at compile time to run without

physical DMA, but that's buggy and implemented in a way which is not

portable.
The only reason why we don't have an SBP-2 initiator which works without

remote DMA is that nobody is bothered enough to either debug that mode

in the old driver or implement it in the new driver.  Besides, we could

rather trivially add filtered physical DMA to the old

...
x86 BIOSes don't initialize OHCI-1394 controllers up to the point that

its physical response unit were working remote nodes were granted access

to it.
Apple's OpenFirmware implements SBP-2 initiator but I don't know if it

uses the physical response unit.  But this point is moot --- you can

boot from SBP-2 targets.

--

Stefan Richter

-=====-==--- --=- -=---

http://arcgraph.de/sr/

--

FWIW, I'm not a fulltime developer by any means, but on occasion

I have fixed a few bugs in the netfilter area of the kernel.

And in almost all cases, I used kgdb in my debugging and testing

of fixes.  
In doing so, it was a bit of a PITA to find/patch kgdb into the

kernel, and having it as a configurable option would have saved

me some time and effort and made the process much smoother.
So perhaps someone else out there would find it similarly useful,

and the extra time it takes to find/patch/compile kgdb in is

precluding them from participating?  Why would we ever want to do

that?
Phil

--

Just as a note I find it extremly useful in some case to be able

to run gdb on a kernel.  As said by Andrew it's less the tradition

debugging but more to get a picture of what's going on.
But kgdb traditionally was more than just a simple gdb stub and

contained hooks all over the place for additional functionality.

I don't think all this is a good idea and I'd be against it.
I'd be really happy to see a common gdb stub with small arch support

that allows attaching gdb to the kernel through various transports.
Maybe someone is up to do just that?  Even the full blown kgdb with

all the hooks would benefit from having the gdb stub already in,

so maybe I could motivate some kgdb developers to do that work?

--

Hi Christoph,
For sure, every small step forward will help.
Maybe you could have a look at current kgdb.git at kernel.org and

comment on what you would like to see in a first submission round, what

kind of hooks, specifically regarding the core, are not yet in an

acceptable state, and so forth. We will listen.
TiA,

Jan
--

Siemens AG, Corporate Technology, CT SE 2

Corporate Competence Center Embedded Linux

--

I used kgdb continuously for 4-5 years until it broke.  I don't think I

ever used it much for "debugging" as such.  I used it more for general

observation of what's going on in the kernel.  And for _confirmation_ of

what's going on (ie: testing that the actual state matches the expected

state).
I'd end up doing my development with the assumption that kgdb was present.

One example: rather than putting printks all over the place to ensure that

the right thing was happening at the right time I'd instead add code like
void foo(void)

{

}
	...

	if (expr)

		foo();
then, when the testcase was up and running and in steady state, break in

and put a breakpoint on foo().  Continue, wait for the breakpoint then go

in and observe locals, globals, data structures, etc.
It's hard to describe (and remember!).  But the presence of the debugger as

a development (not debugging) tool changes the way you do development a bit.

--

I can also underline this - and add the aspect that a kernel debugger

may also nicely serve to explore tricky code paths interactively. This

specifically can lower the entrance barrier to complex kernel subsystems

for new developers/bug hunters.
With the latest changes, now all available through Jason's git repos for

2.6.25, kgdb should be usable again ("Now even more stable than ever!"

;) ). It became much less invasive towards critical code paths during

recent rounds of refactoring, so we can hopefully meet the requirements

for merging it upstream soon (2.6.26?).
While too many people consider a debugger as _the_ tool for kernel

development, which it clearly isn't, it remains a fairly useful feature,

and I don't see any regression, technically or organizationally, it may

introduce to Linux. IMHO, it would be a pity if kgdb have to remain out

off tree and may potentially fall back at quality levels that many of us

had fought with in the past.
Jan
--

Siemens AG, Corporate Technology, CT SE 2

Corporate Competence Center Embedded Linux

--

I do pretty much all my debugging with printk, not just because it is a

pain to go find a working kgdb patch, but also because tools like uml

make printk style debugging really fast.  That said, I often find my

development time sinking away into tedious activity like putting in a

printk after each line of code, just to find out where some bad thing

started going bad.  At that point a source level debugger would save me

a bunch of time and I would not have to remove the printks afterwards.  
However, if the time required to patch the kernel with kgdb is more than

the time spent putting in prinks then I will just grit my teeth and put

in the printks.  Never mind that I will end up going through the printk

insertion process many times, while only needing to apply the kgdb

patch once.  Ahem, that is once per kernel version, and I change kernel

versions like I change socks (that means "often" for the wags among

you.)
One thing I like to do with a source level debugger besides debugging is

take a walk once through some new algorithm I have implemented.  Not

because I think there is a bug, but more for the same reason that I

like to do a side by side walkthrough of new code with another

developer before ever running it.  This just provides a different

perspective, so that perhaps some little blemishes, inefficiencies and

redundancies will show themselves, and the code quality usually

improves because of it.
Not that this is the only way I review my own code, it is just another

way.  More ways of reviewing code are better.  In this sense, the

debugger is like a mechanical friend who always has time available to

join in a side by side code review.
Regards,
Daniel

--

You tested x86 but broke more than half a dozen other archtectures,

with at least 3 different commits breaking other architectures.
It now takes a few days until this mess is completely sorted out, and I

hope there won't be too many poor souls having to bisect 2.6.25-rc1

regresions on !x86 since this can now become the pure horror.
And if people give up trying to bisect 2.6.25 might ship with more

regressions.
I already said in the past that the x86 tree contains not architecture

specific stuff that doesn't belong there, and looking at the following

parts of the diffstat, most of it does simply not belong into an

--

Note that all known breakages are fixed in current -git, except for the

s390 problem that Martin/Nick posted the fix.
	Ingo

--

What about the breakages caused by commit

a5a19c63f4e55e32dc0bc3d936d7f94793d8b380 (this commit broke the

defconfig compilation on at least avr32, blackfin, sh, sparc and uml)?
This commit touched two different not x86 specific headers, and both of 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

the patch below fixes that.
	Ingo
---

 include/asm-generic/tlb.h |    1 +

 1 file changed, 1 insertion(+)
Index: linux/include/asm-generic/tlb.h

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

--- linux.orig/include/asm-generic/tlb.h

+++ linux/include/asm-generic/tlb.h

@@ -15,6 +15,7 @@
 #include <linux/swap.h>

 #include <linux/quicklist.h>

+#include <asm/pgalloc.h>

 #include <asm/tlbflush.h>
 /*

--

I just send the same patch[1] minutes ago. ;-)
1. http://lkml.org/lkml/2008/1/31/223
--

The sparc breakage (might not have been reported until now and I

bisected it just a few minutes ago) is caused by the following part of

commit a5a19c63f4e55e32dc0bc3d936d7f94793d8b380:
--- a/include/linux/swap.h

+++ b/include/linux/swap.h

@@ -6,6 +6,7 @@

 #include <linux/mmzone.h>

 #include <linux/list.h>

 #include <linux/sched.h>

+#include <linux/pagemap.h>
 #include <asm/atomic.h>

 #include <asm/page.h>
The compile error with the sparc defconfig is:
<--  snip  -->
...

  CC      init/main.o

In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/highmem.h:24,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/pagemap.h:10,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swap.h:9,

                 from include2/asm/pgtable.h:15,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/mm.h:39,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/asm-generic/dma-mapping.h:17,

                 from include2/asm/dma-mapping.h:6,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/dma-mapping.h:52,

                 from include2/asm/sbus.h:10,

                 from include2/asm/dma.h:13,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/bootmem.h:8,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/init/main.c:26:

include2/asm/highmem.h: In function 'kmap':

include2/asm/highmem.h:60: error: implicit declaration of function 'PageHighMem'

include2/asm/highmem.h:61: error: implicit declaration of function 'page_address'

include2/asm/highmem.h:61: warning: return makes pointer from integer without a cast

In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swap.h:9,

                 from include2/asm/pgtable.h:15,

                 from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/mm.h:39,

                 from...
[ message continues ]

Drat.  I added that because of
/* only sparc can not include linux/pagemap.h in this file

 * so leave page_cache_release and release_pages undeclared... */

#define free_page_and_swap_cache(page) \

	page_cache_release(page)

#define free_pages_and_swap_cache(pages, nr) \

	release_pages((pages), (nr), 0);
But I guess I overlooked the comment...
I guess the fix is to scatter linux/pagemap.h into the appropriate

places where these macros are used (asm-generic/tlb.h, for a start).
--

no. The fix is always to undo the damage ASAP, to keep the window of

breakage minimized.
Adrian, could you please check whether latest x86.git:
  git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
resolves the Sparc build failure you were seeing? All known issues are

fixed in it. (let me know if you know about more)
	Ingo

--

cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

thanks Adrian.
	Ingo

--

Yes, sorry about that.  Uninlining the asm-x86/pgalloc.h functions is

the right thing to do anyway.
    J

--

Is it safe, or why did Jeremy state in the commit
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

that is an x86.git complication alone, and only affects 32-bit PAE: it

is solved by the uninlining patch (that i've queued up to before the

asm-generic/tlb.h revert/fix).
	Ingo
------------->

Subject: x86: uninline __pte_free_tlb() and __pmd_free_tlb()

From: Ingo Molnar <mingo@elte.hu>
this also removes an include file dependency.
Signed-off-by: Ingo Molnar <mingo@elte.hu>

---

 arch/x86/mm/pgtable_32.c     |   19 +++++++++++++++++++

 include/asm-x86/pgalloc_32.h |   19 ++-----------------

 2 files changed, 21 insertions(+), 17 deletions(-)
Index: linux/arch/x86/mm/pgtable_32.c

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

--- linux.orig/arch/x86/mm/pgtable_32.c

+++ linux/arch/x86/mm/pgtable_32.c

@@ -376,3 +376,22 @@ void check_pgt_cache(void)

 {

 	quicklist_trim(0, pgd_dtor, 25, 16);

 }

+

+void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte)

+{

+	paravirt_release_pt(page_to_pfn(pte));

+	tlb_remove_page(tlb, pte);

+}

+

+void __pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)

+{

+	/* This is called just after the pmd has been detached from

+	   the pgd, which requires a full tlb flush to be recognized

+	   by the CPU.  Rather than incurring multiple tlb flushes

+	   while the address space is being pulled down, make the tlb

+	   gathering machinery do a full flush when we're done. */

+	tlb->fullmm = 1;

+

+	paravirt_release_pd(__pa(pmd) >> PAGE_SHIFT);

+	tlb_remove_page(tlb, virt_to_page(pmd));

+}

Index: linux/include/asm-x86/pgalloc_32.h

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

--- linux.orig/include/asm-x86/pgalloc_32.h

+++ linux/include/asm-x86/pgalloc_32.h

@@ -51,11 +51,7 @@ static inline void pte_free(struct page

 }
-static inline void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte)

-{

-	paravirt_release_pt(page_to_pfn(pte));

-	tlb_remove_page(tlb, pte);

-}

+extern void __pte_free_tlb(struct mmu_gather *tlb, struct page *pte);
 #ifdef CONFIG_X86...
[ message continues ]

Yes, that simplifies things a lot.
--

find below the s390 fix.
	Ingo
Index: linux/arch/s390/Kconfig

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

--- linux.orig/arch/s390/Kconfig

+++ linux/arch/s390/Kconfig

@@ -22,6 +22,9 @@ config RWSEM_GENERIC_SPINLOCK

 config RWSEM_XCHGADD_ALGORITHM

 	def_bool y
+config GENERIC_LOCKBREAK

+	def_bool y

+

 config ARCH_HAS_ILOG2_U32

 	bool

 	default n

--

<--  snip  -->
...

  CC      arch/s390/kernel/asm-offsets.s

In file included from

/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/s390/kernel/asm-offsets.c:7:

/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/sched.h: In function 'spin_needbreak':

/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/sched.h:1931: error: implicit declaration of function '__raw_spin_is_contended'

make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1
<--  snip  -->
Guilty commit:
Commit: 95c354fe9f7d6decc08a92aa26eb233ecc2155bf

Author: Nick Piggin <npiggin@suse.de> Wed, 30 Jan 2008 13:31:20 +0100 
    spinlock: lockbreak cleanup
    The break_lock data structure and code for spinlocks is quite nasty.

    Not only does it double the size of a spinlock but it changes locking to

    a potentially less optimal trylock.
    Put all of that under CONFIG_GENERIC_LOCKBREAK, and introduce a

    __raw_spin_is_contended that uses the lock data itself to determine whether

    there are waiters on the lock, to be used if CONFIG_GENERIC_LOCKBREAK is

    not set.
    Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to

    decouple it from the spinlock implementation, and make it typesafe (rwlocks

    do not have any need_lockbreak sites -- why do they even get bloated up

    with that break_lock then?).
    Signed-off-by: Nick Piggin <npiggin@suse.de>

    Signed-off-by: Ingo Molnar <mingo@elte.hu>

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Defining GENERIC_LOCKBREAK in arch/s390/Kconfig takes care of it. I'll

cook up a patch and queue it in git390.
--

blue skies,

  Martin.
"Reality continues to ruin my life." - Calvin.
--

the one below should do the trick.
	Ingo
----------------->

Subject: s390: enable GENERIC_LOCKBREAK

From: Ingo Molnar <mingo@elte.hu>
the recent need_lockbreak cleanups broke s390 build: enable

GENERIC_LOCKBREAK.
Signed-off-by: Ingo Molnar <mingo@elte.hu>

---

 arch/s390/Kconfig |    3 +++

 1 file changed, 3 insertions(+)
Index: linux/arch/s390/Kconfig

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

--- linux.orig/arch/s390/Kconfig

+++ linux/arch/s390/Kconfig

@@ -22,6 +22,9 @@ config RWSEM_GENERIC_SPINLOCK

 config RWSEM_XCHGADD_ALGORITHM

 	def_bool y
+config GENERIC_LOCKBREAK

+	def_bool y

+

 config ARCH_HAS_ILOG2_U32

 	bool

 	default n

--

Thanks but I already queued a different one (see below). The other

architectures that define GENERIC_LOCKBREAK have the "depends on SMP &&

PREEMPT" line as well. The line does make sense if you look at the way

how spin_is_contended is used, no ?
--

blue skies,

  Martin.
"Reality continues to ruin my life." - Calvin.
---

Subject: [PATCH] Define GENERIC_LOCKBREAK.
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Fix compile error:
  CC      arch/s390/kernel/asm-offsets.s

In file included from

arch/s390/kernel/asm-offsets.c:7:

include/linux/sched.h: In function 'spin_needbreak':

include/linux/sched.h:1931: error: implicit declaration of function

'__raw_spin_is_contended'

make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

---
 arch/s390/Kconfig |    5 +++++

 1 file changed, 5 insertions(+)
diff -urpN linux-2.6/arch/s390/Kconfig

linux-2.6-patched/arch/s390/Kconfig

--- linux-2.6/arch/s390/Kconfig	2008-01-31 13:57:33.000000000 +0100

+++ linux-2.6-patched/arch/s390/Kconfig	2008-01-31 13:57:42.000000000

+0100

@@ -47,6 +47,11 @@ config NO_IOMEM

 config NO_DMA

 	def_bool y
+config GENERIC_LOCKBREAK

+	bool

+	default y

+	depends on SMP && PREEMPT

+

 mainmenu "Linux Kernel Configuration"
 config S390
--

yes, you are right and your fix is the correct one. Currently, if we

define GENERIC_LOCKBREAK on UP then we get accesses to the non-existing

lock->need_lockbreak field.
[ btw., this is really a small uncleanliness in the generic code: it

  should be possible for an architecture to just enable

  GENERIC_LOCKBREAK unconditionally, to indicate that it intends to "let

  the generic code do this". Then the generic code, when it does not

  have a field (such as on UP), should just not access it. But this is a

  small detail. ]
	Ingo

--

ah, i see the one you queued up (below) is even better :)
	Ingo
------------->

Subject: [PATCH] Define GENERIC_LOCKBREAK.
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Fix compile error:
  CC      arch/s390/kernel/asm-offsets.s

In file included from

arch/s390/kernel/asm-offsets.c:7:

include/linux/sched.h: In function 'spin_needbreak':

include/linux/sched.h:1931: error: implicit declaration of function '__raw_spin_is_contended'

make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

---
 arch/s390/Kconfig |    5 +++++

 1 file changed, 5 insertions(+)
diff -urpN linux-2.6/arch/s390/Kconfig linux-2.6-patched/arch/s390/Kconfig

--- linux-2.6/arch/s390/Kconfig	2008-01-31 13:57:33.000000000 +0100

+++ linux-2.6-patched/arch/s390/Kconfig	2008-01-31 13:57:42.000000000 +0100

@@ -47,6 +47,11 @@ config NO_IOMEM

 config NO_DMA

 	def_bool y
+config GENERIC_LOCKBREAK

+	bool

+	default y

+	depends on SMP && PREEMPT

+

 mainmenu "Linux Kernel Configuration"
 config S390

--

thanks!
	Ingo

--

Yeah thanks, don't know what happened with this, sorry. I thought I

had defined it for all SMP capable ones, so maybe it was a quilt

error or something on my part.

--