I have been looking into the DRM's DMA/CCE/CP initialization subroutines
(those named *_do_init{dma,cce,cp} ) of the current DRI drivers, and I
still don't know how they protect themselves from making faults due to
bad initialization parameters. Since I this is a little complicated to
put over IRC I'm sending this email to prepare you for tonight...


The first question is why the dev->dev_private initializition is delayed
until the last moment of exiting these subroutines. Taking the Radeon
code as example, why is radeon_do_init_cp (radeon_cp.c:668) full of
statements like

                dev->dev_private = (void *)dev_priv;

instead of a single on right after dev_priv allocation (as done before)?
Is this subroutine reentrant? Even if it is, how does this solve the
problem?


The other thing is in r128_do_cleanup_cce. This subroutine is called by
r128_do_init_cce in case of failure as in 

        DRM_FIND_MAP( dev_priv->buffers, init->buffers_offset );
        if(!dev_priv->buffers) {
                DRM_ERROR("could not find dma buffer region!\n");
                dev->dev_private = (void *)dev_priv;
                r128_do_cleanup_cce( dev );
                return -EINVAL;
        }

but if indeed dev_priv->buffers is NULL, won't the following code in
128_do_cleanup_cce generate a segfault?

                if ( !dev_priv->is_pci ) {
                        DRM_IOREMAPFREE( dev_priv->cce_ring );
                        DRM_IOREMAPFREE( dev_priv->ring_rptr );
                        DRM_IOREMAPFREE( dev_priv->buffers );
                } else {

since as said in a previous email of mine DRM_IOREMAPFREE doesn't check
if its argument is NULL, on the contrary it references it before passing
it to ioremapfree:

#define DRM_IOREMAPFREE(map)                                           \
        do {                                                           \
                if ( (map)->handle && (map)->size )                    \
                        DRM(ioremapfree)( (map)->handle, (map)->size );\
        } while (0)

So isn't there a bug here as well or I'm missing something?


Just in case you may be thinking that this can be fairly uncommon this
situation occurs when the init structure changes. So everytime there is
a versioning problem in the DRM, libdrm.a or DDX which involves a change
on the init structure this will most likely to occur and, at least on my
systems, it locks mach64.o on the kernel, and only a reset can allow
normal operation again.

Jose Fonseca


_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to