Crash in 2.4.17/ptrace

Crash in 2.4.17/ptrace

Post by Daniel Jacobowit » Wed, 30 Jan 2002 05:40:19



I've been debugging frame buffer graphics lately, and encountering a
very annoying problem.  If the debugee has /dev/fb/0 mapped, and I try
to print out the contents of a pointer into that buffer, GDB crashes in
kernel/ptrace.c:access_process_vm.  The problem seems to be that
get_user_pages returns a NULL page.  Something as simple as this
prevents the crash:

--- 2.4.18-pre7/2.4.18-pre7/kernel/ptrace.c     Fri Dec 21 12:42:04 2001

                flush_cache_page(vma, addr);

+#if 1
+               if (!page)
+               {
+                       /* FIXME: Writes? */
+                       if (!write) memset (buf, 0, bytes);
+                       len -= bytes;
+                       buf += bytes;
+                       continue;
+               }
+#endif
+
+
                maddr = kmap(page);
                if (write) {
                        memcpy(maddr + offset, buf, bytes);

Of course, I would much rather be able to see the contents of the
framebuffer.  Any suggestions?

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Crash in 2.4.17/ptrace

Post by Andrew Morto » Wed, 30 Jan 2002 06:40:19



> Frame buffers aren't reliable marked VM_IO when mapped, currently.  Ben
> H. said he was going to push a fix for this at least to the PPC trees
> today or tomorrow.

They are now, I hope.  I fixed that in 2.4.18-pre2.
 drivers/video/fbmem.c:fb_mmap() marks the vma as
VM_IO for all architectures.  But perhaps I missed some;
an audit is needed in there, which I'll do.

Quote:> It's cute - fbmem.c goes out of its way to set the flag on some
> architectures and not others.  I can't imagine why.

> But with that, yes, that should fix it.

> > > Of course, I would much rather be able to see the contents of the
> > > framebuffer.  Any suggestions?

> > Not with this patch, I'm afraid.  For your testing purposes you
> > could just remove the VALID_PAGE() test in mm/memory.c:get_page_map(),
> > and then gdb should be able to get at the framebuffer.

> I'm sure there's a good reason to not do that in general.  Mind
> enlightening me?

Well, get_user_pages is used by several parts of the kernel.
In the O_DIRECT/map_user_kiobuf case, we could end up asking
the disk controller to perform busmastering against the video
PCI device, which will probably explode somewhere down the chain.

Also, just because the hardware is mapped into the process
virtual address space, it's not necessarily all accessible.
It is possible to get a bus fault against part of the mapping.
And the kernel doesn't expect to get bus faults on the source
of copy_to_user, I think.

I'm sure Andrea will have a better notion than I.  Sometimes I
just fling out random patches to get people thinking about
things ;)

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Crash in 2.4.17/ptrace

Post by Manfred Sprau » Wed, 30 Jan 2002 06:50:11


Quote:

> > Not with this patch, I'm afraid.  For your testing purposes you
> > could just remove the VALID_PAGE() test in

mm/memory.c:get_page_map(),

Quote:> > and then gdb should be able to get at the framebuffer.

> I'm sure there's a good reason to not do that in general.  Mind
> enlightening me?

Please don't do it at all.
The test is there to ensure that there is a 'struct page' for address
found in the pages tables.
For framebuffers addresses, there is no page structure, and then the
page reference count updates read/write to random memory.

--
    Manfred

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Crash in 2.4.17/ptrace

Post by Alan Co » Wed, 30 Jan 2002 06:50:15


Quote:> In the O_DIRECT/map_user_kiobuf case, we could end up asking
> the disk controller to perform busmastering against the video
> PCI device, which will probably explode somewhere down the chain.

Actually we already know if this will fail or not. Check the pci quirks file
We set a bunch of flags for safety issues on pci<->pci transfers. I did that
anticipating one day more than just a few capture cards would care

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Crash in 2.4.17/ptrace

Post by Alan Co » Wed, 30 Jan 2002 07:00:15


Quote:> For framebuffers addresses, there is no page structure, and then the
> page reference count updates read/write to random memory.

If it is a physical pci bus object why do we need to refcount it, surely
"no page" is ok. Its just up to the driver not to do anything stupid and
the core code to honour the pci/pci transfer quirks (or when faced with
a *e just say "no")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/
 
 
 

Crash in 2.4.17/ptrace

Post by Benjamin Herrenschmid » Wed, 30 Jan 2002 07:20:12


Quote:>Well, get_user_pages is used by several parts of the kernel.
>In the O_DIRECT/map_user_kiobuf case, we could end up asking
>the disk controller to perform busmastering against the video
>PCI device, which will probably explode somewhere down the chain.

Well... not sure. I'd like this to be doable. I have worked
on some high-end broadcast video stuffs in the past, and we
did intensive use of direct bus master from the disk controller
to the framebuffer linear aperture. Actually, we even controlled
the scatter gather list to "sort" lines ;)

If the HW cause a fault, the disk controller should stop and
report an error, and the process should be signaled instead
of getting an oops, but I don't know these code path in linux
at all so...

Quote:>Also, just because the hardware is mapped into the process
>virtual address space, it's not necessarily all accessible.
>It is possible to get a bus fault against part of the mapping.
>And the kernel doesn't expect to get bus faults on the source
>of copy_to_user, I think.

Well. My point of view here is fix copy_to_user, but well...

Quote:>I'm sure Andrea will have a better notion than I.  Sometimes I
>just fling out random patches to get people thinking about
>things ;)

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Crash in 2.4.17/ptrace

Post by Daniel Jacobowit » Wed, 30 Jan 2002 07:30:25



> > For framebuffers addresses, there is no page structure, and then the
> > page reference count updates read/write to random memory.

> If it is a physical pci bus object why do we need to refcount it, surely
> "no page" is ok. Its just up to the driver not to do anything stupid and
> the core code to honour the pci/pci transfer quirks (or when faced with
> a *e just say "no")

So, is there a clear interface by which access_process_vm ought to be
able to get at the mapped framebuffer, or should get_user_pages just
punt off it?

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Crash in 2.4.17/ptrace

Post by Andrea Arcangel » Wed, 30 Jan 2002 08:50:17




> > Oh nice.  And it seems that, say, an O_DIRECT write of, say,
> > a mmaped framebuffer will also oops the kernel.

> > Most callers of get_user_pages() aren't prepared for a
> > null page* in the returned array.

> > This patch *may* be sufficient, but perhaps get_user_pages()
> > should just bale out as soon as it finds an invalid page, rather
> > than sticking a null page * into the returned array and continuing.

> > --- linux-2.4.18-pre7/mm/memory.c     Fri Dec 21 11:19:23 2001
> > +++ linux-akpm/mm/memory.c    Mon Jan 28 12:54:40 2002

> >               vma = find_extend_vma(mm, start);

> >               if ( !vma ||
> > +                  (vma->vm_flags & VM_IO) ||
> >                   (!force &&
> >                       ((write && (!(vma->vm_flags & VM_WRITE))) ||
> >                        (!write && (!(vma->vm_flags & VM_READ))) ) )) {

> Frame buffers aren't reliable marked VM_IO when mapped, currently.  Ben

For this reason (and also because there aren't only framebuffers mmapped
out there) I guess it's better to just add (yet another) flag to
get_user_pages, so that it fails with an error when it encounters a
page out of the mem_map array.

- Show quoted text -

Quote:> H. said he was going to push a fix for this at least to the PPC trees
> today or tomorrow.

> It's cute - fbmem.c goes out of its way to set the flag on some
> architectures and not others.  I can't imagine why.

> But with that, yes, that should fix it.

> > > Of course, I would much rather be able to see the contents of the
> > > framebuffer.  Any suggestions?

> > Not with this patch, I'm afraid.  For your testing purposes you
> > could just remove the VALID_PAGE() test in mm/memory.c:get_page_map(),
> > and then gdb should be able to get at the framebuffer.

> I'm sure there's a good reason to not do that in general.  Mind
> enlightening me?

> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Crash in 2.4.17/ptrace

Post by Andrea Arcangel » Wed, 30 Jan 2002 09:00:17



> >Well, get_user_pages is used by several parts of the kernel.
> >In the O_DIRECT/map_user_kiobuf case, we could end up asking
> >the disk controller to perform busmastering against the video
> >PCI device, which will probably explode somewhere down the chain.

> Well... not sure. I'd like this to be doable. I have worked
> on some high-end broadcast video stuffs in the past, and we
> did intensive use of direct bus master from the disk controller
> to the framebuffer linear aperture. Actually, we even controlled

you can do direct DMA to framebuffer on most sane hardware, yes.  But
the kiobuf structure on 2.4 doesn't allow that, it only works with valid
'page structures' not physical addresses. This is valid for both rawio
and O_DIRECT. The MM part is the same for both of course.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Crash in 2.4.17/ptrace

Post by Andrew Morto » Wed, 30 Jan 2002 14:50:10



> ...
> Well, I think your earlier suggestion to bale out with an error if an
> invalid page is found sounds like the cleaner fix (possibly in function
> of yet another bitflag, so if somebody wants to get the nearby pages
> regardless of an invalid pages somewhere, it can).

I find it rather hard to decide about this.  get_user_pages()
leaves null page pointers in the page[] array for invalid
pages, and that's a reasonable API, as long as all callers
are actually aware of it....

In the O_DIRECT case, the kernel does not crash, because
brw_kiovec() does:

                        map  = iobuf->maplist[pageind];
                        if (!map) {
                                err = -EFAULT;
                                goto finished;
                        }

However, I think it _would_ crash if the first entry in the maplist[]
was non-null, and the second is null, because that would cause
generic_file_direct_IO() to call mark_dirty_kiobuf(), and
mark_dirty_kiobuf() forgets to check for NULL page *'s in the maplist[].

Given the difficulty of testing all this, and the dubious benefit
in allowing a holey maplist[], I'm inclined to just disallow it
in 2.4.   What do you think?

--- linux-2.4.18-pre7/mm/memory.c       Fri Dec 21 11:19:23 2001

                vma = find_extend_vma(mm, start);

                if ( !vma ||
+                    (vma->vm_flags & VM_IO) ||
                    (!force &&
                        ((write && (!(vma->vm_flags & VM_WRITE))) ||

                                /* FIXME: call the correct function,
                                 * depending on the type of the found page
                                 */
-                               if (pages[i])
-                                       page_cache_get(pages[i]);
+                               if (!pages[i])
+                                       goto bad_page;
+                               page_cache_get(pages[i]);
                        }
                        if (vmas)

                } while(len && start < vma->vm_end);
                spin_unlock(&mm->page_table_lock);
        } while(len);
+out:
        return i;
+
+       /*
+        * We found an invalid page in the VMA.  Release all we have
+        * so far and fail.
+        */
+bad_page:
+       spin_unlock(&mm->page_table_lock);
+       while (i--)
+               page_cache_release(pages[i]);
+       i = -EFAULT;
+       goto out;
 }

 /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. [PATCH?] Crash in 2.4.17/ptrace

Good this is needed.

You missed the atyfb driver. Other then that it looks fine. Geert what do
you think?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. remote x terminal session

3. some 2.4.17 vs. 2.4.17-rmap8 vs. lowmem analysis

4. ppp dialup works only under root

5. Oops/Crash with 2.4.17 and 2.4.18 kernels

6. Telnetable Linux BBS

7. Geode crashed 2.4.17, runs under 2.4.19

8. donbp error message?

9. kernel crashes with 2.4.17

10. kernel 2.4.17 crashes on SCSI-errors

11. Kernel 2.4.17 with VT8367 [KT266] crashes on heavy ide load togeter

12. 2.4.17 agpgart process hang on crash

13. In 2.4.17 __free_pages_ok