Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Greg KH wrote: On Fri, Oct 13, 2000 at 02:44:32AM +0200, FORT David wrote: > > USB still have problems, when starting to grab with my ov511 webcam i got the > attached oops. This bug appeared > in test9-preX(X beeing at least > 2) series. Some people have claimed that > test10-pre1 fixed the problem, but > the bug is still present in the last two pre(test10-pre1 and test10-pre2). > To be noted: > -this oops is obtained with "Enforce USB bandwidth allocation", but it occurs > in the same place when disabled > -I'm using usb-uhci Does this same problem happen when using the uhci.o driver? greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg I've just tried "uhci" with and without "Enforce USB bandwidth allocation", it doesn't oops anymore, but instead the video device is always busy. -- %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France [EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--LINUX-HTTPD-PIOGENE% % -datamining <-/ | .~. % % -networking/flashed PHP3 coming soon | /V\ L I N U X % % -opensource | // \\ >Fear the Penguin< % % -GNOME/enlightenment/GIMP | /( )\ % % feel enlighted | ^^-^^ % % http://ibonneace.dnsalias.org/ when connected % %-%
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Hi,
On Fri, 13 Oct 2000, Richard Henderson wrote:
> Either that or adjust how we do atomic operations. I can do
> 64-bit atomic widgetry, but not with the code as written.
It's probably more something for 2.5, but what about adding a lock
argument to the atomic operations, then sparc could use that explicit lock
and everyone else simply optimizes that away. That would allow us to use
the full 32/64 bit. What we could get is a nice generic atomic exchange
command like:
atomic_exchange(lock, ptr, old, new);
Where new can be a (simple) expression which can include old. Especially
for risc system every atomic operation in atomic.h can be replaced with
this. Or if you need more flexibility the same can be written as:
atomic_enter(lock);
__atomic_init(ptr, old);
do {
__atomic_reserve(ptr, old);
} while (!__atomic_update(ptr, old, new));
atomic_leave(lock);
atomic_enter/atomic_enter are either normal spinlocks or (in most cases)
dummys. The other macros are either using RMW instructions or special
load/store instructions.
Using a lock makes it a bit more difficult to use and especially the last
construction must never be required in normal drivers. On the other hand
it gets way more flexible as we are not limited to a single atomic_t
anymore. If anyone is interested how it could look like, I've put an
example at http://zeus.fh-brandenburg.de/~zippel/linux/bin/atomic.tar.gz
(It also includes a bit more documentation and some (a bit outdated)
examples). Somewhere I also have a patch where I use this to write a
spinlock free printk implementation, which is still interrupt and SMP
safe.
There are still some issues open (like ordering), but I'd like to know if
there is a general interest in this.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Hi,
On Fri, 13 Oct 2000, Richard Henderson wrote:
Either that or adjust how we do atomic operations. I can do
64-bit atomic widgetry, but not with the code as written.
It's probably more something for 2.5, but what about adding a lock
argument to the atomic operations, then sparc could use that explicit lock
and everyone else simply optimizes that away. That would allow us to use
the full 32/64 bit. What we could get is a nice generic atomic exchange
command like:
atomic_exchange(lock, ptr, old, new);
Where new can be a (simple) expression which can include old. Especially
for risc system every atomic operation in atomic.h can be replaced with
this. Or if you need more flexibility the same can be written as:
atomic_enter(lock);
__atomic_init(ptr, old);
do {
__atomic_reserve(ptr, old);
} while (!__atomic_update(ptr, old, new));
atomic_leave(lock);
atomic_enter/atomic_enter are either normal spinlocks or (in most cases)
dummys. The other macros are either using RMW instructions or special
load/store instructions.
Using a lock makes it a bit more difficult to use and especially the last
construction must never be required in normal drivers. On the other hand
it gets way more flexible as we are not limited to a single atomic_t
anymore. If anyone is interested how it could look like, I've put an
example at http://zeus.fh-brandenburg.de/~zippel/linux/bin/atomic.tar.gz
(It also includes a bit more documentation and some (a bit outdated)
examples). Somewhere I also have a patch where I use this to write a
spinlock free printk implementation, which is still interrupt and SMP
safe.
There are still some issues open (like ordering), but I'd like to know if
there is a general interest in this.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Greg KH wrote: On Fri, Oct 13, 2000 at 02:44:32AM +0200, FORT David wrote: > > USB still have problems, when starting to grab with my ov511 webcam i got the > attached oops. This bug appeared > in test9-preX(X beeing at least > 2) series. Some people have claimed that > test10-pre1 fixed the problem, but > the bug is still present in the last two pre(test10-pre1 and test10-pre2). > To be noted: > -this oops is obtained with "Enforce USB bandwidth allocation", but it occurs > in the same place when disabled > -I'm using usb-uhci Does this same problem happen when using the uhci.o driver? greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg I've just tried "uhci" with and without "Enforce USB bandwidth allocation", it doesn't oops anymore, but instead the video device is always busy. -- %--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-% % FORT David, % % 7 avenue de la morvandire 0240726275 % % 44470 Thouare, France [EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--LINUX-HTTPD-PIOGENE% % -datamining -/ | .~. % % -networking/flashed PHP3 coming soon | /V\ L I N U X % % -opensource | // \\ >Fear the Penguin % % -GNOME/enlightenment/GIMP | /( )\ % % feel enlighted | ^^-^^ % % http://ibonneace.dnsalias.org/ when connected % %-%
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Date:Fri, 13 Oct 2000 15:57:50 -0700 From: Richard Henderson <[EMAIL PROTECTED]> Either that or adjust how we do atomic operations. I can do 64-bit atomic widgetry, but not with the code as written. Ultra can do it as well, and as far as I understand it ia64 64-bit atomic_t's shouldn't be a problem either. I would suggest we make a atomic64_t or similar different type. The space savings from using 32-bit normal atomic_t in all other situations is of real value. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 11:47:55PM +0100, Alan Cox wrote: > Then we need to use locking to protect the rss since on a big 64bit box > we can exceed 2^32 pages in theory and probably soon in practice. Either that or adjust how we do atomic operations. I can do 64-bit atomic widgetry, but not with the code as written. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 02:25:45PM -0700, Linus Torvalds wrote: > And even on alpha, a 32-bit atomic_t means we cover 45 bits of virtual > address space, which, btw, is more than you can cram into the current > three-level page tables, I think. While that's true of Alpha, it's not true of Ultra III, in which all 64-bits are in theory available to the user. Dave hasn't implemented that yet, AFAIK. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
> On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > > ultrsparc/alpha ? > > It is not. Then we need to use locking to protect the rss since on a big 64bit box we can exceed 2^32 pages in theory and probably soon in practice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 02:44:32AM +0200, FORT David wrote: > > USB still have problems, when starting to grab with my ov511 webcam i got the > attached oops. This bug appeared > in test9-preX(X beeing at least > 2) series. Some people have claimed that > test10-pre1 fixed the problem, but > the bug is still present in the last two pre(test10-pre1 and test10-pre2). > To be noted: > -this oops is obtained with "Enforce USB bandwidth allocation", but it occurs > in the same place when disabled > -I'm using usb-uhci Does this same problem happen when using the uhci.o driver? greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Date: Fri, 13 Oct 2000 12:45:47 +0100 (BST) From: Alan Cox <[EMAIL PROTECTED]> > It might make more sense to just make rss an atomic_t. Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the ultrsparc/alpha ? Yes, this issue occurred to me last night as well. It is 32-bit on Alpha/UltraSparc. However, given the fact that this number measures "pages", the PAGE_SIZE on Ultra/Alpha, and the size of the 64-bit user address space on Ultra and Alpha, it would actually end up working. This doesn't make it a good idea though. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, 13 Oct 2000, Jakub Jelinek wrote: > On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote: > > On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > > > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > > > ultrsparc/alpha ? > > > > It is not. > > It is not even 32bit on sparc32 (24bit only). But remember that "rss" counts in pages, so it's plenty for sparc32: only 32 bits of virtual address that can count towards the rss. And even on alpha, a 32-bit atomic_t means we cover 45 bits of virtual address space, which, btw, is more than you can cram into the current three-level page tables, I think. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote: > On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > > ultrsparc/alpha ? > > It is not. It is not even 32bit on sparc32 (24bit only). Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > ultrsparc/alpha ? It is not. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Fwiw:
- vmlist_modify_lock/unlock are turned into spin_lock/unlock;
- ditto for vmlist_access/unaccess;
- atomic_t rss (gross).
Excuse the incorrect In-Reply-To field (my mail archive for the day is
currently unavailable).
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/binfmt_aout.c
linux-2.4.0-test10-pre2/fs/binfmt_aout.c
--- linux-2.4.0-test10-pre2.orig/fs/binfmt_aout.c Fri Jul 7 22:54:01 2000
+++ linux-2.4.0-test10-pre2/fs/binfmt_aout.cFri Oct 13 16:45:45 2000
@@ -301,7 +301,7 @@
current->mm->brk = ex.a_bss +
(current->mm->start_brk = N_BSSADDR(ex));
- current->mm->rss = 0;
+ atomic_set(>mm->rss, 0);
current->mm->mmap = NULL;
compute_creds(bprm);
current->flags &= ~PF_FORKNOEXEC;
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/binfmt_elf.c
linux-2.4.0-test10-pre2/fs/binfmt_elf.c
--- linux-2.4.0-test10-pre2.orig/fs/binfmt_elf.cTue Sep 26 10:41:47 2000
+++ linux-2.4.0-test10-pre2/fs/binfmt_elf.c Fri Oct 13 16:40:34 2000
@@ -586,7 +586,7 @@
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
- current->mm->rss = 0;
+ atomic_set(>mm->rss, 0);
setup_arg_pages(bprm); /* XXX: check error */
current->mm->start_stack = bprm->p;
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/exec.c
linux-2.4.0-test10-pre2/fs/exec.c
--- linux-2.4.0-test10-pre2.orig/fs/exec.c Tue Sep 26 10:41:47 2000
+++ linux-2.4.0-test10-pre2/fs/exec.c Fri Oct 13 16:39:22 2000
@@ -314,9 +314,9 @@
mpnt->vm_pgoff = 0;
mpnt->vm_file = NULL;
mpnt->vm_private_data = (void *) 0;
- vmlist_modify_lock(current->mm);
+ spin_lock(>mm->page_table_lock);
insert_vm_struct(current->mm, mpnt);
- vmlist_modify_unlock(current->mm);
+ spin_unlock(>mm->page_table_lock);
current->mm->total_vm = (mpnt->vm_end - mpnt->vm_start) >> PAGE_SHIFT;
}
@@ -324,7 +324,7 @@
struct page *page = bprm->page[i];
if (page) {
bprm->page[i] = NULL;
- current->mm->rss++;
+ atomic_inc(>mm->rss);
put_dirty_page(current,page,stack_base);
}
stack_base += PAGE_SIZE;
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/proc/array.c
linux-2.4.0-test10-pre2/fs/proc/array.c
--- linux-2.4.0-test10-pre2.orig/fs/proc/array.cFri Oct 13 09:58:47 2000
+++ linux-2.4.0-test10-pre2/fs/proc/array.c Fri Oct 13 16:37:47 2000
@@ -202,14 +202,14 @@
buffer += sprintf(buffer,
"VmSize:\t%8lu kB\n"
"VmLck:\t%8lu kB\n"
- "VmRSS:\t%8lu kB\n"
+ "VmRSS:\t%8u kB\n"
"VmData:\t%8lu kB\n"
"VmStk:\t%8lu kB\n"
"VmExe:\t%8lu kB\n"
"VmLib:\t%8lu kB\n",
mm->total_vm << (PAGE_SHIFT-10),
mm->locked_vm << (PAGE_SHIFT-10),
- mm->rss << (PAGE_SHIFT-10),
+ atomic_read(>rss) << (PAGE_SHIFT-10),
data - stack, stack,
exec - lib, lib);
up(>mmap_sem);
@@ -371,7 +371,8 @@
task->it_real_value,
task->start_time,
vsize,
- mm ? mm->rss : 0, /* you might want to shift this left 3 */
+ /* you might want to shift this left 3 */
+ mm ? atomic_read(>rss) : 0,
task->rlim ? task->rlim[RLIMIT_RSS].rlim_cur : 0,
mm ? mm->start_code : 0,
mm ? mm->end_code : 0,
diff -u --recursive linux-2.4.0-test10-pre2.orig/include/linux/mm.h
linux-2.4.0-test10-pre2/include/linux/mm.h
--- linux-2.4.0-test10-pre2.orig/include/linux/mm.h Tue Oct 3 20:16:16 2000
+++ linux-2.4.0-test10-pre2/include/linux/mm.h Fri Oct 13 10:54:19 2000
@@ -527,11 +527,6 @@
#define pgcache_under_min()(atomic_read(_cache_size) * 100 < \
page_cache.min_percent * num_physpages)
-#define vmlist_access_lock(mm) spin_lock(>page_table_lock)
-#define vmlist_access_unlock(mm) spin_unlock(>page_table_lock)
-#define vmlist_modify_lock(mm) vmlist_access_lock(mm)
-#define vmlist_modify_unlock(mm) vmlist_access_unlock(mm)
-
#endif /* __KERNEL__ */
#endif
diff -u --recursive linux-2.4.0-test10-pre2.orig/include/linux/sched.h
linux-2.4.0-test10-pre2/include/linux/sched.h
--- linux-2.4.0-test10-pre2.orig/include/linux/sched.h Fri Oct 13 09:58:47 2000
+++ linux-2.4.0-test10-pre2/include/linux/sched.h Fri Oct 13 10:19:37 2000
@@ -207,7 +207,8 @@
unsigned long start_code, end_code, start_data, end_data;
unsigned long start_brk, brk, start_stack;
unsigned long arg_start, arg_end, env_start, env_end;
- unsigned long
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
>
>
> On Thu, 12 Oct 2000, David S. Miller wrote:
> >
> >page_table_lock is supposed to protect normal page table activity (like
> >what's done in page fault handler) from swapping out.
> >However, grabbing this lock in swap-out code is completely missing!
> >
> > Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
>
> Yeah, it's an easy mistake to make.
>
> I've made it myself - grepping for page_table_lock and coming up empty in
> places where I expected it to be.
>
> In fact, if somebody sends me patches to remove the "vmlist_access_lock()"
> stuff completely, and replace them with explicit page_table_lock things,
> I'll apply it pretty much immediately. I don't like information hiding,
> and right now that's the only thing that the vmlist_access_lock() stuff is
> doing.
Linus,
I came up with the vmlist_access_lock/vmlist_modify_lock names early in
2.3. The reasoning behind that was that in most places where the "vmlist
lock" was being taken was to protect the vmlist chain, vma_t fields or
mm_struct fields. The fact that implementation wise this lock could be
the same as page_table_lock was a good idea that you suggested.
Nevertheless, the name was chosen to indicate what type of things it was
guarding. For example, in the future, you might actually have a different
(possibly sleeping) lock to guard the vmachain etc, but still have a
spin lock for the page_table_lock (No, I don't want to be drawn into a
discussion of why this might be needed right now). Some of this is
mentioned in Documentation/vm/locking.
Just thought I would mention, in case you don't recollect some of this
history. Of course, I understand the "information hiding" part.
Kanoj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
> In fact, if somebody sends me patches to remove the "vmlist_access_lock()"
> stuff completely, and replace them with explicit page_table_lock things,
> I'll apply it pretty much immediately. I don't like information hiding,
> and right now that's the only thing that the vmlist_access_lock() stuff is
> doing.
(Pruned the cc-list and added Rik van Riel since this touches his
code domain.)
Something like this?
diff -aur linux-240-test10-pre1/fs/exec.c linux/fs/exec.c
--- linux-240-test10-pre1/fs/exec.c Mon Oct 2 22:32:47 2000
+++ linux/fs/exec.c Fri Oct 13 16:01:29 2000
@@ -314,9 +314,9 @@
mpnt->vm_pgoff = 0;
mpnt->vm_file = NULL;
mpnt->vm_private_data = (void *) 0;
- vmlist_modify_lock(current->mm);
+ spin_lock(>mm->page_table_lock);
insert_vm_struct(current->mm, mpnt);
- vmlist_modify_unlock(current->mm);
+ spin_unlock(>mm->page_table_lock);
current->mm->total_vm = (mpnt->vm_end - mpnt->vm_start) >> PAGE_SHIFT;
}
diff -aur linux-240-test10-pre1/include/linux/mm.h linux/include/linux/mm.h
--- linux-240-test10-pre1/include/linux/mm.hTue Oct 3 22:12:52 2000
+++ linux/include/linux/mm.hFri Oct 13 18:43:42 2000
@@ -527,11 +527,6 @@
#define pgcache_under_min()(atomic_read(_cache_size) * 100 < \
page_cache.min_percent * num_physpages)
-#define vmlist_access_lock(mm) spin_lock(>page_table_lock)
-#define vmlist_access_unlock(mm) spin_unlock(>page_table_lock)
-#define vmlist_modify_lock(mm) vmlist_access_lock(mm)
-#define vmlist_modify_unlock(mm) vmlist_access_unlock(mm)
-
#endif /* __KERNEL__ */
#endif
diff -aur linux-240-test10-pre1/mm/filemap.c linux/mm/filemap.c
--- linux-240-test10-pre1/mm/filemap.c Tue Oct 3 22:12:52 2000
+++ linux/mm/filemap.c Fri Oct 13 16:01:29 2000
@@ -1766,11 +1766,11 @@
get_file(n->vm_file);
if (n->vm_ops && n->vm_ops->open)
n->vm_ops->open(n);
- vmlist_modify_lock(vma->vm_mm);
+ spin_lock(>vm_mm->page_table_lock);
vma->vm_pgoff += (end - vma->vm_start) >> PAGE_SHIFT;
vma->vm_start = end;
insert_vm_struct(current->mm, n);
- vmlist_modify_unlock(vma->vm_mm);
+ spin_unlock(>vm_mm->page_table_lock);
return 0;
}
@@ -1790,10 +1790,10 @@
get_file(n->vm_file);
if (n->vm_ops && n->vm_ops->open)
n->vm_ops->open(n);
- vmlist_modify_lock(vma->vm_mm);
+ spin_lock(>vm_mm->page_table_lock);
vma->vm_end = start;
insert_vm_struct(current->mm, n);
- vmlist_modify_unlock(vma->vm_mm);
+ spin_unlock(>vm_mm->page_table_lock);
return 0;
}
@@ -1823,7 +1823,7 @@
vma->vm_ops->open(left);
vma->vm_ops->open(right);
}
- vmlist_modify_lock(vma->vm_mm);
+ spin_lock(>vm_mm->page_table_lock);
vma->vm_pgoff += (start - vma->vm_start) >> PAGE_SHIFT;
vma->vm_start = start;
vma->vm_end = end;
@@ -1831,7 +1831,7 @@
vma->vm_raend = 0;
insert_vm_struct(current->mm, left);
insert_vm_struct(current->mm, right);
- vmlist_modify_unlock(vma->vm_mm);
+ spin_unlock(>vm_mm->page_table_lock);
return 0;
}
diff -aur linux-240-test10-pre1/mm/mlock.c linux/mm/mlock.c
--- linux-240-test10-pre1/mm/mlock.cWed Mar 15 02:45:20 2000
+++ linux/mm/mlock.cFri Oct 13 16:01:29 2000
@@ -14,9 +14,9 @@
static inline int mlock_fixup_all(struct vm_area_struct * vma, int newflags)
{
- vmlist_modify_lock(vma->vm_mm);
+ spin_lock(>vm_mm->page_table_lock);
vma->vm_flags = newflags;
- vmlist_modify_unlock(vma->vm_mm);
+ spin_unlock(>vm_mm->page_table_lock);
return 0;
}
@@ -36,11 +36,11 @@
get_file(n->vm_file);
if (n->vm_ops && n->vm_ops->open)
n->vm_ops->open(n);
- vmlist_modify_lock(vma->vm_mm);
+ spin_lock(>vm_mm->page_table_lock);
vma->vm_pgoff += (end - vma->vm_start) >> PAGE_SHIFT;
vma->vm_start = end;
insert_vm_struct(current->mm, n);
- vmlist_modify_unlock(vma->vm_mm);
+ spin_unlock(>vm_mm->page_table_lock);
return 0;
}
@@ -61,10 +61,10 @@
get_file(n->vm_file);
if (n->vm_ops && n->vm_ops->open)
n->vm_ops->open(n);
- vmlist_modify_lock(vma->vm_mm);
+ spin_lock(>vm_mm->page_table_lock);
vma->vm_end = start;
insert_vm_struct(current->mm, n);
- vmlist_modify_unlock(vma->vm_mm);
+ spin_unlock(>vm_mm->page_table_lock);
return 0;
}
@@ -96,7 +96,7 @@
vma->vm_ops->open(left);
vma->vm_ops->open(right);
}
- vmlist_modify_lock(vma->vm_mm);
+ spin_lock(>vm_mm->page_table_lock);
vma->vm_pgoff += (start - vma->vm_start) >> PAGE_SHIFT;
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Fwiw:
- vmlist_modify_lock/unlock are turned into spin_lock/unlock;
- ditto for vmlist_access/unaccess;
- atomic_t rss (gross).
Excuse the incorrect In-Reply-To field (my mail archive for the day is
currently unavailable).
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/binfmt_aout.c
linux-2.4.0-test10-pre2/fs/binfmt_aout.c
--- linux-2.4.0-test10-pre2.orig/fs/binfmt_aout.c Fri Jul 7 22:54:01 2000
+++ linux-2.4.0-test10-pre2/fs/binfmt_aout.cFri Oct 13 16:45:45 2000
@@ -301,7 +301,7 @@
current-mm-brk = ex.a_bss +
(current-mm-start_brk = N_BSSADDR(ex));
- current-mm-rss = 0;
+ atomic_set(current-mm-rss, 0);
current-mm-mmap = NULL;
compute_creds(bprm);
current-flags = ~PF_FORKNOEXEC;
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/binfmt_elf.c
linux-2.4.0-test10-pre2/fs/binfmt_elf.c
--- linux-2.4.0-test10-pre2.orig/fs/binfmt_elf.cTue Sep 26 10:41:47 2000
+++ linux-2.4.0-test10-pre2/fs/binfmt_elf.c Fri Oct 13 16:40:34 2000
@@ -586,7 +586,7 @@
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
- current-mm-rss = 0;
+ atomic_set(current-mm-rss, 0);
setup_arg_pages(bprm); /* XXX: check error */
current-mm-start_stack = bprm-p;
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/exec.c
linux-2.4.0-test10-pre2/fs/exec.c
--- linux-2.4.0-test10-pre2.orig/fs/exec.c Tue Sep 26 10:41:47 2000
+++ linux-2.4.0-test10-pre2/fs/exec.c Fri Oct 13 16:39:22 2000
@@ -314,9 +314,9 @@
mpnt-vm_pgoff = 0;
mpnt-vm_file = NULL;
mpnt-vm_private_data = (void *) 0;
- vmlist_modify_lock(current-mm);
+ spin_lock(current-mm-page_table_lock);
insert_vm_struct(current-mm, mpnt);
- vmlist_modify_unlock(current-mm);
+ spin_unlock(current-mm-page_table_lock);
current-mm-total_vm = (mpnt-vm_end - mpnt-vm_start) PAGE_SHIFT;
}
@@ -324,7 +324,7 @@
struct page *page = bprm-page[i];
if (page) {
bprm-page[i] = NULL;
- current-mm-rss++;
+ atomic_inc(current-mm-rss);
put_dirty_page(current,page,stack_base);
}
stack_base += PAGE_SIZE;
diff -u --recursive linux-2.4.0-test10-pre2.orig/fs/proc/array.c
linux-2.4.0-test10-pre2/fs/proc/array.c
--- linux-2.4.0-test10-pre2.orig/fs/proc/array.cFri Oct 13 09:58:47 2000
+++ linux-2.4.0-test10-pre2/fs/proc/array.c Fri Oct 13 16:37:47 2000
@@ -202,14 +202,14 @@
buffer += sprintf(buffer,
"VmSize:\t%8lu kB\n"
"VmLck:\t%8lu kB\n"
- "VmRSS:\t%8lu kB\n"
+ "VmRSS:\t%8u kB\n"
"VmData:\t%8lu kB\n"
"VmStk:\t%8lu kB\n"
"VmExe:\t%8lu kB\n"
"VmLib:\t%8lu kB\n",
mm-total_vm (PAGE_SHIFT-10),
mm-locked_vm (PAGE_SHIFT-10),
- mm-rss (PAGE_SHIFT-10),
+ atomic_read(mm-rss) (PAGE_SHIFT-10),
data - stack, stack,
exec - lib, lib);
up(mm-mmap_sem);
@@ -371,7 +371,8 @@
task-it_real_value,
task-start_time,
vsize,
- mm ? mm-rss : 0, /* you might want to shift this left 3 */
+ /* you might want to shift this left 3 */
+ mm ? atomic_read(mm-rss) : 0,
task-rlim ? task-rlim[RLIMIT_RSS].rlim_cur : 0,
mm ? mm-start_code : 0,
mm ? mm-end_code : 0,
diff -u --recursive linux-2.4.0-test10-pre2.orig/include/linux/mm.h
linux-2.4.0-test10-pre2/include/linux/mm.h
--- linux-2.4.0-test10-pre2.orig/include/linux/mm.h Tue Oct 3 20:16:16 2000
+++ linux-2.4.0-test10-pre2/include/linux/mm.h Fri Oct 13 10:54:19 2000
@@ -527,11 +527,6 @@
#define pgcache_under_min()(atomic_read(page_cache_size) * 100 \
page_cache.min_percent * num_physpages)
-#define vmlist_access_lock(mm) spin_lock(mm-page_table_lock)
-#define vmlist_access_unlock(mm) spin_unlock(mm-page_table_lock)
-#define vmlist_modify_lock(mm) vmlist_access_lock(mm)
-#define vmlist_modify_unlock(mm) vmlist_access_unlock(mm)
-
#endif /* __KERNEL__ */
#endif
diff -u --recursive linux-2.4.0-test10-pre2.orig/include/linux/sched.h
linux-2.4.0-test10-pre2/include/linux/sched.h
--- linux-2.4.0-test10-pre2.orig/include/linux/sched.h Fri Oct 13 09:58:47 2000
+++ linux-2.4.0-test10-pre2/include/linux/sched.h Fri Oct 13 10:19:37 2000
@@ -207,7 +207,8 @@
unsigned long start_code, end_code, start_data, end_data;
unsigned long start_brk, brk, start_stack;
unsigned long arg_start, arg_end, env_start, env_end;
- unsigned long rss,
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, 13 Oct 2000, Jakub Jelinek wrote: On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote: On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: Can we always be sure the rss will fit in an atomic_t - is it 32bits on the ultrsparc/alpha ? It is not. It is not even 32bit on sparc32 (24bit only). But remember that "rss" counts in pages, so it's plenty for sparc32: only 32 bits of virtual address that can count towards the rss. And even on alpha, a 32-bit atomic_t means we cover 45 bits of virtual address space, which, btw, is more than you can cram into the current three-level page tables, I think. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Date: Fri, 13 Oct 2000 12:45:47 +0100 (BST) From: Alan Cox [EMAIL PROTECTED] It might make more sense to just make rss an atomic_t. Can we always be sure the rss will fit in an atomic_t - is it 32bits on the ultrsparc/alpha ? Yes, this issue occurred to me last night as well. It is 32-bit on Alpha/UltraSparc. However, given the fact that this number measures "pages", the PAGE_SIZE on Ultra/Alpha, and the size of the 64-bit user address space on Ultra and Alpha, it would actually end up working. This doesn't make it a good idea though. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 02:44:32AM +0200, FORT David wrote: USB still have problems, when starting to grab with my ov511 webcam i got the attached oops. This bug appeared in test9-preX(X beeing at least 2) series. Some people have claimed that test10-pre1 fixed the problem, but the bug is still present in the last two pre(test10-pre1 and test10-pre2). To be noted: -this oops is obtained with "Enforce USB bandwidth allocation", but it occurs in the same place when disabled -I'm using usb-uhci Does this same problem happen when using the uhci.o driver? greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000, David S. Miller wrote:
>
>page_table_lock is supposed to protect normal page table activity (like
>what's done in page fault handler) from swapping out.
>However, grabbing this lock in swap-out code is completely missing!
>
> Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
Yeah, it's an easy mistake to make.
I've made it myself - grepping for page_table_lock and coming up empty in
places where I expected it to be.
In fact, if somebody sends me patches to remove the "vmlist_access_lock()"
stuff completely, and replace them with explicit page_table_lock things,
I'll apply it pretty much immediately. I don't like information hiding,
and right now that's the only thing that the vmlist_access_lock() stuff is
doing.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000, David S. Miller wrote: > >Any of the mm gurus give the patch below a quick once over ? Is >this adequate, or is there more to this than the description >implies? > > It might make more sense to just make rss an atomic_t. Agreed. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12, 2000 at 09:25:47PM -0700, David S. Miller wrote:
>Date: Fri, 13 Oct 2000 12:34:30 +0800
>From: Andrey Savochkin <[EMAIL PROTECTED]>
>
>page_table_lock is supposed to protect normal page table activity (like
>what's done in page fault handler) from swapping out.
>However, grabbing this lock in swap-out code is completely missing!
>
> Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
>
> You've totally missed this and thus your suggested-patch/analysis
> needs to be reevaluated :-)
Oops
You're of course right.
It looks as if somebody tried to separate this two locks and stopped in the
middle...
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Date: Fri, 13 Oct 2000 12:34:30 +0800
From: Andrey Savochkin <[EMAIL PROTECTED]>
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
You've totally missed this and thus your suggested-patch/analysis
needs to be reevaluated :-)
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Hello,
On Fri, Oct 13, 2000 at 01:20:23AM +0100, [EMAIL PROTECTED] wrote:
> > 9. To Do
> > * mm->rss is modified in some places without holding the
> > page_table_lock (sct)
>
> Any of the mm gurus give the patch below a quick once over ?
> Is this adequate, or is there more to this than the description implies?
The patch is basically ok, except one point.
[snip]
> diff -urN --exclude-from=/home/davej/.exclude linux/mm/vmscan.c linux.dj/mm/vmscan.c
> --- linux/mm/vmscan.c Mon Oct 2 20:02:20 2000
> +++ linux.dj/mm/vmscan.c Wed Oct 11 23:46:01 2000
> @@ -102,7 +102,9 @@
> set_pte(page_table, swp_entry_to_pte(entry));
> drop_pte:
> UnlockPage(page);
> + spin_lock (>page_table_lock);
> mm->rss--;
> + spin_unlock (>page_table_lock);
> flush_tlb_page(vma, address);
> deactivate_page(page);
> page_cache_release(page);
> @@ -170,7 +172,9 @@
> struct file *file = vma->vm_file;
> if (file) get_file(file);
> pte_clear(page_table);
> + spin_lock (>page_table_lock);
> mm->rss--;
> + spin_unlock (>page_table_lock);
> flush_tlb_page(vma, address);
> vmlist_access_unlock(mm);
> error = swapout(page, file);
> @@ -202,7 +206,9 @@
> add_to_swap_cache(page, entry);
>
> /* Put the swap entry into the pte after the page is in swapcache */
> + spin_lock (>page_table_lock);
> mm->rss--;
> + spin_unlock (>page_table_lock);
> set_pte(page_table, swp_entry_to_pte(entry));
> flush_tlb_page(vma, address);
> vmlist_access_unlock(mm);
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
In vmscan.c the question is not only about rss protection, but about real
protection for page table entries.
It may be something like
--- mm/vmscan.c.ptl Fri Oct 13 12:09:51 2000
+++ mm/vmscan.c Fri Oct 13 12:19:10 2000
@@ -150,6 +150,7 @@
if (file) get_file(file);
pte_clear(page_table);
vma->vm_mm->rss--;
+ spin_unlock(>page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(vma->vm_mm);
error = swapout(page, file);
@@ -182,6 +183,7 @@
/* Put the swap entry into the pte after the page is in swapcache */
vma->vm_mm->rss--;
set_pte(page_table, swp_entry_to_pte(entry));
+ spin_unlock(>page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(vma->vm_mm);
@@ -324,6 +326,7 @@
if (address < vma->vm_start)
address = vma->vm_start;
+ spin_lock(>page_table_lock);
for (;;) {
int result = swap_out_vma(mm, vma, address, gfp_mask);
if (result)
@@ -333,6 +336,7 @@
break;
address = vma->vm_start;
}
+ spin_unlock(>page_table_lock);
}
vmlist_access_unlock(mm);
On Thu, Oct 12, 2000 at 05:29:39PM -0700, David S. Miller wrote:
>From: [EMAIL PROTECTED]
>Date: Fri, 13 Oct 2000 01:20:23 +0100 (BST)
>
>Any of the mm gurus give the patch below a quick once over ? Is
>this adequate, or is there more to this than the description
>implies?
>
> It might make more sense to just make rss an atomic_t.
In most cases where rss is updated page_table_lock is already held.
Best regards
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
From: [EMAIL PROTECTED] Date:Fri, 13 Oct 2000 01:20:23 +0100 (BST) Any of the mm gurus give the patch below a quick once over ? Is this adequate, or is there more to this than the description implies? It might make more sense to just make rss an atomic_t. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
> 9. To Do
> * mm->rss is modified in some places without holding the
> page_table_lock (sct)
Any of the mm gurus give the patch below a quick once over ?
Is this adequate, or is there more to this than the description implies?
regards,
Dave.
--
| Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/mm/memory.c linux.dj/mm/memory.c
--- linux/mm/memory.c Sat Sep 16 00:51:21 2000
+++ linux.dj/mm/memory.cWed Oct 11 23:41:10 2000
@@ -370,7 +370,6 @@
address = (address + PGDIR_SIZE) & PGDIR_MASK;
dir++;
} while (address && (address < end));
- spin_unlock(>page_table_lock);
/*
* Update rss for the mm_struct (not necessarily current->mm)
* Notice that rss is an unsigned long.
@@ -379,6 +378,7 @@
mm->rss -= freed;
else
mm->rss = 0;
+ spin_unlock(>page_table_lock);
}
@@ -1074,7 +1074,9 @@
flush_icache_page(vma, page);
}
+ spin_lock(>page_table_lock);
mm->rss++;
+ spin_unlock(>page_table_lock);
pte = mk_pte(page, vma->vm_page_prot);
@@ -1113,7 +1115,9 @@
return -1;
clear_user_highpage(page, addr);
entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
+ spin_lock(>page_table_lock);
mm->rss++;
+ spin_unlock(>page_table_lock);
flush_page_to_ram(page);
}
set_pte(page_table, entry);
@@ -1152,7 +1156,9 @@
return 0;
if (new_page == NOPAGE_OOM)
return -1;
+ spin_lock(>page_table_lock);
++mm->rss;
+ spin_unlock(>page_table_lock);
/*
* This silly early PAGE_DIRTY setting removes a race
* due to the bad i386 page protection. But it's valid
diff -urN --exclude-from=/home/davej/.exclude linux/mm/mmap.c linux.dj/mm/mmap.c
--- linux/mm/mmap.c Tue Aug 29 20:41:12 2000
+++ linux.dj/mm/mmap.c Wed Oct 11 23:48:30 2000
@@ -844,7 +844,9 @@
vmlist_modify_lock(mm);
mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL;
vmlist_modify_unlock(mm);
+ spin_lock (>page_table_lock);
mm->rss = 0;
+ spin_unlock (>page_table_lock);
mm->total_vm = 0;
mm->locked_vm = 0;
while (mpnt) {
diff -urN --exclude-from=/home/davej/.exclude linux/mm/vmscan.c linux.dj/mm/vmscan.c
--- linux/mm/vmscan.c Mon Oct 2 20:02:20 2000
+++ linux.dj/mm/vmscan.cWed Oct 11 23:46:01 2000
@@ -102,7 +102,9 @@
set_pte(page_table, swp_entry_to_pte(entry));
drop_pte:
UnlockPage(page);
+ spin_lock (>page_table_lock);
mm->rss--;
+ spin_unlock (>page_table_lock);
flush_tlb_page(vma, address);
deactivate_page(page);
page_cache_release(page);
@@ -170,7 +172,9 @@
struct file *file = vma->vm_file;
if (file) get_file(file);
pte_clear(page_table);
+ spin_lock (>page_table_lock);
mm->rss--;
+ spin_unlock (>page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
error = swapout(page, file);
@@ -202,7 +206,9 @@
add_to_swap_cache(page, entry);
/* Put the swap entry into the pte after the page is in swapcache */
+ spin_lock (>page_table_lock);
mm->rss--;
+ spin_unlock (>page_table_lock);
set_pte(page_table, swp_entry_to_pte(entry));
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Greg KH wrote:
On Thu, Oct 12, 2000 at 08:06:46AM -0400, [EMAIL PROTECTED]
wrote:
> * USB: booting with USB compiled into
kernel causes a lot of syslog
> entries as the root hubs
are probed by all drivers (this is
> especially obnoxious as
the usb-serial drivers start up)
Fixed in test9. If anyone still sees this, please let me know.
> * USB: fix setting urb->dev in printer,
acm, bluetooth, all serial
> drivers (Greg KH) {CRITICAL}
Fixed in test10-pre1.
> * USB: fix usb-uhci setting urb->dev
= NULL at correct places only
> {CRITICAL}
Fixed in test10-pre1.
thanks,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
USB still have problems, when starting to grab with my ov511 webcam i got
the attached oops. This bug appeared
in test9-preX(X beeing at least > 2) series. Some people have
claimed that test10-pre1 fixed the problem, but
the bug is still present in the last two pre(test10-pre1 and test10-pre2).
To be noted:
-this oops is obtained with "Enforce USB bandwidth allocation", but
it occurs in the same place when disabled
-I'm using usb-uhci
-the attached oops is truncated as each following schedule call produce
a new oops
--
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière 0240726275 %
% 44470 Thouare, France [EMAIL PROTECTED] %
% ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
% -datamining <-/ | .~. %
% -networking/flashed PHP3 coming soon | /V\ L I N U X %
% -opensource | // \\ >Fear the Penguin< %
% -GNOME/enlightenment/GIMP | /( )\ %
% feel enlighted | ^^-^^ %
% http://ibonneace.dnsalias.org/ when connected %
%-%
ksymoops 2.3.4 on i686 2.4.0-test10. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test10/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference at virtual address 00a0
c8c7365d
*pde =
Oops:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00013246
eax: ebx: c6e26480 ecx: edx: 0028
esi: c6e26480 edi: c2bb8d9c ebp: esp: c0d05f28
ds: 0018 es: 0018 ss: 0018
Process X (pid: 974, stackpage=c0d05000)
Stack: c1b236a8 c8c84814 c6e26480 0001 c1b236a8 c2bb8d80 c2bb8d9c
0001 c8c849bf c2bb8d80 c6e26488 c2fc4b60 0401
0020 000a c0020020 c010be71 000a c2bb8d80 c0d05fc4 c0282740
Call Trace: [] [] [] [] []
Code: 8b 91 a0 00 00 00 8b 43 30 29 42 28 83 7c 24 10 00 74 10 8b
>>EIP; c8c7365d <[usbcore]usb_release_bandwidth+9/60> <=
Trace; c8c84814 <[usb-uhci]process_urb+d4/1f0>
Trace; c8c849bf <[usb-uhci]uhci_interrupt+8f/e8>
Trace; c010be71
Trace; c010c056
Trace; c010a7c0
Code; c8c7365d <[usbcore]usb_release_bandwidth+9/60>
<_EIP>:
Code; c8c7365d <[usbcore]usb_release_bandwidth+9/60> <=
0: 8b 91 a0 00 00 00 mov0xa0(%ecx),%edx <=
Code; c8c73663 <[usbcore]usb_release_bandwidth+f/60>
6: 8b 43 30 mov0x30(%ebx),%eax
Code; c8c73666 <[usbcore]usb_release_bandwidth+12/60>
9: 29 42 28 sub%eax,0x28(%edx)
Code; c8c73669 <[usbcore]usb_release_bandwidth+15/60>
c: 83 7c 24 10 00cmpl $0x0,0x10(%esp,1)
Code; c8c7366e <[usbcore]usb_release_bandwidth+1a/60>
11: 74 10 je 23 <_EIP+0x23> c8c73680
<[usbcore]usb_release_bandwidth+2c/60>
Code; c8c73670 <[usbcore]usb_release_bandwidth+1c/60>
13: 8b 00 mov(%eax),%eax
Aiee, killing interrupt handler
invalid operand:
CPU:1
EIP:0010:[]
EFLAGS: 00013282
eax: 001b ebx: ecx: 001b edx: c021a8e8
esi: c5bce9e0 edi: c0d04000 ebp: c0d05cec esp: c0d05cac
ds: 0018 es: 0018 ss: 0018
Process X (pid: 974, stackpage=c0d05000)
Stack: c01e6e45 c01e7016 02b8 c5bce9e0 c0d04000 3286 c5bce9e0
c0d04000 c5bcea28 c0185373 c12b9e60
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
> * USB: system hang with USB audio driver {CRITICAL} (David
>Woodhouse, Randy Dunlap, Narayan Desai)
This is necessary but not sufficient:
Index: drivers/usb/audio.c
===
RCS file: /net/passion/inst/cvs/linux/drivers/usb/audio.c,v
retrieving revision 1.1.2.31
diff -u -r1.1.2.31 audio.c
--- drivers/usb/audio.c 2000/09/07 08:26:12 1.1.2.31
+++ drivers/usb/audio.c 2000/10/12 21:33:22
@@ -1007,8 +1007,10 @@
}
spin_lock_irqsave(>lock, flags);
}
- if (u->dma.count >= u->dma.dmasize && !u->dma.mapped)
+ if (u->dma.count >= u->dma.dmasize && !u->dma.mapped) {
+ spin_unlock_irqrestore(>lock, flags);
return 0;
+ }
u->flags |= FLG_RUNNING;
if (!(u->flags & FLG_URB0RUNNING)) {
urb = >durb[0].urb;
@@ -1368,8 +1370,10 @@
}
spin_lock_irqsave(>lock, flags);
}
- if (u->dma.count <= 0 && !u->dma.mapped)
+ if (u->dma.count <= 0 && !u->dma.mapped) {
+ spin_unlock_irqrestore(>lock, flags);
return 0;
+ }
u->flags |= FLG_RUNNING;
if (!(u->flags & FLG_URB0RUNNING)) {
urb = >durb[0].urb;
That fixes failure mode #1, in which the NMI watchdog gets triggered and
all subsequent attempts to open /dev/audio just block.
Unfortunately, it doesn't affect failure mode #2, in which the machine
just dies completely.
as->lock isn't locked when this happens - the last time
it was altered was at the end of usbout_start (line 1435).
wait_on_irq, CPU 0:
irq: 1 [ 0 1 ]
bh: 0 [ 1 0 ]
850f00e4 00a0 0fe0458b b70f00b7 0cec83c0 5c4ee850 c483fffd 85896610
e7a2 a2858b66 0fe7 6850c0b7 080e83c2 006a016a 00d373e8 10c48300
Call Trace: [] [] [] [] []
[] []
[] [] [] [] [] []
[] []
< ... LOTS of similarly unbelievable addresses ... >
[] [] [] [] [] []
[] []
c62e5000 0001 c62e5764 c016a6a2 c03087a0
c62e5364 c0170b72 c62e5000 c029f00c c011d597 0001 c02f559
Call Trace: [] [] [] [] []
[] []
[] [] [] [] []
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; ec83e045
Trace; e900
Trace; c010be0d <__global_cli+8d/12c>
Trace; c0247f68
Trace; c016a6a2
Trace; c0170b72
Trace; c011d597
Trace; c011d4ba
Trace; c010c1ea
Trace; c010a8b4
Trace; c0241150
Trace; c013614d
Trace; c0108d53
The trace always include __global_cli(), obviously -
wait_on_irq() can't get called from anywhere else, AIUI. The rest of
the trace (except for the lines immediately above and below __global_cli
-- c0247f53 and c0247f68) is different each time.
The stack of the 'other' CPU each time is crap. Whether it's _really_ crap
or whether the code in show() is just doing something wrong I'm not sure.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12, 2000 at 08:06:46AM -0400, [EMAIL PROTECTED] wrote:
> * USB: booting with USB compiled into kernel causes a lot of syslog
>entries as the root hubs are probed by all drivers (this is
>especially obnoxious as the usb-serial drivers start up)
Fixed in test9. If anyone still sees this, please let me know.
> * USB: fix setting urb->dev in printer, acm, bluetooth, all serial
>drivers (Greg KH) {CRITICAL}
Fixed in test10-pre1.
> * USB: fix usb-uhci setting urb->dev = NULL at correct places only
>{CRITICAL}
Fixed in test10-pre1.
thanks,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
"[EMAIL PROTECTED] wrote:" > * Use PCI DMA by default in IDE is unsafe (must not do so on via >VPx, x < 3) (Vojtech Pavlik --- requires chipset tuning to be >enabled according to Andre Hedrick --- we need to turn this on by >default, if it is safe -- TYT) Using PCI DMA is also generally broken for modular IDE. Unloading/reloading the ide-probe-mod module still causes an oops when accessing disks (NULL pointer dereference / Aiee, killing the interrupt handler / Panic) and you are left with a dead system :( I observe it with alim15xx, but probably problem is more general and appears somewhere in IDE initialization by ide-probe-mod (IMHO). I observe similar (but not exactly the same) problem in 2.2.17+ide. I think that getting rid of the ide-probe-mod module (and linking it into ide-mod) should solve the problem. What do you think of it Andre ? Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
>10. To Do But Non Showstopper > > * Go through as 2.4pre kicks in and figure what we should mark > obsolete for the final 2.4 (i.e. XT hard disk support?) > * Union mount (Al Viro) ^^^ Anyone know the status of this? I have seen postings saying it's likely a 2.5 thingy, but it's continually on the 2.4 TODO lists. I am willing to help if it's needed/wanted. Thanks, Phil Philip Auld Dept. of Computer Science College of William and Mary - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000 [EMAIL PROTECTED] wrote: > * DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten >much commens yet) Can anyone tell me where to get this patch? I've got a DM9102A card in a SMP machine currently on which it can be tested. David Huen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12 2000, [EMAIL PROTECTED] wrote: > 8. Fix Exists But Isnt Merged > * TLAN nic appears to be adding a timer twice (2.4.0test8pre6, Arjan >ve de Ven) (Fixed, but patch not sent to Linus yet -- Torben >Mathiasen) > * Loading the qlogicfc driver in 2.4.0-test8 causes the kernel to >loop forver reporting SCSI disks that aren't present (Paul >Hubbard, Torben Mathiasen has a potential patch, sent to Linus, >need to very with Paul) These two have been merged. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12 2000, [EMAIL PROTECTED] wrote: 8. Fix Exists But Isnt Merged * TLAN nic appears to be adding a timer twice (2.4.0test8pre6, Arjan ve de Ven) (Fixed, but patch not sent to Linus yet -- Torben Mathiasen) * Loading the qlogicfc driver in 2.4.0-test8 causes the kernel to loop forver reporting SCSI disks that aren't present (Paul Hubbard, Torben Mathiasen has a potential patch, sent to Linus, need to very with Paul) These two have been merged. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000 [EMAIL PROTECTED] wrote: * DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten much commens yet) Can anyone tell me where to get this patch? I've got a DM9102A card in a SMP machine currently on which it can be tested. David Huen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
10. To Do But Non Showstopper * Go through as 2.4pre kicks in and figure what we should mark obsolete for the final 2.4 (i.e. XT hard disk support?) * Union mount (Al Viro) ^^^ Anyone know the status of this? I have seen postings saying it's likely a 2.5 thingy, but it's continually on the 2.4 TODO lists. I am willing to help if it's needed/wanted. Thanks, Phil Philip Auld Dept. of Computer Science College of William and Mary - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
"[EMAIL PROTECTED] wrote:" * Use PCI DMA by default in IDE is unsafe (must not do so on via VPx, x 3) (Vojtech Pavlik --- requires chipset tuning to be enabled according to Andre Hedrick --- we need to turn this on by default, if it is safe -- TYT) Using PCI DMA is also generally broken for modular IDE. Unloading/reloading the ide-probe-mod module still causes an oops when accessing disks (NULL pointer dereference / Aiee, killing the interrupt handler / Panic) and you are left with a dead system :( I observe it with alim15xx, but probably problem is more general and appears somewhere in IDE initialization by ide-probe-mod (IMHO). I observe similar (but not exactly the same) problem in 2.2.17+ide. I think that getting rid of the ide-probe-mod module (and linking it into ide-mod) should solve the problem. What do you think of it Andre ? Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
* USB: system hang with USB audio driver {CRITICAL} (David
Woodhouse, Randy Dunlap, Narayan Desai)
This is necessary but not sufficient:
Index: drivers/usb/audio.c
===
RCS file: /net/passion/inst/cvs/linux/drivers/usb/audio.c,v
retrieving revision 1.1.2.31
diff -u -r1.1.2.31 audio.c
--- drivers/usb/audio.c 2000/09/07 08:26:12 1.1.2.31
+++ drivers/usb/audio.c 2000/10/12 21:33:22
@@ -1007,8 +1007,10 @@
}
spin_lock_irqsave(as-lock, flags);
}
- if (u-dma.count = u-dma.dmasize !u-dma.mapped)
+ if (u-dma.count = u-dma.dmasize !u-dma.mapped) {
+ spin_unlock_irqrestore(as-lock, flags);
return 0;
+ }
u-flags |= FLG_RUNNING;
if (!(u-flags FLG_URB0RUNNING)) {
urb = u-durb[0].urb;
@@ -1368,8 +1370,10 @@
}
spin_lock_irqsave(as-lock, flags);
}
- if (u-dma.count = 0 !u-dma.mapped)
+ if (u-dma.count = 0 !u-dma.mapped) {
+ spin_unlock_irqrestore(as-lock, flags);
return 0;
+ }
u-flags |= FLG_RUNNING;
if (!(u-flags FLG_URB0RUNNING)) {
urb = u-durb[0].urb;
That fixes failure mode #1, in which the NMI watchdog gets triggered and
all subsequent attempts to open /dev/audio just block.
Unfortunately, it doesn't affect failure mode #2, in which the machine
just dies completely.
as-lock isn't locked when this happens - the last time
it was altered was at the end of usbout_start (line 1435).
wait_on_irq, CPU 0:
irq: 1 [ 0 1 ]
bh: 0 [ 1 0 ]
850f00e4 00a0 0fe0458b b70f00b7 0cec83c0 5c4ee850 c483fffd 85896610
e7a2 a2858b66 0fe7 6850c0b7 080e83c2 006a016a 00d373e8 10c48300
Call Trace: [ec83e045] [e0458b0c] [e850c0b7] [fffef850] [e8080e45]
[eb10c483] [f6892aeb]
[e7cc8589] [ffe7cc85] [e8006a02] [ffe79c85] [fd5b8fe8] [e79a858b]
[e798858b] [fb808ae4]
... LOTS of similarly unbelievable addresses ...
[e0858910] [fffbe0bd] [ff0cec83] [e900] [ff016a08] [fbe8858d]
[e850] [fffbe485]
c62e5000 0001 c62e5764 c016a6a2 c03087a0
c62e5364 c0170b72 c62e5000 c029f00c c011d597 0001 c02f559
Call Trace: [c0247f53] [c010be0d] [c0247f68] [c016a6a2] [c0170b72]
[c011d597] [c011d4ba]
[c010c1ea] [c010a8b4] [c0241150] [c013614d] [c0108d53]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; ec83e045 END_OF_CODE+21f5c2da/???
Trace; e0458b0c END_OF_CODE+15b76da1/???
Trace; e850c0b7 END_OF_CODE+1dc2a34c/???
... blah blah blah ...
Trace; e900 END_OF_CODE+1e71e295/???
Trace; ff016a08 END_OF_CODE+34734c9d/???
Trace; fbe8858d END_OF_CODE+315a6822/???
Trace; e850 END_OF_CODE+1dc2e294/???
Trace; fffbe485 END_OF_CODE+356dc71a/???
Trace; c0247f53 stext_lock+89ff/9110
Trace; c010be0d __global_cli+8d/12c
Trace; c0247f68 stext_lock+8a14/9110
Trace; c016a6a2 flush_to_ldisc+8e/110
Trace; c0170b72 console_softint+56/11c
Trace; c011d597 tasklet_action+4f/7c
Trace; c011d4ba do_softirq+5a/88
Trace; c010c1ea do_IRQ+da/ec
Trace; c010a8b4 ret_from_intr+0/20
Trace; c0241150 stext_lock+1bfc/9110
Trace; c013614d kupdate+10d/110
Trace; c0108d53 kernel_thread+23/30
The trace always include __global_cli(), obviously -
wait_on_irq() can't get called from anywhere else, AIUI. The rest of
the trace (except for the lines immediately above and below __global_cli
-- c0247f53 and c0247f68) is different each time.
The stack of the 'other' CPU each time is crap. Whether it's _really_ crap
or whether the code in show() is just doing something wrong I'm not sure.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Greg KH wrote:
On Thu, Oct 12, 2000 at 08:06:46AM -0400, [EMAIL PROTECTED]
wrote:
> * USB: booting with USB compiled into
kernel causes a lot of syslog
> entries as the root hubs
are probed by all drivers (this is
> especially obnoxious as
the usb-serial drivers start up)
Fixed in test9. If anyone still sees this, please let me know.
> * USB: fix setting urb->dev in printer,
acm, bluetooth, all serial
> drivers (Greg KH) {CRITICAL}
Fixed in test10-pre1.
> * USB: fix usb-uhci setting urb->dev
= NULL at correct places only
> {CRITICAL}
Fixed in test10-pre1.
thanks,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
USB still have problems, when starting to grab with my ov511 webcam i got
the attached oops. This bug appeared
in test9-preX(Xbeeing at least > 2) series. Some people have
claimed that test10-pre1 fixed the problem, but
the bug is still present in the last two pre(test10-pre1 and test10-pre2).
To be noted:
-this oops is obtained with "Enforce USB bandwidth allocation", but
it occurs in the same place when disabled
-I'm using usb-uhci
-the attached oops is truncated as each following schedule call produce
a new oops
--
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandire 0240726275 %
% 44470 Thouare, France [EMAIL PROTECTED] %
% ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
% -datamining -/ | .~. %
% -networking/flashed PHP3 coming soon | /V\ L I N U X %
% -opensource | // \\ >Fear the Penguin %
% -GNOME/enlightenment/GIMP | /( )\ %
% feel enlighted | ^^-^^ %
% http://ibonneace.dnsalias.org/ when connected %
%-%
ksymoops 2.3.4 on i686 2.4.0-test10. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test10/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference at virtual address 00a0
c8c7365d
*pde =
Oops:
CPU:1
EIP:0010:[c8c7365d]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00013246
eax: ebx: c6e26480 ecx: edx: 0028
esi: c6e26480 edi: c2bb8d9c ebp: esp: c0d05f28
ds: 0018 es: 0018 ss: 0018
Process X (pid: 974, stackpage=c0d05000)
Stack: c1b236a8 c8c84814 c6e26480 0001 c1b236a8 c2bb8d80 c2bb8d9c
0001 c8c849bf c2bb8d80 c6e26488 c2fc4b60 0401
0020 000a c0020020 c010be71 000a c2bb8d80 c0d05fc4 c0282740
Call Trace: [c8c84814] [c8c849bf] [c010be71] [c010c056] [c010a7c0]
Code: 8b 91 a0 00 00 00 8b 43 30 29 42 28 83 7c 24 10 00 74 10 8b
EIP; c8c7365d [usbcore]usb_release_bandwidth+9/60 =
Trace; c8c84814 [usb-uhci]process_urb+d4/1f0
Trace; c8c849bf [usb-uhci]uhci_interrupt+8f/e8
Trace; c010be71 handle_IRQ_event+4d/78
Trace; c010c056 do_IRQ+a6/f4
Trace; c010a7c0 ret_from_intr+0/20
Code; c8c7365d [usbcore]usb_release_bandwidth+9/60
_EIP:
Code; c8c7365d [usbcore]usb_release_bandwidth+9/60 =
0: 8b 91 a0 00 00 00 mov0xa0(%ecx),%edx =
Code; c8c73663 [usbcore]usb_release_bandwidth+f/60
6: 8b 43 30 mov0x30(%ebx),%eax
Code; c8c73666 [usbcore]usb_release_bandwidth+12/60
9: 29 42 28 sub%eax,0x28(%edx)
Code; c8c73669 [usbcore]usb_release_bandwidth+15/60
c: 83 7c 24 10 00cmpl $0x0,0x10(%esp,1)
Code; c8c7366e [usbcore]usb_release_bandwidth+1a/60
11: 74 10 je 23 _EIP+0x23 c8c73680
[usbcore]usb_release_bandwidth+2c/60
Code; c8c73670 [usbcore]usb_release_bandwidth+1c/60
13: 8b 00 mov(%eax),%eax
Aiee, killing interrupt handler
invalid operand:
CPU:1
EIP:0010:[c0116889]
EFLAGS: 00013282
eax: 001b ebx: ecx: 001b edx: c021a8e8
esi: c5bce9e0 edi: c0d04000 ebp: c0d05cec esp: c0d05cac
ds: 0018 es: 0018 ss: 0018
Process X (pid: 974, stackpage=c0d05000)
Stack: c01e6e45 c01e7016 02b8 c5bce9e0 c0d04000 3286 c5bce9e0
c0d04000 c5bcea28 c0185373 c12b9e60 0001 c0d04000
c5bcea28 c0131bd9 c13dc080 c13dfc00 c0d05d08 01234567
Call Trace: [c01e6e45] [c01e7016] [c0185373] [c0131bd9] [c0132bf9]
[c014eb64] [c014ed35]
[c014ee67] [c010a8b6] [c0150bbd] [c014fca8] [c0131901] [c0130892]
[c011b0cb] [c011b89c]
[c010abf2]
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
9. To Do
* mm-rss is modified in some places without holding the
page_table_lock (sct)
Any of the mm gurus give the patch below a quick once over ?
Is this adequate, or is there more to this than the description implies?
regards,
Dave.
--
| Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/mm/memory.c linux.dj/mm/memory.c
--- linux/mm/memory.c Sat Sep 16 00:51:21 2000
+++ linux.dj/mm/memory.cWed Oct 11 23:41:10 2000
@@ -370,7 +370,6 @@
address = (address + PGDIR_SIZE) PGDIR_MASK;
dir++;
} while (address (address end));
- spin_unlock(mm-page_table_lock);
/*
* Update rss for the mm_struct (not necessarily current-mm)
* Notice that rss is an unsigned long.
@@ -379,6 +378,7 @@
mm-rss -= freed;
else
mm-rss = 0;
+ spin_unlock(mm-page_table_lock);
}
@@ -1074,7 +1074,9 @@
flush_icache_page(vma, page);
}
+ spin_lock(mm-page_table_lock);
mm-rss++;
+ spin_unlock(mm-page_table_lock);
pte = mk_pte(page, vma-vm_page_prot);
@@ -1113,7 +1115,9 @@
return -1;
clear_user_highpage(page, addr);
entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma-vm_page_prot)));
+ spin_lock(mm-page_table_lock);
mm-rss++;
+ spin_unlock(mm-page_table_lock);
flush_page_to_ram(page);
}
set_pte(page_table, entry);
@@ -1152,7 +1156,9 @@
return 0;
if (new_page == NOPAGE_OOM)
return -1;
+ spin_lock(mm-page_table_lock);
++mm-rss;
+ spin_unlock(mm-page_table_lock);
/*
* This silly early PAGE_DIRTY setting removes a race
* due to the bad i386 page protection. But it's valid
diff -urN --exclude-from=/home/davej/.exclude linux/mm/mmap.c linux.dj/mm/mmap.c
--- linux/mm/mmap.c Tue Aug 29 20:41:12 2000
+++ linux.dj/mm/mmap.c Wed Oct 11 23:48:30 2000
@@ -844,7 +844,9 @@
vmlist_modify_lock(mm);
mm-mmap = mm-mmap_avl = mm-mmap_cache = NULL;
vmlist_modify_unlock(mm);
+ spin_lock (mm-page_table_lock);
mm-rss = 0;
+ spin_unlock (mm-page_table_lock);
mm-total_vm = 0;
mm-locked_vm = 0;
while (mpnt) {
diff -urN --exclude-from=/home/davej/.exclude linux/mm/vmscan.c linux.dj/mm/vmscan.c
--- linux/mm/vmscan.c Mon Oct 2 20:02:20 2000
+++ linux.dj/mm/vmscan.cWed Oct 11 23:46:01 2000
@@ -102,7 +102,9 @@
set_pte(page_table, swp_entry_to_pte(entry));
drop_pte:
UnlockPage(page);
+ spin_lock (mm-page_table_lock);
mm-rss--;
+ spin_unlock (mm-page_table_lock);
flush_tlb_page(vma, address);
deactivate_page(page);
page_cache_release(page);
@@ -170,7 +172,9 @@
struct file *file = vma-vm_file;
if (file) get_file(file);
pte_clear(page_table);
+ spin_lock (mm-page_table_lock);
mm-rss--;
+ spin_unlock (mm-page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
error = swapout(page, file);
@@ -202,7 +206,9 @@
add_to_swap_cache(page, entry);
/* Put the swap entry into the pte after the page is in swapcache */
+ spin_lock (mm-page_table_lock);
mm-rss--;
+ spin_unlock (mm-page_table_lock);
set_pte(page_table, swp_entry_to_pte(entry));
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
From: [EMAIL PROTECTED] Date:Fri, 13 Oct 2000 01:20:23 +0100 (BST) Any of the mm gurus give the patch below a quick once over ? Is this adequate, or is there more to this than the description implies? It might make more sense to just make rss an atomic_t. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Hello,
On Fri, Oct 13, 2000 at 01:20:23AM +0100, [EMAIL PROTECTED] wrote:
9. To Do
* mm-rss is modified in some places without holding the
page_table_lock (sct)
Any of the mm gurus give the patch below a quick once over ?
Is this adequate, or is there more to this than the description implies?
The patch is basically ok, except one point.
[snip]
diff -urN --exclude-from=/home/davej/.exclude linux/mm/vmscan.c linux.dj/mm/vmscan.c
--- linux/mm/vmscan.c Mon Oct 2 20:02:20 2000
+++ linux.dj/mm/vmscan.c Wed Oct 11 23:46:01 2000
@@ -102,7 +102,9 @@
set_pte(page_table, swp_entry_to_pte(entry));
drop_pte:
UnlockPage(page);
+ spin_lock (mm-page_table_lock);
mm-rss--;
+ spin_unlock (mm-page_table_lock);
flush_tlb_page(vma, address);
deactivate_page(page);
page_cache_release(page);
@@ -170,7 +172,9 @@
struct file *file = vma-vm_file;
if (file) get_file(file);
pte_clear(page_table);
+ spin_lock (mm-page_table_lock);
mm-rss--;
+ spin_unlock (mm-page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
error = swapout(page, file);
@@ -202,7 +206,9 @@
add_to_swap_cache(page, entry);
/* Put the swap entry into the pte after the page is in swapcache */
+ spin_lock (mm-page_table_lock);
mm-rss--;
+ spin_unlock (mm-page_table_lock);
set_pte(page_table, swp_entry_to_pte(entry));
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
In vmscan.c the question is not only about rss protection, but about real
protection for page table entries.
It may be something like
--- mm/vmscan.c.ptl Fri Oct 13 12:09:51 2000
+++ mm/vmscan.c Fri Oct 13 12:19:10 2000
@@ -150,6 +150,7 @@
if (file) get_file(file);
pte_clear(page_table);
vma-vm_mm-rss--;
+ spin_unlock(mm-page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(vma-vm_mm);
error = swapout(page, file);
@@ -182,6 +183,7 @@
/* Put the swap entry into the pte after the page is in swapcache */
vma-vm_mm-rss--;
set_pte(page_table, swp_entry_to_pte(entry));
+ spin_unlock(mm-page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(vma-vm_mm);
@@ -324,6 +326,7 @@
if (address vma-vm_start)
address = vma-vm_start;
+ spin_lock(mm-page_table_lock);
for (;;) {
int result = swap_out_vma(mm, vma, address, gfp_mask);
if (result)
@@ -333,6 +336,7 @@
break;
address = vma-vm_start;
}
+ spin_unlock(mm-page_table_lock);
}
vmlist_access_unlock(mm);
On Thu, Oct 12, 2000 at 05:29:39PM -0700, David S. Miller wrote:
From: [EMAIL PROTECTED]
Date: Fri, 13 Oct 2000 01:20:23 +0100 (BST)
Any of the mm gurus give the patch below a quick once over ? Is
this adequate, or is there more to this than the description
implies?
It might make more sense to just make rss an atomic_t.
In most cases where rss is updated page_table_lock is already held.
Best regards
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Date: Fri, 13 Oct 2000 12:34:30 +0800
From: Andrey Savochkin [EMAIL PROTECTED]
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
You've totally missed this and thus your suggested-patch/analysis
needs to be reevaluated :-)
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12, 2000 at 09:25:47PM -0700, David S. Miller wrote:
Date: Fri, 13 Oct 2000 12:34:30 +0800
From: Andrey Savochkin [EMAIL PROTECTED]
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
You've totally missed this and thus your suggested-patch/analysis
needs to be reevaluated :-)
Oops
You're of course right.
It looks as if somebody tried to separate this two locks and stopped in the
middle...
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000, David S. Miller wrote: Any of the mm gurus give the patch below a quick once over ? Is this adequate, or is there more to this than the description implies? It might make more sense to just make rss an atomic_t. Agreed. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000, David S. Miller wrote:
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
Yeah, it's an easy mistake to make.
I've made it myself - grepping for page_table_lock and coming up empty in
places where I expected it to be.
In fact, if somebody sends me patches to remove the "vmlist_access_lock()"
stuff completely, and replace them with explicit page_table_lock things,
I'll apply it pretty much immediately. I don't like information hiding,
and right now that's the only thing that the vmlist_access_lock() stuff is
doing.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
