search for: sgdma

Currently, we take down the sgdma engine without evicting all buffers from VRAM. The TTM device release will try to evict anything in VRAM to GART memory, but this will fail since sgdma has already been taken down. This causes an infinite loop in kernel mode on module unload. It usually doesn't happen because there aren't...

When ttm_dma_tt_init() fails in nouveau_sgdma_create_ttm(), we should free the previously allocated memory before returning NULL. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau_sgdma.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drm/nouveau_sgdma.c b/drm/nouveau_sgdma.c index 01707...

nouveau_sgdma_be::dev is only set once during init and never used anywhere, so remove it. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau_sgdma.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drm/nouveau_sgdma.c b/drm/nouveau_sgdma.c index 01707e7deaf5..ec76c0b4e452 10064...

...instead adds a comment which explains why this kfree isn't needed :) [I'm leaving the reason to the reader, which will force you to glance at the ttm code.] On Wed, Dec 10, 2014 at 1:37 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > When ttm_dma_tt_init() fails in nouveau_sgdma_create_ttm(), we should > free the previously allocated memory before returning NULL. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drm/nouveau_sgdma.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drm/nouveau_sgd...

Common programming sense dictates that resources allocated by a function are freed by this function should it fails, but this is not the case for the allocated structure of nouveau_sgdma_create_ttm(). It seems that n00b contributors attempt to fix this one like bugs flying towards a bug zapper, so add a comment to hopefully prevent this from happening anymore. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau_sgdma.c | 5 +++++ 1 file changed, 5 inse...

...rote: > We get this patch every few months... How about one that instead adds > a comment which explains why this kfree isn't needed :) [I'm leaving > the reason to the reader, which will force you to glance at the ttm > code.] ttm_dma_tt_init -> ttm_tt_destroy -> nouveau_sgdma_destroy -> kfree Urrk. I'm definitely not a fan of things happening this way, but let it be. Indeed a comment would be nice to have here, let me prep a patch for this instead...