Home » Mailing list archives » linux-kernel » 2008 » March » 28

Re: Linux 2.6.25-rc7 sparc64 loops forever on cat /proc/<pid>/pagemap

Previous thread: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor by Mike Travis on Tuesday, March 25, 2008 - 6:41 pm. (1 message)

Next thread: [PATCH] Improvev netconsole support for RTL8139 NIC driver by yshi on Tuesday, March 25, 2008 - 7:12 pm. (12 messages)
[view original message]
From: Linus Torvalds
Subject: Linux 2.6.25-rc7
Date: Tuesday, March 25, 2008 - 7:07 pm

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 &quot;big&quot; 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 ...
[ message continues ]
[view original message]
From: Mariusz Kozlowski
Subject: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 3:42 am

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: ...
[ message continues ]
[view original message]
From: David Miller
Subject: Re: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 4:16 am

From: Mariusz Kozlowski &lt;m.kozlowski@tuxland.pl&gt;

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.
--


[ message continues ]
[view original message]
From: David Miller
Subject: Re: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 4:25 am

From: David Miller &lt;davem@davemloft.net&gt;

And this patch should fix it:

commit 69072f6e8e4bd4799d2a54e4ff8771d0657512c1
Author: David S. Miller &lt;davem@davemloft.net&gt;
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 &lt;davem@davemloft.net&gt;

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 = &amp;__get_cpu_var(mmu_gathers);
+	struct mmu_gather *mp;
 
 	preempt_disable();
 
+	mp = &amp;__get_cpu_var(mmu_gathers);
 	if (mp-&gt;tlb_nr) {
 		flush_tsb_user(mp);
 
--


[ message continues ]
[view original message]
From: Mariusz Kozlowski
Subject: Re: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 4:46 am

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
--


[ message continues ]
[view original message]
From: David Miller
Subject: Re: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 4:51 am

From: Mariusz Kozlowski &lt;m.kozlowski@tuxland.pl&gt;

Here ya go:

commit f6a843d939ade435e060d580f5c56d958464f8a5
Author: David S. Miller &lt;davem@davemloft.net&gt;
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 &lt;davem@davemloft.net&gt;

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 &lt; end; start += icache_line_size)
 			flushi(start);
 	}
+
+	preempt_enable();
 }
 
 enum sparc_regset {
--


[ message continues ]
[view original message]
From: Mariusz Kozlowski
Subject: Re: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 5:10 am

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

Thanks,

	Mariusz
--


[ message continues ]
[view original message]
From: Andrew Morton
Subject: Re: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 8:25 pm

that's an open-coded get_cpu_var().

fwiw.  Which isn't much, IMO.  Sometimes it's nice to see things open-coded.
--


[ message continues ]
[view original message]
From: David Miller
Subject: Re: sparc64 BUG: using smp_processor_id() in preemptible
Date: Wednesday, March 26, 2008 - 11:33 pm

From: Andrew Morton &lt;akpm@linux-foundation.org&gt;

Good point, I might restructure that to use {get,put}_cpu_var().
--


[ message continues ]
[view original message]
From: Mariusz Kozlowski
Subject: Re: Linux 2.6.25-rc7 sparc64 loops forever on cat /proc/&lt;pid&gt;/pagemap
Date: Wednesday, March 26, 2008 - 5:02 am

Hello,

cat /proc/&lt;pid&gt;/pagemap 

and 

cat /proc/&lt;pid&gt;/task/&lt;pid&gt;/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

[ message continues ]
[view original message]
From: David Miller
Subject: Re: Linux 2.6.25-rc7 sparc64 loops forever on cat /proc/&lt;pid&gt;/pagemap
Date: Wednesday, March 26, 2008 - 5:35 pm

From: Mariusz Kozlowski &lt;m.kozlowski@tuxland.pl&gt;

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 &lt;davem@davemloft.net&gt;
Date:   Wed Mar 26 17:32:33 2008 -0700

    [SPARC64]: Define TASK_SIZE_OF()
    
    This make &quot;cat /proc/${PID}/pagemap&quot; more efficient for
    32-bit tasks.
    
    Based upon a report by Mariusz Kozlowski.
    
    Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;

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 &lt;&lt; 32UL) : TASK_SIZE)
 #ifdef __KERNEL__
 
 #define STACK_TOP32	((1UL &lt;&lt; 32UL) - PAGE_SIZE)
--


[ message continues ]
[view original message]
From: Mariusz Kozlowski
Subject: Re: Linux 2.6.25-rc7 sparc64 loops forever on cat /proc/&lt;pid&gt;/pagemap
Date: Friday, March 28, 2008 - 4:33 am

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 &gt; /dev/null
real    0m0.046s
user    0m0.000s
sys     0m0.047s

Thanks,

	Mariusz
--


[ message continues ]
Previous thread: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor by Mike Travis on Tuesday, March 25, 2008 - 6:41 pm. (1 message)

Next thread: [PATCH] Improvev netconsole support for RTL8139 NIC driver by yshi on Tuesday, March 25, 2008 - 7:12 pm. (12 messages)