From: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
To: "Kasiviswanathan,
Harish" <Harish.Kasiviswanathan-5C7GfCeVMHo@public.gmane.org>
Cc: "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 4/4] drm/amdkfd: Check against device cgroup
Date: Tue, 14 May 2019 17:37:54 +0000 [thread overview]
Message-ID: <20190514173749.GA12629@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <20190514015832.GA14741-+gKZQzcddEWxlMhWRU56u/MCgOUTN/qS0E9HWUfgJXw@public.gmane.org>
On Tue, May 14, 2019 at 01:58:40AM +0000, Roman Gushchin wrote:
> On Wed, May 01, 2019 at 02:59:29PM +0000, Kasiviswanathan, Harish wrote:
> > Participate in device cgroup. All kfd devices are exposed via /dev/kfd.
> > So use /dev/dri/renderN node.
> >
> > Before exposing the device to a task check if it has permission to
> > access it. If the task (based on its cgroup) can access /dev/dri/renderN
> > then expose the device via kfd node.
> >
> > If the task cannot access /dev/dri/renderN then process device data
> > (pdd) is not created. This will ensure that task cannot use the device.
> >
> > In sysfs topology, all device nodes are visible irrespective of the task
> > cgroup. The sysfs node directories are created at driver load time and
> > cannot be changed dynamically. However, access to information inside
> > nodes is controlled based on the task's cgroup permissions.
> >
> > Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
> > Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
>
> Hello, Harish!
>
> Cgroup/device controller part looks good to me.
> Please, feel free to use my acks for patches 3 and 4:
> Acked-by: Roman Gushchin <guro@fb.com>
Hello!
After the second look at the patchset I came to an understanding that
exporting cgroup_v1-only __devcgroup_check_permission() isn't the best idea.
Instead it would be better to export devcgroup_check_permission(), which
provides an universal interface for both cgroup v1 and v2 device controllers.
It require some refactorings, but should be not hard.
Does it makes sense to you? Can you, please, rework this part?
Thanks!
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-05-14 17:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-01 14:59 [PATCH 0/4] AMDKFD (AMD GPU compute) support for device cgroup Kasiviswanathan, Harish
[not found] ` <20190501145904.27505-1-Harish.Kasiviswanathan-5C7GfCeVMHo@public.gmane.org>
2019-05-01 14:59 ` [PATCH 1/4] drm/amdkfd: Store kfd_dev in iolink and cache properties Kasiviswanathan, Harish
2019-05-01 14:59 ` [PATCH 2/4] drm/amd: Pass drm_device to kfd Kasiviswanathan, Harish
2019-05-01 14:59 ` [PATCH 3/4] device_cgroup: Export __devcgroup_check_permission Kasiviswanathan, Harish
[not found] ` <20190501145904.27505-4-Harish.Kasiviswanathan-5C7GfCeVMHo@public.gmane.org>
2019-05-13 21:47 ` Kasiviswanathan, Harish
2019-05-01 14:59 ` [PATCH 4/4] drm/amdkfd: Check against device cgroup Kasiviswanathan, Harish
[not found] ` <20190501145904.27505-5-Harish.Kasiviswanathan-5C7GfCeVMHo@public.gmane.org>
2019-05-14 1:58 ` Roman Gushchin
[not found] ` <20190514015832.GA14741-+gKZQzcddEWxlMhWRU56u/MCgOUTN/qS0E9HWUfgJXw@public.gmane.org>
2019-05-14 17:37 ` Roman Gushchin [this message]
[not found] ` <20190514173749.GA12629-+gKZQzcddEWxlMhWRU56u/MCgOUTN/qS0E9HWUfgJXw@public.gmane.org>
2019-05-14 19:43 ` Kasiviswanathan, Harish
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=20190514173749.GA12629@tower.DHCP.thefacebook.com \
--to=guro-b10kyp2domg@public.gmane.org \
--cc=Harish.Kasiviswanathan-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox