All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	David Airlie <airlied@linux.ie>, Huang Rui <ray.huang@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Trigger Huang <Trigger.Huang@gmail.com>,
	Gert Wollny <gert.wollny@collabora.com>,
	Antonio Caggiano <antonio.caggiano@collabora.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Dmitry Osipenko <digetx@gmail.com>,
	kvm@vger.kernel.org, kernel@collabora.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
Date: Mon, 15 Aug 2022 12:42:22 +0200	[thread overview]
Message-ID: <2e64c037-ee5a-0c60-5dba-2e48bb437014@amd.com> (raw)
In-Reply-To: <14be3b22-1d60-732b-c695-ddacc6b21055@collabora.com>

Am 15.08.22 um 12:18 schrieb Dmitry Osipenko:
> On 8/15/22 13:14, Christian König wrote:
>> Am 15.08.22 um 12:11 schrieb Christian König:
>>> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko:
>>>> On 8/15/22 13:05, Christian König wrote:
>>>>> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
>>>>>> Higher order pages allocated using alloc_pages() aren't refcounted and
>>>>>> they
>>>>>> need to be refcounted, otherwise it's impossible to map them by
>>>>>> KVM. This
>>>>>> patch sets the refcount of the tail pages and fixes the KVM memory
>>>>>> mapping
>>>>>> faults.
>>>>>>
>>>>>> Without this change guest virgl driver can't map host buffers into
>>>>>> guest
>>>>>> and can't provide OpenGL 4.5 profile support to the guest. The host
>>>>>> mappings are also needed for enabling the Venus driver using host GPU
>>>>>> drivers that are utilizing TTM.
>>>>>>
>>>>>> Based on a patch proposed by Trigger Huang.
>>>>> Well I can't count how often I have repeated this: This is an
>>>>> absolutely
>>>>> clear NAK!
>>>>>
>>>>> TTM pages are not reference counted in the first place and because of
>>>>> this giving them to virgl is illegal.
>>>> A? The first page is refcounted when allocated, the tail pages are not.
>>> No they aren't. The first page is just by coincident initialized with
>>> a refcount of 1. This refcount is completely ignored and not used at all.
>>>
>>> Incrementing the reference count and by this mapping the page into
>>> some other address space is illegal and corrupts the internal state
>>> tracking of TTM.
>> See this comment in the source code as well:
>>
>>          /* Don't set the __GFP_COMP flag for higher order allocations.
>>           * Mapping pages directly into an userspace process and calling
>>           * put_page() on a TTM allocated page is illegal.
>>           */
>>
>> I have absolutely no idea how somebody had the idea he could do this.
> I saw this comment, but it doesn't make sense because it doesn't explain
> why it's illegal. Hence it looks like a bogus comment since the
> refcouting certainly works, at least to a some degree because I haven't
> noticed any problems in practice, maybe by luck :)

Well exactly that's the problem. It does not work, you are just lucky :)

I will provide a patch to set the reference count to zero even for 
non-compound pages. Maybe that will yield more backtrace to abusers of 
this interface.

Regards,
Christian.

>
> I'll try to dig out the older discussions, thank you for the quick reply!
>


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König via Virtualization" <virtualization@lists.linux-foundation.org>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	David Airlie <airlied@linux.ie>, Huang Rui <ray.huang@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Trigger Huang <Trigger.Huang@gmail.com>,
	Gert Wollny <gert.wollny@collabora.com>,
	Antonio Caggiano <antonio.caggiano@collabora.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	Dmitry Osipenko <digetx@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
Date: Mon, 15 Aug 2022 12:42:22 +0200	[thread overview]
Message-ID: <2e64c037-ee5a-0c60-5dba-2e48bb437014@amd.com> (raw)
In-Reply-To: <14be3b22-1d60-732b-c695-ddacc6b21055@collabora.com>

Am 15.08.22 um 12:18 schrieb Dmitry Osipenko:
> On 8/15/22 13:14, Christian König wrote:
>> Am 15.08.22 um 12:11 schrieb Christian König:
>>> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko:
>>>> On 8/15/22 13:05, Christian König wrote:
>>>>> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
>>>>>> Higher order pages allocated using alloc_pages() aren't refcounted and
>>>>>> they
>>>>>> need to be refcounted, otherwise it's impossible to map them by
>>>>>> KVM. This
>>>>>> patch sets the refcount of the tail pages and fixes the KVM memory
>>>>>> mapping
>>>>>> faults.
>>>>>>
>>>>>> Without this change guest virgl driver can't map host buffers into
>>>>>> guest
>>>>>> and can't provide OpenGL 4.5 profile support to the guest. The host
>>>>>> mappings are also needed for enabling the Venus driver using host GPU
>>>>>> drivers that are utilizing TTM.
>>>>>>
>>>>>> Based on a patch proposed by Trigger Huang.
>>>>> Well I can't count how often I have repeated this: This is an
>>>>> absolutely
>>>>> clear NAK!
>>>>>
>>>>> TTM pages are not reference counted in the first place and because of
>>>>> this giving them to virgl is illegal.
>>>> A? The first page is refcounted when allocated, the tail pages are not.
>>> No they aren't. The first page is just by coincident initialized with
>>> a refcount of 1. This refcount is completely ignored and not used at all.
>>>
>>> Incrementing the reference count and by this mapping the page into
>>> some other address space is illegal and corrupts the internal state
>>> tracking of TTM.
>> See this comment in the source code as well:
>>
>>          /* Don't set the __GFP_COMP flag for higher order allocations.
>>           * Mapping pages directly into an userspace process and calling
>>           * put_page() on a TTM allocated page is illegal.
>>           */
>>
>> I have absolutely no idea how somebody had the idea he could do this.
> I saw this comment, but it doesn't make sense because it doesn't explain
> why it's illegal. Hence it looks like a bogus comment since the
> refcouting certainly works, at least to a some degree because I haven't
> noticed any problems in practice, maybe by luck :)

Well exactly that's the problem. It does not work, you are just lucky :)

I will provide a patch to set the reference count to zero even for 
non-compound pages. Maybe that will yield more backtrace to abusers of 
this interface.

Regards,
Christian.

>
> I'll try to dig out the older discussions, thank you for the quick reply!
>

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	David Airlie <airlied@linux.ie>, Huang Rui <ray.huang@amd.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Trigger Huang <Trigger.Huang@gmail.com>,
	Gert Wollny <gert.wollny@collabora.com>,
	Antonio Caggiano <antonio.caggiano@collabora.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	Dmitry Osipenko <digetx@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
Date: Mon, 15 Aug 2022 12:42:22 +0200	[thread overview]
Message-ID: <2e64c037-ee5a-0c60-5dba-2e48bb437014@amd.com> (raw)
In-Reply-To: <14be3b22-1d60-732b-c695-ddacc6b21055@collabora.com>

Am 15.08.22 um 12:18 schrieb Dmitry Osipenko:
> On 8/15/22 13:14, Christian König wrote:
>> Am 15.08.22 um 12:11 schrieb Christian König:
>>> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko:
>>>> On 8/15/22 13:05, Christian König wrote:
>>>>> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
>>>>>> Higher order pages allocated using alloc_pages() aren't refcounted and
>>>>>> they
>>>>>> need to be refcounted, otherwise it's impossible to map them by
>>>>>> KVM. This
>>>>>> patch sets the refcount of the tail pages and fixes the KVM memory
>>>>>> mapping
>>>>>> faults.
>>>>>>
>>>>>> Without this change guest virgl driver can't map host buffers into
>>>>>> guest
>>>>>> and can't provide OpenGL 4.5 profile support to the guest. The host
>>>>>> mappings are also needed for enabling the Venus driver using host GPU
>>>>>> drivers that are utilizing TTM.
>>>>>>
>>>>>> Based on a patch proposed by Trigger Huang.
>>>>> Well I can't count how often I have repeated this: This is an
>>>>> absolutely
>>>>> clear NAK!
>>>>>
>>>>> TTM pages are not reference counted in the first place and because of
>>>>> this giving them to virgl is illegal.
>>>> A? The first page is refcounted when allocated, the tail pages are not.
>>> No they aren't. The first page is just by coincident initialized with
>>> a refcount of 1. This refcount is completely ignored and not used at all.
>>>
>>> Incrementing the reference count and by this mapping the page into
>>> some other address space is illegal and corrupts the internal state
>>> tracking of TTM.
>> See this comment in the source code as well:
>>
>>          /* Don't set the __GFP_COMP flag for higher order allocations.
>>           * Mapping pages directly into an userspace process and calling
>>           * put_page() on a TTM allocated page is illegal.
>>           */
>>
>> I have absolutely no idea how somebody had the idea he could do this.
> I saw this comment, but it doesn't make sense because it doesn't explain
> why it's illegal. Hence it looks like a bogus comment since the
> refcouting certainly works, at least to a some degree because I haven't
> noticed any problems in practice, maybe by luck :)

Well exactly that's the problem. It does not work, you are just lucky :)

I will provide a patch to set the reference count to zero even for 
non-compound pages. Maybe that will yield more backtrace to abusers of 
this interface.

Regards,
Christian.

>
> I'll try to dig out the older discussions, thank you for the quick reply!
>


  reply	other threads:[~2022-08-15 10:42 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-15  9:54 [PATCH v1] drm/ttm: Refcount allocated tail pages Dmitry Osipenko
2022-08-15  9:54 ` Dmitry Osipenko
2022-08-15 10:05 ` Christian König
2022-08-15 10:05   ` Christian König
2022-08-15 10:05   ` Christian König via Virtualization
2022-08-15 10:09   ` Dmitry Osipenko
2022-08-15 10:09     ` Dmitry Osipenko
2022-08-15 10:11     ` Christian König
2022-08-15 10:11       ` Christian König
2022-08-15 10:11       ` Christian König via Virtualization
2022-08-15 10:14       ` Christian König via Virtualization
2022-08-15 10:14         ` Christian König
2022-08-15 10:14         ` Christian König
2022-08-15 10:18         ` Dmitry Osipenko
2022-08-15 10:18           ` Dmitry Osipenko
2022-08-15 10:42           ` Christian König [this message]
2022-08-15 10:42             ` Christian König
2022-08-15 10:42             ` Christian König via Virtualization
2022-08-15 10:47           ` Dmitry Osipenko
2022-08-15 10:47             ` Dmitry Osipenko
2022-08-15 10:51             ` Christian König
2022-08-15 10:51               ` Christian König
2022-08-15 10:51               ` Christian König via Virtualization
2022-08-15 11:19               ` Dmitry Osipenko
2022-08-15 11:19                 ` Dmitry Osipenko
2022-08-15 11:28                 ` Christian König
2022-08-15 11:28                   ` Christian König
2022-08-15 11:28                   ` Christian König via Virtualization
2022-08-15 11:50                   ` Dmitry Osipenko
2022-08-15 11:50                     ` Dmitry Osipenko
2022-08-15 13:06                     ` Christian König
2022-08-15 13:06                       ` Christian König
2022-08-15 13:06                       ` Christian König via Virtualization
2022-08-15 13:45                       ` Dmitry Osipenko
2022-08-15 13:45                         ` Dmitry Osipenko
2022-08-15 13:53                         ` Christian König
2022-08-15 13:53                           ` Christian König
2022-08-15 13:53                           ` Christian König via Virtualization
2022-08-15 14:57                           ` Dmitry Osipenko
2022-08-15 14:57                             ` Dmitry Osipenko
2022-08-15 15:54                             ` Dmitry Osipenko
2022-08-15 15:54                               ` Dmitry Osipenko
2022-08-17 22:57                               ` Dmitry Osipenko
2022-08-17 22:57                                 ` Dmitry Osipenko
2022-08-17 23:13                                 ` Dmitry Osipenko
2022-08-17 23:13                                   ` Dmitry Osipenko
2022-08-18  9:41                                   ` Christian König
2022-08-18  9:41                                     ` Christian König
2022-08-18  9:41                                     ` Christian König via Virtualization
2023-01-11 17:05                                     ` Sean Christopherson
2023-01-11 17:05                                       ` Sean Christopherson
2023-01-11 21:24                                       ` Dmitry Osipenko
2023-01-11 21:24                                         ` Dmitry Osipenko
2022-09-06 20:01   ` Daniel Vetter
2022-09-06 20:01     ` Daniel Vetter
2022-09-06 20:01     ` Daniel Vetter
2022-09-06 20:05     ` Daniel Vetter
2022-09-06 20:05       ` Daniel Vetter
2022-09-07  6:48       ` Christian König via Virtualization
2022-09-07  6:48         ` Christian König
2023-01-11 17:13       ` Sean Christopherson
2022-09-08 11:04     ` Rob Clark
2022-09-08 11:04       ` Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e64c037-ee5a-0c60-5dba-2e48bb437014@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Trigger.Huang@gmail.com \
    --cc=airlied@linux.ie \
    --cc=antonio.caggiano@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=digetx@gmail.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gert.wollny@collabora.com \
    --cc=kernel@collabora.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ray.huang@amd.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.