similar to: [PATCH] drm/nouveau/mmu: fix use-after-free bug in nvkm_vmm_pfn_map

Actually - could you resend this with dri-devel at lists.freedesktop.org added to the cc list just to make patchwork happy? On Sat, 2022-10-29 at 15:46 +0800, Zheng Wang wrote: > If it failed in kzalloc, vma will be freed in nvkm_vmm_node_merge. > The later use of vma will casue use after free. > > Reported-by: Zheng Wang <hackerzheng666 at gmail.com> > Reported-by: Zhuorao

Reviewed-by: Lyude Paul <lyude at redhat.com> Will push upstream in a moment On Sat, 2022-10-29 at 15:46 +0800, Zheng Wang wrote: > If it failed in kzalloc, vma will be freed in nvkm_vmm_node_merge. > The later use of vma will casue use after free. > > Reported-by: Zheng Wang <hackerzheng666 at gmail.com> > Reported-by: Zhuorao Yang <alex000young at gmail.com>

On Tue, Apr 21, 2020 at 09:21:46PM -0300, Jason Gunthorpe wrote: > +void nouveau_hmm_convert_pfn(struct nouveau_drm *drm, struct hmm_range *range, > + u64 *ioctl_addr) > { > unsigned long i, npages; > > + /* > + * The ioctl_addr prepared here is passed through nvif_object_ioctl() > + * to an eventual DMA map on some call chain like: > + *

The goal for this series is to introduce the hmm_pfn_to_map_order() function. This allows a device driver to know that a given 4K PFN is actually mapped by the CPU using a larger sized CPU page table entry and therefore the device driver can safely map system memory using larger device MMU PTEs. The series is based on 5.8.0-rc3 and is intended for Jason Gunthorpe's hmm tree. These were

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

In an effort to separate intentional arithmetic wrap-around from unexpected wrap-around, we need to refactor places that depend on this kind of math. One of the most common code patterns of this is: VAR + value < VAR Notably, this is considered "undefined behavior" for signed and pointer types, which the kernel works around by using the -fno-strict-overflow option in the build[1]

On Wed, Apr 22, 2020 at 08:03:29AM +0200, Christoph Hellwig wrote: > > > On Tue, Apr 21, 2020 at 09:21:46PM -0300, Jason Gunthorpe wrote: > > +void nouveau_hmm_convert_pfn(struct nouveau_drm *drm, struct hmm_range *range, > > + u64 *ioctl_addr) > > { > > unsigned long i, npages; > > > > + /* > > + * The ioctl_addr prepared here is

The goal for this series is to introduce the hmm_range_fault() output array flags HMM_PFN_PMD and HMM_PFN_PUD. This allows a device driver to know that a given 4K PFN is actually mapped by the CPU using either a PMD sized or PUD sized CPU page table entry and therefore the device driver can safely map system memory using larger device MMU PTEs. The series is based on 5.8.0-rc3 and is intended for

On 5/1/20 11:20 AM, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Presumably the intent here was that hmm_range_fault() could put the data > into some HW specific format and thus avoid some work. However, nothing > actually does that, and it isn't clear how anything actually could do that > as hmm_range_fault() provides CPU addresses which

The nvif_object_ioctl() method NVIF_VMM_V0_PFNMAP wasn't correctly setting the hardware specific GPU page table entries for 2MB sized pages. Fix this by adding functions to set and clear PD0 GPU page table entries. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 5 +- .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 82

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

Nouveau currently only supports mapping PAGE_SIZE sized pages of system memory when shared virtual memory (SVM) is enabled. Use the new HMM_PFN_COMPOUND flag that hmm_range_fault() returns to support mapping system memory pages larger than PAGE_SIZE. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_svm.c | 47 ++++++++++++++-----

hmm_range_fault() returns an array of page frame numbers and flags for how the pages are mapped in the requested process' page tables. The PFN can be used to get the struct page with hmm_pfn_to_page() and the page size order can be determined with compound_order(page) but if the page is larger than order 0 (PAGE_SIZE), there is no indication that the page is mapped using a larger page size. To

In ocfs2_block_group_clear_bits, when num_bits != bits_cleared, it just log an error message without setting EROFS. The code is below: /* * If encountered, it means we are clearing bits multiple times. While * we are handling the case, we still need to be alerted to its * occurrence. Hence, marking it as an ERROR and not NOTICE. */ if (num_bits != bits_cleared) { mlog(ML_ERROR,

Note: stub out endian-ness conversion for now. We'll add a flag to control it for BE guests later. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- This will be needed once __virtio16 typedefs come in. drivers/net/tun.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index

Note: stub out endian-ness conversion for now. We'll add a flag to control it for BE guests later. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- This will be needed once __virtio16 typedefs come in. drivers/net/tun.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index

Topic: strace casues hardlock. no kernel panic. userland tool Category: kernel Program: strace Affects: FreeBSD releases 5.x and later. problem: When a normal user (or root user) users strace on certain binarys, the system will hardlock up, with no kernel panic. (numlock doesnt turn on and off, no ssh or console access). Im using strace from the ports

Hi. I have a CentOS 6.2 virtual machine in a vmware ESXi 4.0 host 4G Ram 4 virtaul cpus and with about 4 TB of disk space formatted with XFS . I'm seeing a lot of : Mar 21 10:49:42 nzhmlfpr05 kernel: XFS (dm-4): xlog_space_left: head behind tail Mar 21 10:49:42 nzhmlfpr05 kernel: tail_cycle = 129, tail_bytes = 20163072 Mar 21 10:49:42 nzhmlfpr05 kernel: GH cycle = 129, GH bytes =

Hi All, After configuring and compiling OpenSSH version 4.6p1 in my SUN Solaris8 ultrasparc machine, I run "make tests" and got the following errors. The compiler used is GCC3.3. run test sftp.sh ... test basic sftp put/get: buffer_size 5 num_requests 1 sftp failed with 1 test basic sftp put/get: buffer_size 5 num_requests 2 sftp failed with 1 test basic sftp put/get: buffer_size 5

On trying to run a rake task via crontab, I''m getting the following error: rake aborted! 550 Cannot receive from specified address <help-+zpghU0kKgY@public.gmane.org>: Unauthenticated senders not allowed /mnt/voylla-production/shared/bundle/ruby/1.9.1/gems/mail-2.3.3/lib/mail/network/delivery_methods/smtp.rb:129:in `block in deliver!''