* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Russell King @ 2002-12-19 9:13 UTC (permalink / raw)
To: Adam J. Richter; +Cc: linux-kernel
In-Reply-To: <200212190108.RAA03649@adam.yggdrasil.com>
On Wed, Dec 18, 2002 at 05:08:45PM -0800, Adam J. Richter wrote:
> I don't currently use bugzilla (just due to inertia), but the
> whole world doesn't have to switch to something overnight in order for
> that facility to end up saving more time and resources than it has
> cost. Adoption can grow gradually, and it's probably easier to work
> out bugs (in bugzilla) and improvements that way anyhow.
I'm not asking the world to switch to it overnight. Just one person
would be nice. 8)
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* Re: [LARTC] linux bridging and htb.init / cbq.init
From: Mindaugas Riauba @ 2002-12-19 9:09 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104028870626803@msgid-missing>
> I'am successful using a linux (2.4.20) bridge and the cbq.init_v0.7
> script for traffic shaping. But I can only use the queuing discipline
> tbf (LEAF=tbf). If I try use queuing discipline sfq or none then tc
> applies the rules but no shaping occurs.
> Is this problem a normal behavior when using bridging ?
>
> I tried to use htb.init (using patched tc binary). It accepts
> the rules but also no shaping occurs (tested with all queuing
> disciplines (LEAF=none|sfq|pfifo).
> Why it doesn't work together with bridging ?
Works for me. View my previous post about exceeding limits. It
applies to this setup with shaping bridged traffic.
Mindaugas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Problems with CONFIG_PREEMPT
From: Colin.Helliwell @ 2002-12-19 9:10 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips, rml
Thanks for the patch, but unfortunately the problem is still the same. I'm
not sure whether it occurs as a result of interrupts, or just after a
certain amount of scheduler 'activity' as it sits there copying the initrd
into ram disk. A few interrupts are enabled, but its only the MIPS timer
which should be generating any interrupts at that point (I'll check that,
in case its relevant).
I presume the change from "sti()" to "__sti()" was a semantic (or SMP)
thing, since the former is #defined to the latter anyway? Please note also
the following modification which was required to 2.4.19:
diff -u -p -r1.1 -r1.2
--- scratch/include/asm-mips/hardirq.h 2002/09/26 15:58:11 1.1
+++ scratch/include/asm-mips/hardirq.h 2002/12/12 13:15:03 1.2
@@ -42,7 +42,7 @@
#define irq_exit(cpu, irq) (local_irq_count(cpu)--)
#define synchronize_irq() barrier();
-
+#define release_irqlock(cpu) do { } while (0)
#else
#include <asm/atomic.h>
(We had a look at the 2.5 (head) kernel, but this seems to have some wrong
coding, and doesn't build straight off. Things like duplicate #defines
ALIGN and a conditional branch instruction with only one operand!)
Jun Sun
<jsun@mvista.com> To: Colin.Helliwell@Zarlink.Com
Sent by: cc: linux-mips@linux-mips.org, jsun@mvista.com, rml@mvista.com
linux-mips-bounce@lin Subject: Re: Problems with CONFIG_PREEMPT
ux-mips.org
17-Dec-2002 06:03 PM
On Tue, Dec 17, 2002 at 08:27:16AM +0000, Colin.Helliwell@Zarlink.Com
wrote:
>
> NEW_TIME_C is set. URL to the patch is:
>
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-2.patch
>
There are some bits missing. Not sure if it is related to your problem or
not.
Robert, please take the MIPS preemptible kernel update patch.
> We ultimately want to add in real-time support, such as Ingo's O(1)
> scheduler - if this is 'complete' for MIPS.
O(1) shortens process dispatching time, usually not a big time saver
unless you have *lots* of process and/or you are doing frequent context
switches.
Another patch which is probably more important is the Ingo's breaking
selected big lock patch. That will preemption work more effectively.
> I don't know if it would be
> better just to go for this in one hit, or if we'd need the preemption
> sorted out anyway first.
You do have to sort them out one by one. (Or you get them all by becoming
mvista customer. :-0)
> Or should we just go to a 2.5.x kernel instead?
We'd love to have more people bang on 2.5 MIPS *grin* ...
Jun
^ permalink raw reply
* Re: Multithreaded coredump patch where?
From: Roberto Fichera @ 2002-12-19 9:24 UTC (permalink / raw)
To: mgross; +Cc: linux-kernel
In-Reply-To: <200212181907.gBIJ7XP12936@unix-os.sc.intel.com>
At 08.13 18/12/02 -0800, mgross wrote:
>On Tuesday 17 December 2002 03:05 am, Roberto Fichera wrote:
> > >I haven't rebased the patches I posted back in June for a while now.
> > >
> > >Attached is the patch I posted for the 2.4.18 vanilla kernel. Its a bit
> > >controversial, but it seems to work for a number of folks. Let me know if
> > >you have any troubles re-basing it.
> >
> > Only one hunk failed on include/asm-ia64/elf.h but fixed by hand.
> > Why do you say a bit controversial ? One difference that I have
> > notice is in coredump size after your patch. However seem to be
> > working well for now. I'll try later on a SMP machine.
>
>There are 2 issues with this implementation that will likely not effect you.
>
>
>First, when dumping core of MT applications with LOTS of threads the pthread
>library signals all the threads in the application to exit. Sometimes
>the process that is dumping core fails to suspend other threads in the
>application before some exit. The result of this is that for such
>applications you will not see them in the core file.
>
>You have to work at it to see this failure. The way I reproduce this is to
>run a test application with about 555 pthread threads in it and send it a
>sig_quit. When I look at the core file wont have all 555 threads. SMP makes
>this effect a bit more noticeable.
This could be a problem for me. I haven't tried yet your patch with my SMP
machine but I'll try today, I hope.
>Ingo's design to fix this change the exit path for thread to wait for the
>core file to get dumped before finishing the process clean up. I like this
>approach, I just wish I thought of it ;)
Yes seem to be a good solution.
>Second, the controversial issue is in the way my design pauses the other
>threads in the MT application. Its not semaphore lock safe. Although no
>instance of the following failure has been seen, it is possible with new
>kernel code.
>
>If one of the processes in the MT application is currently holding semaphore
>lock when the dumping process pauses it, AND the dumping process does any
>blocking operation that could attempt to grab this same semaphore, THEN the
>core dump will deadlock. Boom.
This problem could be reproducible under load doing some IO (fs & net),
cpu bound process and swapping (vm IO). In this way we could have some
possibility to catch it.
>My patch is good for developers, pending the back port of Ingo's version.
>
>Do let me know how it works out for you.
>
>--mgross
Roberto Fichera.
^ permalink raw reply
* Re: 2.5.52-mm2
From: William Lee Irwin III @ 2002-12-19 9:28 UTC (permalink / raw)
To: Andrew Morton, lkml, linux-mm
In-Reply-To: <20021219085426.GJ1922@holomorphy.com>
On Wed, Dec 18, 2002 at 09:53:18PM -0800, Andrew Morton wrote:
>> url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.52/2.5.52-mm2/
On Thu, Dec 19, 2002 at 12:54:26AM -0800, William Lee Irwin III wrote:
> Kernel compile on ramfs, shpte off, overcommit on (probably more like a
> stress test for shpte):
With shpte on:
c0135790 123025 0.33807 nr_free_pages
c015021c 134621 0.369936 __fput
c0119974 144602 0.397364 kmap_atomic
c01b23d0 146899 0.403676 __copy_user_intel
c014c050 159002 0.436935 pte_unshare
c0122c28 171802 0.472109 current_kernel_time
c01fbd9c 172897 0.475118 sync_buffer
c0116870 187066 0.514054 pfn_to_nid
c0115390 199497 0.548214 smp_apic_timer_interrupt
c013f820 236468 0.64981 do_no_page
c0116918 260314 0.715338 x86_profile_hook
c016566c 274151 0.753362 d_lookup
c01b2578 280625 0.771152 __copy_from_user
c013212c 323752 0.889665 find_get_page
c0140800 338288 0.929609 vm_enough_memory
c013fbd0 355384 0.976589 handle_mm_fault
c014ff90 358839 0.986083 get_empty_filp
c011a710 363642 0.999282 scheduler_tick
c011a258 507320 1.39411 load_balance
c01505a9 664873 1.82706 .text.lock.file_table
c01b2510 834467 2.2931 __copy_to_user
c0135928 1051119 2.88846 __get_page_state
c013f400 1062731 2.92037 do_anonymous_page
c0143fa0 1273498 3.49955 page_add_rmap
c014419c 1386659 3.81051 page_remove_rmap
c0106f38 21099307 57.9805 poll_idle
Bill
^ permalink raw reply
* Re: 2.5.52-mm2
From: William Lee Irwin III @ 2002-12-19 9:28 UTC (permalink / raw)
To: Andrew Morton, lkml, linux-mm
In-Reply-To: <20021219085426.GJ1922@holomorphy.com>
On Wed, Dec 18, 2002 at 09:53:18PM -0800, Andrew Morton wrote:
>> url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.52/2.5.52-mm2/
On Thu, Dec 19, 2002 at 12:54:26AM -0800, William Lee Irwin III wrote:
> Kernel compile on ramfs, shpte off, overcommit on (probably more like a
> stress test for shpte):
With shpte on:
c0135790 123025 0.33807 nr_free_pages
c015021c 134621 0.369936 __fput
c0119974 144602 0.397364 kmap_atomic
c01b23d0 146899 0.403676 __copy_user_intel
c014c050 159002 0.436935 pte_unshare
c0122c28 171802 0.472109 current_kernel_time
c01fbd9c 172897 0.475118 sync_buffer
c0116870 187066 0.514054 pfn_to_nid
c0115390 199497 0.548214 smp_apic_timer_interrupt
c013f820 236468 0.64981 do_no_page
c0116918 260314 0.715338 x86_profile_hook
c016566c 274151 0.753362 d_lookup
c01b2578 280625 0.771152 __copy_from_user
c013212c 323752 0.889665 find_get_page
c0140800 338288 0.929609 vm_enough_memory
c013fbd0 355384 0.976589 handle_mm_fault
c014ff90 358839 0.986083 get_empty_filp
c011a710 363642 0.999282 scheduler_tick
c011a258 507320 1.39411 load_balance
c01505a9 664873 1.82706 .text.lock.file_table
c01b2510 834467 2.2931 __copy_to_user
c0135928 1051119 2.88846 __get_page_state
c013f400 1062731 2.92037 do_anonymous_page
c0143fa0 1273498 3.49955 page_add_rmap
c014419c 1386659 3.81051 page_remove_rmap
c0106f38 21099307 57.9805 poll_idle
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: 2.5.52-mm2
From: Andrew Morton @ 2002-12-19 9:41 UTC (permalink / raw)
To: lkml, linux-mm
In-Reply-To: <3E015ECE.9E3BD19@digeo.com>
Andrew Morton wrote:
>
> ...
> slab-poisoning.patch
> more informative slab poisoning
This patch has exposed a quite long-standing use-after-free bug in
mremap(). It make the machine go BUG when starting the X server if
memory debugging is turned on.
The bug might be present in 2.4 as well..
--- 25/mm/mremap.c~move_vma-use-after-free Thu Dec 19 00:51:49 2002
+++ 25-akpm/mm/mremap.c Thu Dec 19 01:08:45 2002
@@ -183,14 +183,16 @@ static unsigned long move_vma(struct vm_
next = find_vma_prev(mm, new_addr, &prev);
if (next) {
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
new_vma = prev;
if (next != prev->vm_next)
BUG();
- if (prev->vm_end == next->vm_start && can_vma_merge(next, prev->vm_flags)) {
+ if (prev->vm_end == next->vm_start &&
+ can_vma_merge(next, prev->vm_flags)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = next->vm_end;
__vma_unlink(mm, next, prev);
@@ -201,7 +203,8 @@ static unsigned long move_vma(struct vm_
kmem_cache_free(vm_area_cachep, next);
}
} else if (next->vm_start == new_addr + new_len &&
- can_vma_merge(next, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(next, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
next->vm_start = new_addr;
spin_unlock(&mm->page_table_lock);
@@ -210,7 +213,8 @@ static unsigned long move_vma(struct vm_
} else {
prev = find_vma(mm, new_addr-1);
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
@@ -227,12 +231,16 @@ static unsigned long move_vma(struct vm_
}
if (!move_page_tables(vma, new_addr, addr, old_len)) {
+ unsigned long must_fault_in;
+ unsigned long fault_in_start;
+ unsigned long fault_in_end;
+
if (allocated_vma) {
*new_vma = *vma;
INIT_LIST_HEAD(&new_vma->shared);
new_vma->vm_start = new_addr;
new_vma->vm_end = new_addr+new_len;
- new_vma->vm_pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
+ new_vma->vm_pgoff += (addr-vma->vm_start) >> PAGE_SHIFT;
if (new_vma->vm_file)
get_file(new_vma->vm_file);
if (new_vma->vm_ops && new_vma->vm_ops->open)
@@ -251,19 +259,25 @@ static unsigned long move_vma(struct vm_
} else
vma = NULL; /* nothing more to do */
- do_munmap(current->mm, addr, old_len);
-
/* Restore VM_ACCOUNT if one or two pieces of vma left */
if (vma) {
vma->vm_flags |= VM_ACCOUNT;
if (split)
vma->vm_next->vm_flags |= VM_ACCOUNT;
}
+
+ must_fault_in = new_vma->vm_flags & VM_LOCKED;
+ fault_in_start = new_vma->vm_start;
+ fault_in_end = new_vma->vm_end;
+
+ do_munmap(current->mm, addr, old_len);
+
+ /* new_vma could have been invalidated by do_munmap */
+
current->mm->total_vm += new_len >> PAGE_SHIFT;
- if (new_vma->vm_flags & VM_LOCKED) {
+ if (must_fault_in) {
current->mm->locked_vm += new_len >> PAGE_SHIFT;
- make_pages_present(new_vma->vm_start,
- new_vma->vm_end);
+ make_pages_present(fault_in_start, fault_in_end);
}
return new_addr;
}
_
^ permalink raw reply
* Re: 2.5.52-mm2
From: Andrew Morton @ 2002-12-19 9:41 UTC (permalink / raw)
To: lkml, linux-mm
In-Reply-To: <3E015ECE.9E3BD19@digeo.com>
Andrew Morton wrote:
>
> ...
> slab-poisoning.patch
> more informative slab poisoning
This patch has exposed a quite long-standing use-after-free bug in
mremap(). It make the machine go BUG when starting the X server if
memory debugging is turned on.
The bug might be present in 2.4 as well..
--- 25/mm/mremap.c~move_vma-use-after-free Thu Dec 19 00:51:49 2002
+++ 25-akpm/mm/mremap.c Thu Dec 19 01:08:45 2002
@@ -183,14 +183,16 @@ static unsigned long move_vma(struct vm_
next = find_vma_prev(mm, new_addr, &prev);
if (next) {
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
new_vma = prev;
if (next != prev->vm_next)
BUG();
- if (prev->vm_end == next->vm_start && can_vma_merge(next, prev->vm_flags)) {
+ if (prev->vm_end == next->vm_start &&
+ can_vma_merge(next, prev->vm_flags)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = next->vm_end;
__vma_unlink(mm, next, prev);
@@ -201,7 +203,8 @@ static unsigned long move_vma(struct vm_
kmem_cache_free(vm_area_cachep, next);
}
} else if (next->vm_start == new_addr + new_len &&
- can_vma_merge(next, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(next, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
next->vm_start = new_addr;
spin_unlock(&mm->page_table_lock);
@@ -210,7 +213,8 @@ static unsigned long move_vma(struct vm_
} else {
prev = find_vma(mm, new_addr-1);
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
@@ -227,12 +231,16 @@ static unsigned long move_vma(struct vm_
}
if (!move_page_tables(vma, new_addr, addr, old_len)) {
+ unsigned long must_fault_in;
+ unsigned long fault_in_start;
+ unsigned long fault_in_end;
+
if (allocated_vma) {
*new_vma = *vma;
INIT_LIST_HEAD(&new_vma->shared);
new_vma->vm_start = new_addr;
new_vma->vm_end = new_addr+new_len;
- new_vma->vm_pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
+ new_vma->vm_pgoff += (addr-vma->vm_start) >> PAGE_SHIFT;
if (new_vma->vm_file)
get_file(new_vma->vm_file);
if (new_vma->vm_ops && new_vma->vm_ops->open)
@@ -251,19 +259,25 @@ static unsigned long move_vma(struct vm_
} else
vma = NULL; /* nothing more to do */
- do_munmap(current->mm, addr, old_len);
-
/* Restore VM_ACCOUNT if one or two pieces of vma left */
if (vma) {
vma->vm_flags |= VM_ACCOUNT;
if (split)
vma->vm_next->vm_flags |= VM_ACCOUNT;
}
+
+ must_fault_in = new_vma->vm_flags & VM_LOCKED;
+ fault_in_start = new_vma->vm_start;
+ fault_in_end = new_vma->vm_end;
+
+ do_munmap(current->mm, addr, old_len);
+
+ /* new_vma could have been invalidated by do_munmap */
+
current->mm->total_vm += new_len >> PAGE_SHIFT;
- if (new_vma->vm_flags & VM_LOCKED) {
+ if (must_fault_in) {
current->mm->locked_vm += new_len >> PAGE_SHIFT;
- make_pages_present(new_vma->vm_start,
- new_vma->vm_end);
+ make_pages_present(fault_in_start, fault_in_end);
}
return new_addr;
}
_
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: 2.5.52-mm2
From: Andrew Morton @ 2002-12-19 9:50 UTC (permalink / raw)
To: lkml, linux-mm
In-Reply-To: <3E01943B.4170B911@digeo.com>
Andrew Morton wrote:
>
> Andrew Morton wrote:
> >
> > ...
> > slab-poisoning.patch
> > more informative slab poisoning
>
> This patch has exposed a quite long-standing use-after-free bug in
> mremap(). It make the machine go BUG when starting the X server if
> memory debugging is turned on.
>
> The bug might be present in 2.4 as well..
here's a 2.4 patch:
move_vma() calls do_munmap() and then uses the memory at *new_vma.
But when starting X11 it just happens that the memory which do_munmap
unmapped had the same start address and the range at *new_vma. So
new_vma is freed by do_munmap().
This was never noticed before because (vm_flags & VM_LOCKED) evaluates
false when vm_flags is 0x5a5a5a5a. But I just changed that to
0x6b6b6b6b and we call make_pages_present() with start == end ==
0x6b6b6b6b and it goes BUG.
The fix is for move_vma() to not inspect the values of any vma's after
it has called do_munmap().
The patch does that, for `vma' and `new_vma'.
It also removes three redundant tests of !vma->vm_file. can_vma_merge()
already tested that.
mm/mremap.c | 31 +++++++++++++++++++++++--------
1 files changed, 23 insertions(+), 8 deletions(-)
--- 24/mm/mremap.c~move_vma-use-after-free Thu Dec 19 01:29:52 2002
+++ 24-akpm/mm/mremap.c Thu Dec 19 01:31:43 2002
@@ -134,14 +134,16 @@ static inline unsigned long move_vma(str
next = find_vma_prev(mm, new_addr, &prev);
if (next) {
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
new_vma = prev;
if (next != prev->vm_next)
BUG();
- if (prev->vm_end == next->vm_start && can_vma_merge(next, prev->vm_flags)) {
+ if (prev->vm_end == next->vm_start &&
+ can_vma_merge(next, prev->vm_flags)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = next->vm_end;
__vma_unlink(mm, next, prev);
@@ -151,7 +153,8 @@ static inline unsigned long move_vma(str
kmem_cache_free(vm_area_cachep, next);
}
} else if (next->vm_start == new_addr + new_len &&
- can_vma_merge(next, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(next, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
next->vm_start = new_addr;
spin_unlock(&mm->page_table_lock);
@@ -160,7 +163,8 @@ static inline unsigned long move_vma(str
} else {
prev = find_vma(mm, new_addr-1);
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
@@ -177,11 +181,15 @@ static inline unsigned long move_vma(str
}
if (!move_page_tables(current->mm, new_addr, addr, old_len)) {
+ unsigned long must_fault_in;
+ unsigned long fault_in_start;
+ unsigned long fault_in_end;
+
if (allocated_vma) {
*new_vma = *vma;
new_vma->vm_start = new_addr;
new_vma->vm_end = new_addr+new_len;
- new_vma->vm_pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
+ new_vma->vm_pgoff += (addr-vma->vm_start) >> PAGE_SHIFT;
new_vma->vm_raend = 0;
if (new_vma->vm_file)
get_file(new_vma->vm_file);
@@ -189,12 +197,19 @@ static inline unsigned long move_vma(str
new_vma->vm_ops->open(new_vma);
insert_vm_struct(current->mm, new_vma);
}
+
+ must_fault_in = new_vma->vm_flags & VM_LOCKED;
+ fault_in_start = new_vma->vm_start;
+ fault_in_end = new_vma->vm_end;
+
do_munmap(current->mm, addr, old_len);
+
+ /* new_vma could have been invalidated by do_munmap */
+
current->mm->total_vm += new_len >> PAGE_SHIFT;
- if (new_vma->vm_flags & VM_LOCKED) {
+ if (must_fault_in) {
current->mm->locked_vm += new_len >> PAGE_SHIFT;
- make_pages_present(new_vma->vm_start,
- new_vma->vm_end);
+ make_pages_present(fault_in_start, fault_in_end);
}
return new_addr;
}
_
^ permalink raw reply
* Re: problem using jffs2 on DiskOnChip
From: David Woodhouse @ 2002-12-19 10:14 UTC (permalink / raw)
To: wolff; +Cc: linux-mtd
In-Reply-To: <001901c2a6c8$1c87ff60$446410ac@lt-gw8l30j.turnkiek.nl>
wolff@turnkiek.nl said:
> Short read: 0x10 bytes at 0x000001f0 instead of requested 44
The DiskOnChip hardware driver hasn't been used much with anything other
than NFTL. It appears not to do a full read if you ask it to read a range
of data which crosses a page boundary. Fix it accordingly by putting an
appropriate loop in instead of...
/* Don't allow a single read to cross a 512-byte block boundary */
if (from + len > ((from | 0x1ff) + 1))
len = ((from | 0x1ff) + 1) - from;
--
dwmw2
^ permalink raw reply
* Dell OEM Soundblaster Live 5.1 with different PCI ID
From: elchhome @ 2002-12-19 9:45 UTC (permalink / raw)
To: alsa-devel
Hello Friends,
Dell ships since a month an OEM Soundblaster Live 5.1 (sb0200) with a
different PCI ID
for original sblive you got 1102:0002
the Dell version has 1102:0006
I got no sound with the actual version of the sound driver.
Could anyone be so kind to incorporate this into the source code?
I am willing to supply all information which is needed.
If the problem was allready dealt with by other threads, please don't
flame me ;)
Thanks & regards
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* NAT HOWTO; iptables, man pageM; Errata
From: andre @ 2002-12-19 9:47 UTC (permalink / raw)
To: netfilter
Dear Rusty Russell,
First of all, I must apologise if I use a wrong email-adress, but this
was the only one I found in the HowTo.
The HowTo descripes following:
6.2. Destination NAT
...
## Change destination addresses of web traffic to 5.6.7.8, port 8080.
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \
-j DNAT --to 5.6.7.8:8080
The "--dport" option is available only if the extended packet matching
modules are loaded.
Altought the man page says, that the extended packet matching modules
are loaded implicity, when -p or --protocol is specified, the only way
to load them in Version 1.2.2 is to set the -m option.
So the way it works look like this
## Change destination addresses of web traffic to 5.6.7.8, port 8080.
# iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -i eth0 \
-j DNAT --to 5.6.7.8:8080
Best regards
Ein herzliches Servus aus Wien
André Dostal
mailto: ad7@gmx.at
^ permalink raw reply
* AW: Re: [PATCH] S4bios for 2.5.52.
From: Herbert Nachtnebel @ 2002-12-19 9:49 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Sorry to be stupid,
but that sounds like a unpluged block queue which get flushed every 5 seconds (or 30 seconds) by the bdflush daemon. There are two things which counters this, 1st: swsusp works on ide and there aren't such problems since aeons and 2nd Pavel knows that :-)
Hence, apologies for this hip shot.
Herbert.
-----Ursprüngliche Nachricht-----
Von: Nigel Cunningham [mailto:ncunningham-oKK1aGe2n869koe0gwxAeg@public.gmane.org]
Gesendet: Mittwoch, 18. Dezember 2002 20:38
An: 'Ducrot Bruno'; 'Kai Germaschewski'
Cc: 'Grover, Andrew'; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; 'Pavel Machek';
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Betreff: RE: [ACPI] Re: [PATCH] S4bios for 2.5.52.
> Kai, if you see that S4OS is slower, it is probably a bug
> that have to be
> fixed in swsusp.
There does seem to be a problem with the rw_swap_page_sync routine. Perhaps
not on Pavel's machine (:>), but I've experienced painfully slow suspends
too. Performance was helped immensely by applying a concept that I'll credit
Lyle Seaman for - unrolling rw_swap_page_sync and submitting all the IO for
pages then looping again and waiting on each sync. I found with writing 7000
or so pages (a suspend from init S) that something gets triggered to force
the sync about every 3900 pages anyway.
Regards,
Nigel
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: 2.5.52-mm2
From: Andrew Morton @ 2002-12-19 9:50 UTC (permalink / raw)
To: lkml, linux-mm
In-Reply-To: <3E01943B.4170B911@digeo.com>
Andrew Morton wrote:
>
> Andrew Morton wrote:
> >
> > ...
> > slab-poisoning.patch
> > more informative slab poisoning
>
> This patch has exposed a quite long-standing use-after-free bug in
> mremap(). It make the machine go BUG when starting the X server if
> memory debugging is turned on.
>
> The bug might be present in 2.4 as well..
here's a 2.4 patch:
move_vma() calls do_munmap() and then uses the memory at *new_vma.
But when starting X11 it just happens that the memory which do_munmap
unmapped had the same start address and the range at *new_vma. So
new_vma is freed by do_munmap().
This was never noticed before because (vm_flags & VM_LOCKED) evaluates
false when vm_flags is 0x5a5a5a5a. But I just changed that to
0x6b6b6b6b and we call make_pages_present() with start == end ==
0x6b6b6b6b and it goes BUG.
The fix is for move_vma() to not inspect the values of any vma's after
it has called do_munmap().
The patch does that, for `vma' and `new_vma'.
It also removes three redundant tests of !vma->vm_file. can_vma_merge()
already tested that.
mm/mremap.c | 31 +++++++++++++++++++++++--------
1 files changed, 23 insertions(+), 8 deletions(-)
--- 24/mm/mremap.c~move_vma-use-after-free Thu Dec 19 01:29:52 2002
+++ 24-akpm/mm/mremap.c Thu Dec 19 01:31:43 2002
@@ -134,14 +134,16 @@ static inline unsigned long move_vma(str
next = find_vma_prev(mm, new_addr, &prev);
if (next) {
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
new_vma = prev;
if (next != prev->vm_next)
BUG();
- if (prev->vm_end == next->vm_start && can_vma_merge(next, prev->vm_flags)) {
+ if (prev->vm_end == next->vm_start &&
+ can_vma_merge(next, prev->vm_flags)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = next->vm_end;
__vma_unlink(mm, next, prev);
@@ -151,7 +153,8 @@ static inline unsigned long move_vma(str
kmem_cache_free(vm_area_cachep, next);
}
} else if (next->vm_start == new_addr + new_len &&
- can_vma_merge(next, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(next, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
next->vm_start = new_addr;
spin_unlock(&mm->page_table_lock);
@@ -160,7 +163,8 @@ static inline unsigned long move_vma(str
} else {
prev = find_vma(mm, new_addr-1);
if (prev && prev->vm_end == new_addr &&
- can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
+ can_vma_merge(prev, vma->vm_flags) &&
+ !(vma->vm_flags & VM_SHARED)) {
spin_lock(&mm->page_table_lock);
prev->vm_end = new_addr + new_len;
spin_unlock(&mm->page_table_lock);
@@ -177,11 +181,15 @@ static inline unsigned long move_vma(str
}
if (!move_page_tables(current->mm, new_addr, addr, old_len)) {
+ unsigned long must_fault_in;
+ unsigned long fault_in_start;
+ unsigned long fault_in_end;
+
if (allocated_vma) {
*new_vma = *vma;
new_vma->vm_start = new_addr;
new_vma->vm_end = new_addr+new_len;
- new_vma->vm_pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
+ new_vma->vm_pgoff += (addr-vma->vm_start) >> PAGE_SHIFT;
new_vma->vm_raend = 0;
if (new_vma->vm_file)
get_file(new_vma->vm_file);
@@ -189,12 +197,19 @@ static inline unsigned long move_vma(str
new_vma->vm_ops->open(new_vma);
insert_vm_struct(current->mm, new_vma);
}
+
+ must_fault_in = new_vma->vm_flags & VM_LOCKED;
+ fault_in_start = new_vma->vm_start;
+ fault_in_end = new_vma->vm_end;
+
do_munmap(current->mm, addr, old_len);
+
+ /* new_vma could have been invalidated by do_munmap */
+
current->mm->total_vm += new_len >> PAGE_SHIFT;
- if (new_vma->vm_flags & VM_LOCKED) {
+ if (must_fault_in) {
current->mm->locked_vm += new_len >> PAGE_SHIFT;
- make_pages_present(new_vma->vm_start,
- new_vma->vm_end);
+ make_pages_present(fault_in_start, fault_in_end);
}
return new_addr;
}
_
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: Domain transition -- enabling user_r in eklogin
From: Russell Coker @ 2002-12-19 9:51 UTC (permalink / raw)
To: Brian May; +Cc: SELinux
In-Reply-To: <20021218222704.GH10185@snoopy.apana.org.au>
On Wed, 18 Dec 2002 23:27, Brian May wrote:
> On Wed, Dec 18, 2002 at 08:45:22AM +0100, Russell Coker wrote:
> > Which is something you could easily achieve through PAM configuration if
> > that is what you desire, without any kerberos issues etc.
>
> How would you do it with PAM?
Put the following in /etc/pam.d/newrole:
auth required pam_permit.so
NB I'm not advocating doing this, just letting you know it's possible.
> What security issues would this raise?
It largely removes the point of having newrole. In that case you should
probably just permit each user exactly one role and give the default domain
for that role the permissions required to do everything that they need to do.
One significant disadvantage is that a hacked sshd could run "newrole -r
sysadm_r" and get that access (and this can be extended to other programs
with a similar situation).
Of course if you allow someone the ability to transition to a role with less
capabilities than their default role, and then denied them the ability to run
the newrole program while in that role it might have some potential.
> > Also I think that in most situations where a user could be tricked into
> > running newrole then it's game-over anyway.
>
> OK. I was thinking more of scripts, etc.
It's the same thing. If I can trick you into running some arbitary commands
with your main role then I can get your ssh identity key and your gpg secret
key. These crypto keys are often worth more than the hardware that they are
stored on...
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: EDE - 0.0.5
From: jb1 @ 2002-12-19 9:53 UTC (permalink / raw)
To: Neil Holmes; +Cc: Linux 8086
In-Reply-To: <DDENIOHFNLNMCGGDFDPCMEAPCJAA.neil.holmes@zoom.co.uk>
On Wed, 18 Dec 2002, Neil Holmes wrote:
...
> I have, for 0.0.5, also upgraded the version of elkscmd programs. I have
> taken what was the latest download on sourceforge, namely elkscmd_20020501,
> at the time I was building the release.
...
The elkscmd CVS has a *bunch* of problems. Please check my (jb1's)
submissions to the mailing list, September through December 2002; much of
it is about problems in another package (elksnet), but I remember
submitting a list of problems ("Re: root disk!" in reply to Paul Nasrat)
and at least two bug fixes (for more.c and clock.c). My stuff is in no way
"official", so you should check with the developers ... I haven't heard
from them.
^ permalink raw reply
* parport_serial link order bug, NetMos support
From: Marek Michalkiewicz @ 2002-12-19 10:03 UTC (permalink / raw)
To: linux-kernel
Hello,
I've been trying (for quite a long time now, starting around the
time when 2.4.19 was released) to submit the following patches into
the 2.4.x kernel:
http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/00_parport_serial
http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/01_netmos
(generated for 2.4.20-pre9, but apply cleanly to 2.4.20-final too,
00_parport_serial needs to be applied before 01_netmos).
The first patch fixes a bug with CONFIG_PARPORT_SERIAL=y (moves the
parport_serial driver - must be initialised after serial). This
bug has been fixed in 2.5.x some time ago, by moving the serial
driver to its own directory - a change that looks too intrusive for
2.4.x, moving parport_serial instead looks much safer. This patch
is quite big, but most of it is just moving parport_serial.c from
drivers/parport/ to drivers/char/ without changing a single line.
Now parport_serial is after serial, but before any drivers that
need parport already initialised: lp, block (paride), net (plip).
The second patch adds support for NetMos PCI I/O cards, based on
a >1 year old 2.5.x patch by Tim Waugh. I've been using a few
NM9835-based cards in production use, no problems so far (in 3
machines, one of them is my server with two permanent 115.2k PPP
connections, which have seen quite a few gigabytes of traffic).
Now that 2.4.21-pre2 is out, I'd like to ask - are there any good
reasons why these patches are not going in? There has been some
discussion, but no conclusion either way (not accepted, and not
rejected). Are there any known problems, like some NM9835 chips
burn and explode when run under Linux and I've just been lucky? ;)
Please, I would really appreciate to see these patches in 2.4.21.
Thanks,
Marek
^ permalink raw reply
* Re: how to delete a piece of rule in iptables?
From: Markus Schaber @ 2002-12-19 9:56 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <200212181230.UAA02960@email.whu.edu.cn>
Hallo,
bobo <boboaq@163.com> schrieb:
> i have insert some rules to iptables firewall.now,i would
>
> like to delete it .
> but i only know to use iptalbes -L to empty them.
> but it lead to delete all the rules in it.
> how to do ??
"iptables --help" gives you a short command overview.
"man iptables" gives you more extensive help.
Gruß,
Markus
--
Markus Schaber - http://www.schabi.de/
Schabi's Flohmarkt unter http://schabi.de/flohmarkt
^ permalink raw reply
* Re: [PATCH]: make highmem only things enclosed in the right #ifdef
From: Juan Quintela @ 2002-12-19 10:07 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <Pine.GSO.3.96.1021218173132.5977B-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 18 Dec 2002, Juan Quintela wrote:
>> +#ifdef CONFIG_HIGHMEM
>> unsigned long vaddr;
>> - pgd_t *pgd, *pgd_base;
>> pmd_t *pmd;
>> pte_t *pte;
>> -
>> + pgd_t *pgd, pgd_base;
>> +#endif
>> /* Initialize the entire pgd. */
>> pgd_init((unsigned long)swapper_pg_dir);
maciej> Please don't change the spacing this way -- it worsens readability.
maciej> Check other pathes for cases like this, too.
Hi
Argh, the patch indeed missed an *.
What do you think of this new one?
Later ,Juan.
Index: arch/mips/mm/init.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/init.c,v
retrieving revision 1.38.2.7
diff -u -r1.38.2.7 init.c
--- arch/mips/mm/init.c 5 Aug 2002 23:53:35 -0000 1.38.2.7
+++ arch/mips/mm/init.c 19 Dec 2002 09:21:09 -0000
@@ -161,6 +161,7 @@
extern char _ftext, _etext, _fdata, _edata;
extern char __init_begin, __init_end;
+#ifdef CONFIG_HIGHMEM
static void __init fixrange_init (unsigned long start, unsigned long end,
pgd_t *pgd_base)
{
@@ -189,22 +190,26 @@
j = 0;
}
}
+#endif /* CONFIG_HIGHMEM */
void __init pagetable_init(void)
{
+#ifdef CONFIG_HIGHMEM
unsigned long vaddr;
pgd_t *pgd, *pgd_base;
pmd_t *pmd;
pte_t *pte;
+#endif
/* Initialize the entire pgd. */
pgd_init((unsigned long)swapper_pg_dir);
pgd_init((unsigned long)swapper_pg_dir +
sizeof(pgd_t ) * USER_PTRS_PER_PGD);
- pgd_base = swapper_pg_dir;
#ifdef CONFIG_HIGHMEM
+ pgd_base = swapper_pg_dir;
+
/*
* Fixed mappings:
*/
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: gettimeofday() moving backwards
From: Herbert Nachtnebel @ 2002-12-19 10:01 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: p.a.richards-Y3tGgqFSo3OFxr2TtlUqVg
In 2.4 there exists CONFIG_ASYNC_TSC to help with such things.
I never tried it, but it should change the gettimeofday()
system call to not use the TSC for time calculations. This
results in a really slow system call since now it uses the PIT
for every access, but the system time should be smoothly again.
Regards, Herbert.
-----Ursprüngliche Nachricht-----
Von: Dominik Brodowski [mailto:linux-JhLEnvuH02M@public.gmane.org]
Gesendet: Mittwoch, 18. Dezember 2002 23:41
An: Grover, Andrew
Cc: 'Paul Richards'; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Betreff: Re: [ACPI] gettimeofday() moving backwards
On Wed, Dec 18, 2002 at 01:23:57PM -0800, Grover, Andrew wrote:
> > From: Paul Richards [mailto:p.a.richards-Y3tGgqFSo3OFxr2TtlUqVg@public.gmane.org]
> > I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.
> >
> > I have noticed that if my processor changes state (800Mhz up
> > to 1200Mhz say)
> > then gettimeofday() behaves weirdly. It runs smoothly but
> > every now and again
> > (on the order of 10 times a second) it makes a correction.
> > If I have gone from
> > 800Mhz to 1200Mhz then the correction is backwards, otherwise
> > it makes a forward
> > jump..
>
> Hmm, can you mention this on the cpufreq mailing list?
> cpufreq-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org .
In kernel 2.5.5x, gettimeofday() should work fine: ACPI uses the cpufreq
infrastructure, which adds -among other things- a hunk in
arch/i386/timer/tsc.c which updates some values on frequency transitions.
(see http://www.brodo.de/cpufreq/ for details on cpufreq).
As cpufreq isn't included in 2.4. kernels, and likely never will, the 2.4.
gettimeofday() call does cause strange results in 2.4.
Dominik
-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: QOS
From: Maciej Soltysiak @ 2002-12-19 10:02 UTC (permalink / raw)
To: Paulo Andre; +Cc: netfilter
In-Reply-To: <1040280504.11113.140.camel@bigblue>
> Which is the better package to use for QOS??
> HTB or CBQ..???
Well, some say that CBQ is very inacurate, but very often is sufficient,
which i know from experience. HTB is said to be a bit easier and more
acurate.
Please read about it on www.lartc.org
Regards,
Maciej
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Denis Vlasenko @ 2002-12-19 14:40 UTC (permalink / raw)
To: Alan Cox, D.A.M. Revok
Cc: Andre Hedrick, Manish Lachwani, Linux Kernel Mailing List
In-Reply-To: <1040251122.26501.0.camel@irongate.swansea.linux.org.uk>
On 18 December 2002 20:38, Alan Cox wrote:
> On Wed, 2002-12-18 at 21:35, D.A.M. Revok wrote:
> > So. I /think/ that somehow the Promise controller isn't being
> > initialized properly by the Linux kernel, UNLESS the mobo's BIOS
> > inits it first?
>
> In some situations yes. The BIOS does stuff including fixups we mere
> mortals arent permitted to know about.
OTOH mere mortals are allowed to make full dump of PCI config ;)
"D.A.M. Revok" <marvin@synapse.net>, can you send lspci -vvvxxx
outputs when you boot with BIOS enabled and BIOS disabled?
--
vda
^ permalink raw reply
* Re: 2.5.52-mm2
From: William Lee Irwin III @ 2002-12-19 10:12 UTC (permalink / raw)
To: Andrew Morton, lkml, linux-mm
In-Reply-To: <20021219092853.GK1922@holomorphy.com>
On Wed, Dec 18, 2002 at 09:53:18PM -0800, Andrew Morton wrote:
>>> url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.52/2.5.52-mm2/
On Thu, Dec 19, 2002 at 12:54:26AM -0800, William Lee Irwin III wrote:
>> Kernel compile on ramfs, shpte off, overcommit on (probably more like a
>> stress test for shpte):
On Thu, Dec 19, 2002 at 01:28:53AM -0800, William Lee Irwin III wrote:
> With shpte on:
With the following patch:
c013d4d4 94944 0.310788 zap_pte_range
c01355d0 104773 0.342962 nr_free_pages
c014f65c 107566 0.352105 __fput
c01b1750 112055 0.366799 __copy_user_intel
c0115350 121040 0.39621 smp_apic_timer_interrupt
c0119814 126089 0.412738 kmap_atomic
c014b6cc 145095 0.474952 pte_unshare
c01fb11c 145992 0.477888 sync_buffer
c0122a78 148079 0.484719 current_kernel_time
c01168b8 193805 0.634398 x86_profile_hook
c013f140 205233 0.671806 do_no_page
c0164aac 235356 0.77041 d_lookup
c01b18f8 257358 0.842431 __copy_from_user
c0131f7c 275559 0.90201 find_get_page
c011a560 282341 0.92421 scheduler_tick
c0140090 300128 0.982434 vm_enough_memory
c013f4bc 310474 1.0163 handle_mm_fault
c014f3d0 312725 1.02367 get_empty_filp
c011a0a8 365066 1.195 load_balance
c014f9e9 502737 1.64565 .text.lock.file_table
c01b1890 719105 2.35391 __copy_to_user
c0135768 911894 2.98498 __get_page_state
c013ee50 952823 3.11895 do_anonymous_page
c01436d0 1079864 3.53481 page_add_rmap
c01438cc 1186938 3.8853 page_remove_rmap
c0106f38 17763755 58.1476 poll_idle
pfn_to_nid() got lots of icache misses. Try using a macro.
arch/i386/kernel/i386_ksyms.c | 1 -
arch/i386/kernel/numaq.c | 15 ++-------------
include/asm-i386/numaq.h | 3 ++-
3 files changed, 4 insertions(+), 15 deletions(-)
diff -urpN linux-2.5.52-mm1/arch/i386/kernel/i386_ksyms.c mm1-2.5.52-1/arch/i386/kernel/i386_ksyms.c
--- linux-2.5.52-mm1/arch/i386/kernel/i386_ksyms.c 2002-12-16 19:29:45.000000000 -0800
+++ mm1-2.5.52-1/arch/i386/kernel/i386_ksyms.c 2002-12-17 08:47:25.000000000 -0800
@@ -67,7 +67,6 @@ EXPORT_SYMBOL(EISA_bus);
EXPORT_SYMBOL(MCA_bus);
#ifdef CONFIG_DISCONTIGMEM
EXPORT_SYMBOL(node_data);
-EXPORT_SYMBOL(pfn_to_nid);
#endif
#ifdef CONFIG_X86_NUMAQ
EXPORT_SYMBOL(xquad_portio);
diff -urpN linux-2.5.52-mm1/arch/i386/kernel/numaq.c mm1-2.5.52-1/arch/i386/kernel/numaq.c
--- linux-2.5.52-mm1/arch/i386/kernel/numaq.c 2002-12-15 18:08:13.000000000 -0800
+++ mm1-2.5.52-1/arch/i386/kernel/numaq.c 2002-12-17 08:51:44.000000000 -0800
@@ -27,6 +27,7 @@
#include <linux/mm.h>
#include <linux/bootmem.h>
#include <linux/mmzone.h>
+#include <linux/module.h>
#include <asm/numaq.h>
/* These are needed before the pgdat's are created */
@@ -82,19 +83,7 @@ static void __init smp_dump_qct(void)
* physnode_map[8- ] = -1;
*/
int physnode_map[MAX_ELEMENTS] = { [0 ... (MAX_ELEMENTS - 1)] = -1};
-
-#define PFN_TO_ELEMENT(pfn) (pfn / PAGES_PER_ELEMENT)
-#define PA_TO_ELEMENT(pa) (PFN_TO_ELEMENT(pa >> PAGE_SHIFT))
-
-int pfn_to_nid(unsigned long pfn)
-{
- int nid = physnode_map[PFN_TO_ELEMENT(pfn)];
-
- if (nid == -1)
- BUG(); /* address is not present */
-
- return nid;
-}
+EXPORT_SYMBOL(physnode_map);
/*
* for each node mark the regions
diff -urpN linux-2.5.52-mm1/include/asm-i386/numaq.h mm1-2.5.52-1/include/asm-i386/numaq.h
--- linux-2.5.52-mm1/include/asm-i386/numaq.h 2002-12-15 18:08:09.000000000 -0800
+++ mm1-2.5.52-1/include/asm-i386/numaq.h 2002-12-17 08:45:19.000000000 -0800
@@ -38,10 +38,11 @@
#define MAX_ELEMENTS 256
#define PAGES_PER_ELEMENT (16777216/256)
+extern int physnode_map[];
+#define pfn_to_nid(pfn) ({ physnode_map[(pfn) / PAGES_PER_ELEMENT]; })
#define pfn_to_pgdat(pfn) NODE_DATA(pfn_to_nid(pfn))
#define PHYSADDR_TO_NID(pa) pfn_to_nid(pa >> PAGE_SHIFT)
#define MAX_NUMNODES 8
-extern int pfn_to_nid(unsigned long);
extern void get_memcfg_numaq(void);
#define get_memcfg_numa() get_memcfg_numaq()
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: Denis Vlasenko @ 2002-12-19 14:59 UTC (permalink / raw)
To: Till Immanuel Patzschke, lse-tech; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <3E0116D6.35CA202A@inw.de>
On 18 December 2002 22:46, Till Immanuel Patzschke wrote:
> Dear List(s),
>
> as part of my project I need to run a very high number of
> processes/threads on a linux machine. Right now I have a Dual-PIII
> 1.4G w/ 8GB RAM -- I am running 4000 processes w/ 2-3 threads each
> totaling in a process count of 15000+ processes (since Linux doesn't
> really distinguish between threads and processes...).
BTW, can you say _what_ are you trying to do?
> Once I pass the 10000 (+/-) pocesses load increases drastically (on
> startup, although it returns to normal), however the system time (on
> one processor) reaches for 54% (12061 procs) while the only non
> sleeping process is top -- the system is basically doing nothing
> (except scheduling the "nothing" which consumes significant system
> time).
> Is there anything I can do to reduce that system load/time? (I
> haven't been able to exactly define the "line" but it definitly gets
> worse the more processes need to be handled.)
> Does any of the patchsets address this particular problem?
> BTW: The processes are all alike...
You need to collect memory info (especially lowmem and highmem situation)
and maybe profile your kernel to find out where does it spend that time
doing "nothing".
BTW, your .config?
--
vda
^ permalink raw reply
* Re: [PATCH]: remove warnings on promlib
From: Juan Quintela @ 2002-12-19 10:17 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips, Ralf Baechle
In-Reply-To: <Pine.GSO.3.96.1021218174743.5977E-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 18 Dec 2002, Juan Quintela wrote:
>> Index: arch/mips/lib/promlib.c
>> ===================================================================
>> RCS file: /home/cvs/linux/arch/mips/lib/promlib.c,v
>> retrieving revision 1.1.2.1
>> diff -u -r1.1.2.1 promlib.c
>> --- arch/mips/lib/promlib.c 28 Sep 2002 22:28:38 -0000 1.1.2.1
>> +++ arch/mips/lib/promlib.c 18 Dec 2002 00:49:18 -0000
>> @@ -1,3 +1,7 @@
>> +
>> +#include <asm/sgialib.h>
>> +#include <linux/kernel.h>
>> +
>> #include <stdarg.h>
>>
>> void prom_printf(char *fmt, ...)
maciej> A few comments:
maciej> 1. <linux> includes first, <asm> ones following (hmm, shouldn't that be
maciej> obvious...).
maciej> 2. <linux/kernel.h> is obviously OK for vsprintf().
maciej> 3. I would hesitate using <asm/sgialib.h> here being too much platform
maciej> specific. Either a separate generic <asm/prom.h> should be created for
maciej> primitives like prom_putchar(), prom_getchar(), etc. or a private
maciej> conservative declaration should be used here. The reason is the functions
maciej> are much platform-specific, e.g. they may be pointers or even macros --
maciej> see <asm/dec/prom.h> for a not-so-trivial example (luckily, DECstations
maciej> support prom_printf() directly, so they don't have to use promlib.c).
Something like that?
Once there, s/vsprintf/vsnprintf/.
If anybody calls prom_printf with more than 1024 chars, we were b0rked
:((
I didn't did the changes for the other users of prom_* that was using
asm/sgialib.h, but change is trivial.
Later, Juan.
diff -uNp build/include/asm-mips/prom.h.orig build/include/asm-mips/prom.h
--- build/include/asm-mips/prom.h.orig 1970-01-01 01:00:00.000000000 +0100
+++ build/include/asm-mips/prom.h 2002-12-18 19:00:47.000000000 +0100
@@ -0,0 +1,21 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Interface with the low level prom consoles.
+ *
+ * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
+ * Copyright (C) 2001, 2002 Ralf Baechle (ralf@gnu.org)
+ */
+#ifndef _ASM_PROM_H
+#define _ASM_PROM_H
+
+/* Simple char-by-char console I/O. */
+extern void prom_putchar(char c);
+extern char prom_getchar(void);
+
+/* Generic printf() console I/O. */
+extern void prom_printf(char *fmt, ...);
+
+#endif /* _ASM_PROM_H */
Index: arch/mips/arc/init.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/arc/init.c,v
retrieving revision 1.10.2.3
diff -u -r1.10.2.3 init.c
--- arch/mips/arc/init.c 1 Aug 2002 22:26:40 -0000 1.10.2.3
+++ arch/mips/arc/init.c 19 Dec 2002 09:21:07 -0000
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <asm/sgialib.h>
+#include <asm/prom.h>
#undef DEBUG_PROM_INIT
Index: arch/mips/lib/promlib.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/lib/promlib.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 promlib.c
--- arch/mips/lib/promlib.c 28 Sep 2002 22:28:38 -0000 1.1.2.1
+++ arch/mips/lib/promlib.c 19 Dec 2002 09:21:08 -0000
@@ -1,13 +1,20 @@
+
+
+#include <linux/kernel.h>
+#include <asm/prom.h>
+
#include <stdarg.h>
+#define BUFSIZE 1024
+
void prom_printf(char *fmt, ...)
{
va_list args;
- char ppbuf[1024];
+ char ppbuf[BUFSIZE];
char *bptr;
va_start(args, fmt);
- vsprintf(ppbuf, fmt, args);
+ vsnprintf(ppbuf, BUFSIZE, fmt, args);
bptr = ppbuf;
Index: arch/mips/sgi-ip22/ip22-system.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-system.c,v
retrieving revision 1.1.2.8
diff -u -r1.1.2.8 ip22-system.c
--- arch/mips/sgi-ip22/ip22-system.c 18 Dec 2002 19:11:09 -0000 1.1.2.8
+++ arch/mips/sgi-ip22/ip22-system.c 19 Dec 2002 09:21:09 -0000
@@ -11,6 +11,7 @@
#include <asm/cpu.h>
#include <asm/sgi/sgi.h>
#include <asm/sgialib.h>
+#include <asm/prom.h>
enum sgi_mach sgimach;
Index: include/asm-mips/sgialib.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/sgialib.h,v
retrieving revision 1.10.2.3
diff -u -r1.10.2.3 sgialib.h
--- include/asm-mips/sgialib.h 1 Aug 2002 22:26:40 -0000 1.10.2.3
+++ include/asm-mips/sgialib.h 19 Dec 2002 09:21:15 -0000
@@ -30,13 +30,6 @@
/* Init the PROM library and it's internal data structures. */
extern void prom_init(int argc, char **argv, char **envp, int *prom_vec);
-/* Simple char-by-char console I/O. */
-extern void prom_putchar(char c);
-extern char prom_getchar(void);
-
-/* Generic printf() using ARCS console I/O. */
-extern void prom_printf(char *fmt, ...);
-
/* Memory descriptor management. */
#define PROM_MAX_PMEMBLOCKS 32
struct prom_pmemblock {
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.