>
> >
> > 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.
Oops. This code is called by kdbgetbytes to help validate the
address. Can't use kdbgetbytes itself. So we will have to live
with the possibility (quite slight) that the list is inconsistent
when kdbgetbytes calls this function.
scott
>
> 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
> >
>
|