So this hopefully continues closing various regressions, and most of the

changes are pretty small (ie diffstat shows a lot of oneliners). The

biggest patches are the trivial powerpc defconfig updates which show up

pretty clearly in the dirstat:
	  38.7% arch/powerpc/configs/

	  39.6% arch/powerpc/

	  42.9% arch/

	   2.4% drivers/ata/

	   7.6% drivers/block/

	   2.3% drivers/char/

	   2.0% drivers/message/fusion/

	   2.0% drivers/mmc/core/

	   4.1% drivers/net/

	   7.2% drivers/video/

	  38.0% drivers/

	   3.0% fs/hppfs/

	   7.8% fs/

	   2.8% kernel/

	   2.0% net/
ie if it weren't for those, the arch/ updates would hardly show up at all.

In the drivers, the two "big" changes are also totally trivial:

drivers/block/ shows up because of the ps2esdi driver removal (it's been

marked BROKEN for years), and drivers/video/ shows up because of a new

metronomefb.c driver for the E-Ink Metronome controller.
Apart from those, most of the changes really are fairly small and spread

out. The scheduler got some tweaking, the memstick driver got some TLC,

and cifs and reiserfs had some fixes.
The shortlog has more details, but it boils down to some reverts, some

docbook fixes, some sparse annotation fixups, a number of trivial patches,

and a healthy sprinkling of small fixups.
Give it a good testing, because we're hopefully now well on our way

towards that eventual real 2.6.25 release!
		Linus
---

Adrian Bunk (4):

      The ps2esdi driver was marked as BROKEN more than two years ago due to being

      make selinux_parse_opts_str() static

      V4L/DVB (7251): VIDEO_VIVI must depend on VIDEO_DEV

      V4L/DVB (7328): usb/opera1.c: fix a memory leak
Ahmed S. Darwish (2):

      smack: do not dereference NULL ipc object

      smackfs: remove redundant lock, fix open(,O_RDWR)
Akinobu Mita (1):

      [SCSI] a100u2w: fix bitmap lookup routine
Al Viro (21):

      r6040 endianness fixes

      wan/farsync: copy_from_user() to iomem is wrong

      fore2000 - fi...
[ message continues ]

Hello,
cat /proc/<pid>/pagemap 
and 
cat /proc/<pid>/task/<pid>/pagemap
eats up to 100% of CPU while looping forever somewhere. On the other

hand on my old x86 the same commands take well below 1s so I

guess that is the expected behaviour.
PS. I'll be offline till tommorow just in case I was sent some patches to test.
	Mariusz

From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
The patch below will speed this up for 32-bit processes but for 64-bit

ones it's still going to take a long time.
Cat'ing this file writes a 64-bit value for every possible page in the

task's address space, which for 64-bit is an enormous number of

entries.
This is not how this file is supposed to be used.  Programs are

supposed to inspect /proc/${PID}/maps, and use those ranges to lseek()

around the pagemap file and fish out the values they need.
This expensive operation is quite harmless, the process can still be

killed, it is not unstoppable.
commit c101b088ba0ed16d7109b2f3c2d16798d162a535

Author: David S. Miller <davem@davemloft.net>

Date:   Wed Mar 26 17:32:33 2008 -0700
    [SPARC64]: Define TASK_SIZE_OF()
    This make "cat /proc/${PID}/pagemap" more efficient for

    32-bit tasks.
    Based upon a report by Mariusz Kozlowski.
    Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/asm-sparc64/processor.h b/include/asm-sparc64/processor.h

index 8da484c..885b6a1 100644

--- a/include/asm-sparc64/processor.h

+++ b/include/asm-sparc64/processor.h

@@ -37,6 +37,9 @@

 #endif
 #define TASK_SIZE	((unsigned long)-VPTE_SIZE)

+#define TASK_SIZE_OF(tsk) \

+	(test_tsk_thread_flag(tsk,TIF_32BIT) ? \

+	 (1UL << 32UL) : TASK_SIZE)

 #ifdef __KERNEL__
 #define STACK_TOP32	((1UL << 32UL) - PAGE_SIZE)

--

I see. Sorry for the noise then 8-) I've got a couple of scripts for testing

/proc and /sys and I just noticed that some of processes started by them

would run for a couple hours eating 100% CPU which doesn't happen on other
This patch certainly helps in my case. Tested here:
sparc64 # time cat /proc/1/pagemap > /dev/null

real    0m0.046s

user    0m0.000s

sys     0m0.047s
Thanks,
	Mariusz

--

Hello,
I see lots of these messages on my ultra 60 box.
	Mariusz
$ uname -a

Linux sparc64 2.6.25-rc7 #2 SMP PREEMPT Wed Mar 26 11:25:23 CET 2008 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux
BUG: using smp_processor_id() in preemptible [00000000] code: init/1

caller is flush_tlb_pending+0xc/0xc0

Call Trace:

 [000000000044ad44] flush_tlb_pending+0xc/0xc0

 [00000000004b33b8] mprotect_fixup+0x3c0/0x480

 [00000000004cc4b4] setup_arg_pages+0x9c/0x320

 [0000000000505498] load_elf_binary+0x620/0x13a0

 [00000000004cb770] search_binary_handler+0xd8/0x300

 [00000000004cca88] do_execve+0x150/0x180

 [000000000042739c] sparc_execve+0x44/0xa0

 [0000000000406354] linux_sparc_syscall+0x3c/0x44

 [00000000004d381c] sys_dup+0x24/0x40

 [0000000000426fe0] init_post+0xa8/0x100

 [0000000000794418] kernel_init+0x260/0x360

 [0000000000427290] kernel_thread+0x38/0x60

 [000000000067f390] rest_init+0x18/0x80

BUG: using smp_processor_id() in preemptible [00000000] code: init/1

caller is flush_tlb_pending+0xc/0xc0

Call Trace:

 [000000000044ad44] flush_tlb_pending+0xc/0xc0

 [00000000004b33b8] mprotect_fixup+0x3c0/0x480

 [00000000004b359c] sys_mprotect+0x124/0x1e0

 [0000000000406314] linux_sparc_syscall32+0x3c/0x40

 [00000000f7f44bcc] 0xf7f44bd4

BUG: using smp_processor_id() in preemptible [00000000] code: init/1

caller is flush_tlb_pending+0xc/0xc0

Call Trace:

 [000000000044ad44] flush_tlb_pending+0xc/0xc0

 [00000000004b33b8] mprotect_fixup+0x3c0/0x480

 [00000000004b359c] sys_mprotect+0x124/0x1e0

 [0000000000406314] linux_sparc_syscall32+0x3c/0x40

 [00000000f7f492ec] 0xf7f492f4

BUG: using smp_processor_id() in preemptible [00000000] code: init/1

caller is flush_tlb_pending+0xc/0xc0

Call Trace:

 [000000000044ad44] flush_tlb_pending+0xc/0xc0

 [00000000004b33b8] mprotect_fixup+0x3c0/0x480

 [00000000004b359c] sys_mprotect+0x124/0x1e0

 [0000000000406314] linux_sparc_syscall32+0x3c/0x40

 [00000000f7f492ec] 0xf7f492f4

BUG: using smp_processor_id() in preemptible [00000000] code: init/1

call...
[ message continues ]

From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
This is a sparc64 bug.
To be honest I don't run with preemption enabled very often, but

I'll try to clear this up somehow.

--

From: David Miller <davem@davemloft.net>
And this patch should fix it:
commit 69072f6e8e4bd4799d2a54e4ff8771d0657512c1

Author: David S. Miller <davem@davemloft.net>

Date:   Wed Mar 26 04:25:00 2008 -0700
    [SPARC64]: Fix __get_cpu_var in preemption-enabled area.
    Reported by Mariusz Kozlowski.
    Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/arch/sparc64/mm/tlb.c b/arch/sparc64/mm/tlb.c

index 3f10fc9..a0f000b 100644

--- a/arch/sparc64/mm/tlb.c

+++ b/arch/sparc64/mm/tlb.c

@@ -23,10 +23,11 @@ DEFINE_PER_CPU(struct mmu_gather, mmu_gathers) = { 0, };
 void flush_tlb_pending(void)

 {

-	struct mmu_gather *mp = &__get_cpu_var(mmu_gathers);

+	struct mmu_gather *mp;
 	preempt_disable();
+	mp = &__get_cpu_var(mmu_gathers);

 	if (mp->tlb_nr) {

 		flush_tsb_user(mp);
--

that's an open-coded get_cpu_var().
fwiw.  Which isn't much, IMO.  Sometimes it's nice to see things open-coded.

--

From: Andrew Morton <akpm@linux-foundation.org>
Good point, I might restructure that to use {get,put}_cpu_var().

--

Ok it worked. Now I get a bunch of these:
BUG: using smp_processor_id() in preemptible [00000000] code: pidof/2471

caller is flush_ptrace_access+0xc0/0x1a0

Call Trace:

 [000000000042ef78] flush_ptrace_access+0xc0/0x1a0

 [00000000004ae6e4] access_process_vm+0x1ac/0x220

 [0000000000508e38] proc_pid_cmdline+0x60/0x120

 [000000000050acb8] proc_info_read+0x80/0xe0

 [00000000004c6fcc] vfs_read+0x74/0x120

 [00000000004c73cc] sys_read+0x34/0x60

 [0000000000406314] linux_sparc_syscall32+0x3c/0x40

 [00000000f7df5fe4] 0xf7df5fec
	Mariusz

--

From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Here ya go:
commit f6a843d939ade435e060d580f5c56d958464f8a5

Author: David S. Miller <davem@davemloft.net>

Date:   Wed Mar 26 04:51:12 2008 -0700
    [SPARC64]: flush_ptrace_access() needs preemption disable.
    Based upon a report by Mariusz Kozlowski.
    Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/arch/sparc64/kernel/ptrace.c b/arch/sparc64/kernel/ptrace.c

index bcf58ec..aaae865 100644

--- a/arch/sparc64/kernel/ptrace.c

+++ b/arch/sparc64/kernel/ptrace.c

@@ -70,6 +70,8 @@ void flush_ptrace_access(struct vm_area_struct *vma, struct page *page,

 	if (tlb_type == hypervisor)

 		return;
+	preempt_disable();

+

 #ifdef DCACHE_ALIASING_POSSIBLE

 	/* If bit 13 of the kernel address we used to access the

 	 * user page is the same as the virtual address that page

@@ -108,6 +110,8 @@ void flush_ptrace_access(struct vm_area_struct *vma, struct page *page,

 		for (; start < end; start += icache_line_size)

 			flushi(start);

 	}

+

+	preempt_enable();

 }
 enum sparc_regset {

--

And this one also worked. Now I have a nice clean dmesg :)
Thanks,
	Mariusz

--