Jose,
Was your concern addressed in today's chat?
Jose Fonseca wrote:
>
> 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
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
