lkml.org 
[lkml]   [2004]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kgdb support in vanilla 2.6.2
Date
On Friday 06 Feb 2004 5:46 pm, Andi Kleen wrote:
> On Fri, 6 Feb 2004 17:28:36 +0530
>
> "Amit S. Kale" <amitkale@emsyssoft.com> wrote:
> > On Friday 06 Feb 2004 7:50 am, Andi Kleen wrote:
> > > On Thu, 5 Feb 2004 23:20:04 +0530
> > >
> > > "Amit S. Kale" <amitkale@emsyssoft.com> wrote:
> > > > On Thursday 05 Feb 2004 8:41 am, Andi Kleen wrote:
> > > > > Andrew Morton <akpm@osdl.org> writes:
> > > > > > need to take a look at such things and really convice ourselves
> > > > > > that they're worthwhile. Personally, I'd only be interested in
> > > > > > the basic stub.
> > > > >
> > > > > What I found always extremly ugly in the i386 stub was that it uses
> > > > > magic globals to talk to the page fault handler. For the x86-64
> > > > > version I replaced that by just using __get/__put_user in the
> > > > > memory accesses, which is much cleaner. I would suggest doing that
> > > > > for i386 too.
> > > >
> > > > May be I am missing something obvious. When debugging a page fault
> > > > handler if kgdb accesses an swapped-out user page doesn't it deadlock
> > > > when trying to hold mm semaphore?
> > >
> > > Modern i386 kernels don't grab the mm semaphore when the access is >=
> > > TASK_SIZE and the access came from kernel space (actually I see x86-64
> > > still does, but that's a bug, will fix). You could only see a deadlock
> > > when using user addresses and you already hold the mm semaphore for
> > > writing (normal read lock is ok). Just don't do that.
> >
> > OK. It don't deadlock when kgdb accesses kernel addresses.
> >
> > When a user space address is accessed through kgdb, won't the kernel
> > attempt to fault in the user page? We don't want that to happen inside
> > kgdb.
>
> Yes, it will. But I don't think it's a bad thing. If the users doesn't want
> that they should not follow user addresses. After all kgdb is for people
> who know what they are doing.

Let kgdb refuse to access any addresses below TASK_SIZE. That's better than
accidentally typing something and getting lost.

I guess preventing user address accesses is lesser evil compared to using a
debugger global.

gdb itself may access user addresses in following scenarios. Not allowing user
accesses doesn't hurt as gdb can accept that and recover gracefully.

1. When a function parameter contains a char pointer.
GDB prints the string pointed to by a function parameter when printing frame
for the function.

2. If a kernel variable points to a user string, print command will show its
contents, unless user explicitely says print/x.

3. When a stack trace goes beyond an interrupt or an exception entrypoint:
The gdb at kgdb.sourceforge.net has some patchup for this problem, though it
doesn't work all the time. Sometimes we do endup seeing one invalid stack
frame for which gdb has accessed a user address.

-Amit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [from the cache]
©2003-2011 Jasper Spaans