search for: kvcalloc

...ull pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations. Fixes: 249881232e14 ("nouveau/dmem: evict device private memory during release") Suggested-by: Danilo Krummrich <dakr at redhat.com> Signed-off-by: Duoming Zhou <duoming at zju.edu.cn> --- Changes in v3: - Switch kcalloc() to kvcallo...

...appen. > > Moreover, the GPU is going away. If the kcalloc() fails, we could not > evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL > flag in kcalloc(). > > Finally, as there is no need to have physically contiguous memory, > this patch switches kcalloc() to kvcalloc() in order to avoid > failing allocations. > > Fixes: 249881232e14 ("nouveau/dmem: evict device private memory during release") > Suggested-by: Danilo Krummrich <dakr at redhat.com> > Signed-off-by: Duoming Zhou <duoming at zju.edu.cn> Applied to drm-misc-fixe...

...tp 05: 088113c6 0f220010 [ 4.312772] nouveau 0000:03:00.0: DRM: DCB conn 00: 00101064 [ 4.318520] nouveau 0000:03:00.0: DRM: DCB conn 01: 00202165 [ 4.329488] nouveau 0000:03:00.0: DRM: MM: using COPY for buffer copies [ 4.336261] stackdepot: allocating hash table of 1048576 entries via kvcalloc ... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette

This patch series is based on the VM introspection patches (https://lore.kernel.org/kvm/20200721210922.7646-1-alazar at bitdefender.com/), extending the introspection API with EPT Views and Virtualization Exceptions (#VE) support. The purpose of this series is to get an initial feedback and to see if we are on the right track, especially because the changes made to add the EPT views are not small

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others