similar to: [PATCH] drm/nouveau: Use vmemdup_user()

From: Markus Elfring <elfring at users.sourceforge.net> Date: Tue, 11 Aug 2020 19:25:22 +0200 Reuse existing functionality from vmemdup_user() instead of keeping duplicate source code. Generated by: scripts/coccinelle/api/memdup_user.cocci Signed-off-by: Markus Elfring <elfring at users.sourceforge.net> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 12 +++--------- 1 file changed, 3

I was getting a order 4 allocation failure from kmalloc when testing some game after a few days uptime with some suspend/resumes. For big allocations vmalloc should be used instead. Also limit size more aggressively to 256 KiB. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++++++++++++++++++++++------- 1 file

On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > I was getting a order 4 allocation failure from kmalloc when testing some game > after a few days uptime with some suspend/resumes. For big allocations vmalloc > should be used instead. I've picked up this patch with a minor modification (see below) > > Also limit size more

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

On Wed, Aug 21, 2019 at 11:50:29PM +0200, Daniel Vetter wrote: > We can't copy_*_user while holding reservations, that will (soon even > for nouveau) lead to deadlocks. And it breaks the cross-driver > contract around dma_resv. > > Fix this by adding a slowpath for when we need relocations, and by > pushing the writeback of the new presumed offsets to the very end. >

On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote: > We can't copy_*_user while holding reservations, that will (soon even > for nouveau) lead to deadlocks. And it breaks the cross-driver > contract around dma_resv. > > Fix this by adding a slowpath for when we need relocations, and by > pushing the writeback of the new presumed offsets to the very end. >

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

Date: Wed, 5 Apr 2023 18:38:54 +0200 The label ?out_prevalid? was used to jump to another pointer check despite of the detail in the implementation of the function ?nouveau_gem_ioctl_pushbuf? that it was determined already in one case that the corresponding variable contained an error pointer because of a failed call of the function ?u_memcpya?. Thus use an additional label. This issue was

Hi Markus, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master drm/drm-next drm-exynos/exynos-drm-next v5.8 next-20200812] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use

Using the libcurl share interface we can share data between the separate curl easy handles in the pool. For more about this see: https://curl.se/libcurl/c/CURLSHOPT_SHARE.html https://gist.github.com/bagder/7eccf74f8b6d70b5abefeb7f288dba9b https://everything.curl.dev/libcurl/sharing --- plugins/curl/curldefs.h | 3 +- plugins/curl/curl.c | 4 ++- plugins/curl/pool.c | 75

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

On 2/22/23 16:01, Richard W.M. Jones wrote: > Using the libcurl share interface we can share data between the > separate curl easy handles in the pool. For more about this see: > > https://curl.se/libcurl/c/CURLSHOPT_SHARE.html > https://gist.github.com/bagder/7eccf74f8b6d70b5abefeb7f288dba9b > https://everything.curl.dev/libcurl/sharing > --- > plugins/curl/curldefs.h |

Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included a logic-bug which results in the relocations not actually getting applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is never reached. This causes a regression with graphical corruption, triggered when relocations need to be done (for example after a suspend/resume cycle.) Fix by setting *apply_relocs

Hello list, I've been having a tough time adding windows resource support to my ogg vorbise decoder, although I think I am close. Basically when I call ov_open_callbacks(), it doesn't ever return and repeatedly calls my seek_func. I'm hoping it is something obvious, but I can't see why my seek_func is being called endlessly. If the file is seekable, I should return 0, right? If

On 2014-02-02, at 12:00 PM, vorbis-request at xiph.org wrote: > Send Vorbis mailing list submissions to > vorbis at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/vorbis > or, via email, send a message with subject or body 'help' to > vorbis-request at xiph.org > > You can reach the person

Commit-ID: 8c056cab6c8cce0b5dbc2c3141060f89a6ffc905 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=8c056cab6c8cce0b5dbc2c3141060f89a6ffc905 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 25 Jul 2020 21:18:30 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 25 Jul 2020 21:44:14 +0100 [klibc] stdio: Define all the

This addresses the following gcc warning with "make W=1": drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ?nv50_mstm_prepare?: drivers/gpu/drm/nouveau/dispnv50/disp.c:1378:6: warning: variable ?ret? set but not used [-Wunused-but-set-variable] Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +++ 1 file changed, 3

fixed the following warnings drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 -- 1 file changed, 2 deletions(-)