linux-kernel - Re: [PATCH v4 5/9] drm/ttm, drm/vmwgfx: Support huge TTM pagefaults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <39b3614c5bc472981bd12419492af9f7764bf980.camel@vmware.com>
Date:   Sun, 1 Mar 2020 14:03:44 +0000
From:   Thomas Hellstrom <thellstrom@...are.com>
To:     "hdanton@...a.com" <hdanton@...a.com>,
        "thomas_os@...pmail.org" <thomas_os@...pmail.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "willy@...radead.org" <willy@...radead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "christian.koenig@....com" <christian.koenig@....com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        Pv-drivers <Pv-drivers@...are.com>,
        "rcampbell@...dia.com" <rcampbell@...dia.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "jglisse@...hat.com" <jglisse@...hat.com>,
        Linux-graphics-maintainer <Linux-graphics-maintainer@...are.com>,
        Roland Scheidegger <sroland@...are.com>
Subject: Re: [PATCH v4 5/9] drm/ttm, drm/vmwgfx: Support huge TTM pagefaults

On Sun, 2020-03-01 at 21:49 +0800, Hillf Danton wrote:
> On Thu, 20 Feb 2020 13:27:15 +0100 Thomas Hellstrom wrote:
> > +
> > +static vm_fault_t ttm_bo_vm_huge_fault(struct vm_fault *vmf,
> > +				       enum page_entry_size pe_size)
> > +{
> > +	struct vm_area_struct *vma = vmf->vma;
> > +	pgprot_t prot;
> > +	struct ttm_buffer_object *bo = vma->vm_private_data;
> > +	vm_fault_t ret;
> > +	pgoff_t fault_page_size = 0;
> > +	bool write = vmf->flags & FAULT_FLAG_WRITE;
> > +
> > +	switch (pe_size) {
> > +	case PE_SIZE_PMD:
> > +		fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
> > +		break;
> > +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> > +	case PE_SIZE_PUD:
> > +		fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
> > +		break;
> > +#endif
> > +	default:
> > +		WARN_ON_ONCE(1);
> > +		return VM_FAULT_FALLBACK;
> > +	}
> > +
> > +	/* Fallback on write dirty-tracking or COW */
> > +	if (write && ttm_pgprot_is_wrprotecting(vma->vm_page_prot))
> > +		return VM_FAULT_FALLBACK;
> > +
> > +	ret = ttm_bo_vm_reserve(bo, vmf);
> > +	if (ret)
> > +		return ret;
> > +
> > +	prot = vm_get_page_prot(vma->vm_flags);
> > +	ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
> > +	if (ret == VM_FAULT_RETRY && !(vmf->flags &
> > FAULT_FLAG_RETRY_NOWAIT))
> > +		return ret;
> 
> Seems it does not make much sense to check VM_FAULT_RETRY and return
> as
> at least resv lock is left behind without care.

With this particular flag combination, both the mm_sem and the dma_resv
lock have already been released by TTM.

It's a special case allowing for drivers to release the mmap_sem when
waiting for IO.

That should probably be documented better in TTM.

/Thomas