Re: [PATCH v4 11/23] device-dax: Kill dax_kmem_res

> Am 24.09.2020 um 23:26 schrieb Dan Williams : > > [..] >>> I'm not suggesting to busy the whole "virtio" range, just the portion >>> that's about to be passed to add_memory_driver_managed(). >> >> I'm afraid I don't get your point. For virtio-mem: >> >> Before: >> >> 1. Create virtio0 cont

Re: [PATCH v4 11/23] device-dax: Kill dax_kmem_res

On Thu, Sep 24, 2020 at 2:42 PM David Hildenbrand wrote: > > > > > Am 24.09.2020 um 23:26 schrieb Dan Williams : > > > > [..] > >>> I'm not suggesting to busy the whole "virtio" range, just the portion > >>> that's about to be passed to add_memory_driver_managed(). > >> > >> I'm afraid I don't ge

Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.

On Thu, 24 Sep 2020 at 22:42, Christian König wrote: > > Am 24.09.20 um 07:18 schrieb Dave Airlie: > > From: Dave Airlie > > > > All the accel moves do the same pattern here, provide a helper > > And exactly that pattern I want to get away from. Currently this is just refactoring out the helper

Re: [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv

On 9/24/20 9:58 AM, Christoph Hellwig wrote: > Replacing alloc_vm_area with get_vm_area_caller + apply_page_range > allows to fill put the phys_addr values directly instead of doing > another loop over all addresses. > > Signed-off-by: Christoph Hellwig Reviewed-by: Boris Ostrovsky -boris

Re: [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc

On 9/24/20 9:58 AM, Christoph Hellwig wrote: > Replace the last call to alloc_vm_area with an open coded version using > an iterator in struct gnttab_vm_area instead of the triple indirection > magic in alloc_vm_area. > > Signed-off-by: Christoph Hellwig Reviewed-by: Boris Ostrovsky ___

[gabbayo:habanalabs-next 4/5] WARNING: modpost: vmlinux.o(.text+0x1db5e10): Section mismatch in reference from the function tfrc_calc_x() to the variable .init.text:.L0

tree: git://people.freedesktop.org/~gabbayo/linux habanalabs-next head: bbfc1bab1edc92023b1e144c1dceb341b31dc834 commit: 6ba70b882d6343bc2c86a6d09fbcad2c8170b6a6 [4/5] habanalabs: add notice of device not idle config: riscv-randconfig-r031-20200923 (attached as .config) compiler: riscv32-linux

[git pull] drm fixes for 5.9-rc7

Hi Linus, Due to the dax merge fail in rc6, this has two backmerges, Intel pulled in a later point in time to fix their CI systems, I also pulled in an earlier point to fix my local builds. Otherwise fairly quiet, a couple of i915 fixes, one dma-buf fix, one vc4 and two sun4i changes. I realised

Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers

On 24. 09. 20, 15:38, Peilin Ye wrote: > Hi all, > > syzbot has reported [1] a global out-of-bounds read issue in > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large > value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in > font data buffers, declared in li

<    1   2