>
> hi,
>
> Rather obvious bugfix. Against kdb v1.3.
Not at all obvious for the
following reasons:
1) When KDB is active, no other processor by definition is running,
thus locking is unnecessary.
2) What if you try to issue a command which uses this function
during a breakpoint where the vmlist_lock is already held in
write mode? KDB will hang, not a good thing.
KDB should never acquire a general kernel lock. There is the
risk that a list (such as vmlist) will be in an inconsistent
or even broken state, but kdb recovers fairly well when it
takes an internal fault. We should probably change this code
to not access 'vp' directly, but rather to use kdbgetbytes instead
for each element in the vmlist, just like the vm command does. This
will preclude faults from following busted pointers.
scott
>
> Regards,
> Tigran
>
> --- vmalloc.c.0 Thu Aug 17 20:12:20 2000
> +++ vmalloc.c Thu Aug 17 20:12:40 2000
> @@ -39,6 +39,7 @@
> {
> struct vm_struct *vp;
>
> + read_lock(&vmlist_lock);
> for(vp=vmlist; vp; vp = vp->next) {
> unsigned long end = (unsigned long)vp->addr + vp->size;
>
> @@ -47,9 +48,11 @@
> if ((starta >= (unsigned long)vp->addr)
> && (starta < end)
> && (enda < end)) {
> + read_unlock(&vmlist_lock);
> return 1;
> }
> }
> + read_unlock(&vmlist_lock);
> return 0;
> }
> #endif
>
|