All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicolai Hähnle" <nhaehnle@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	christian.koenig@amd.com, "Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <guro@fb.com>
Cc: linux-mm@kvack.org, amd-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC] Per file OOM badness
Date: Tue, 30 Jan 2018 12:36:37 +0100	[thread overview]
Message-ID: <82d5894f-f4ea-98cc-068a-5d470f5267df@gmail.com> (raw)
In-Reply-To: <e511ba10-7032-36cc-f22c-2f6bb05f9f6e@daenzer.net>

On 30.01.2018 12:34, Michel Dänzer wrote:
> On 2018-01-30 12:28 PM, Christian König wrote:
>> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>>> On 2018-01-30 11:40 AM, Christian König wrote:
>>>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>>>>> [SNIP]
>>>>>> Would it be ok to hang onto potentially arbitrary mmget references
>>>>>> essentially forever? If that's ok I think we can do your process based
>>>>>> account (minus a few minor inaccuracies for shared stuff perhaps,
>>>>>> but no
>>>>>> one cares about that).
>>>>> Honestly, I think you and Christian are overthinking this. Let's try
>>>>> charging the memory to every process which shares a buffer, and go from
>>>>> there.
>>>> My problem is that this needs to be bullet prove.
>>>>
>>>> For example imagine an application which allocates a lot of BOs, then
>>>> calls fork() and let the parent process die. The file descriptor lives
>>>> on in the child process, but the memory is not accounted against the
>>>> child.
>>> What exactly are you referring to by "the file descriptor" here?
>>
>> The file descriptor used to identify the connection to the driver. In
>> other words our drm_file structure in the kernel.
>>
>>> What happens to BO handles in general in this case? If both parent and
>>> child process keep the same handle for the same BO, one of them
>>> destroying the handle will result in the other one not being able to use
>>> it anymore either, won't it?
>> Correct.
>>
>> That usage is actually not useful at all, but we already had
>> applications which did exactly that by accident.
>>
>> Not to mention that somebody could do it on purpose.
> 
> Can we just prevent child processes from using their parent's DRM file
> descriptors altogether? Allowing it seems like a bad idea all around.

Existing protocols pass DRM fds between processes though, don't they?

Not child processes perhaps, but special-casing that seems like awful 
design.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

WARNING: multiple messages have this Message-ID (diff)
From: "Nicolai Hähnle" <nhaehnle@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	christian.koenig@amd.com, "Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <guro@fb.com>
Cc: linux-mm@kvack.org, amd-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC] Per file OOM badness
Date: Tue, 30 Jan 2018 12:36:37 +0100	[thread overview]
Message-ID: <82d5894f-f4ea-98cc-068a-5d470f5267df@gmail.com> (raw)
In-Reply-To: <e511ba10-7032-36cc-f22c-2f6bb05f9f6e@daenzer.net>

On 30.01.2018 12:34, Michel DA?nzer wrote:
> On 2018-01-30 12:28 PM, Christian KA?nig wrote:
>> Am 30.01.2018 um 12:02 schrieb Michel DA?nzer:
>>> On 2018-01-30 11:40 AM, Christian KA?nig wrote:
>>>> Am 30.01.2018 um 10:43 schrieb Michel DA?nzer:
>>>>> [SNIP]
>>>>>> Would it be ok to hang onto potentially arbitrary mmget references
>>>>>> essentially forever? If that's ok I think we can do your process based
>>>>>> account (minus a few minor inaccuracies for shared stuff perhaps,
>>>>>> but no
>>>>>> one cares about that).
>>>>> Honestly, I think you and Christian are overthinking this. Let's try
>>>>> charging the memory to every process which shares a buffer, and go from
>>>>> there.
>>>> My problem is that this needs to be bullet prove.
>>>>
>>>> For example imagine an application which allocates a lot of BOs, then
>>>> calls fork() and let the parent process die. The file descriptor lives
>>>> on in the child process, but the memory is not accounted against the
>>>> child.
>>> What exactly are you referring to by "the file descriptor" here?
>>
>> The file descriptor used to identify the connection to the driver. In
>> other words our drm_file structure in the kernel.
>>
>>> What happens to BO handles in general in this case? If both parent and
>>> child process keep the same handle for the same BO, one of them
>>> destroying the handle will result in the other one not being able to use
>>> it anymore either, won't it?
>> Correct.
>>
>> That usage is actually not useful at all, but we already had
>> applications which did exactly that by accident.
>>
>> Not to mention that somebody could do it on purpose.
> 
> Can we just prevent child processes from using their parent's DRM file
> descriptors altogether? Allowing it seems like a bad idea all around.

Existing protocols pass DRM fds between processes though, don't they?

Not child processes perhaps, but special-casing that seems like awful 
design.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "Nicolai Hähnle" <nhaehnle@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	christian.koenig@amd.com, "Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <guro@fb.com>
Cc: linux-mm@kvack.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org
Subject: Re: [RFC] Per file OOM badness
Date: Tue, 30 Jan 2018 12:36:37 +0100	[thread overview]
Message-ID: <82d5894f-f4ea-98cc-068a-5d470f5267df@gmail.com> (raw)
In-Reply-To: <e511ba10-7032-36cc-f22c-2f6bb05f9f6e@daenzer.net>

On 30.01.2018 12:34, Michel Dänzer wrote:
> On 2018-01-30 12:28 PM, Christian König wrote:
>> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>>> On 2018-01-30 11:40 AM, Christian König wrote:
>>>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>>>>> [SNIP]
>>>>>> Would it be ok to hang onto potentially arbitrary mmget references
>>>>>> essentially forever? If that's ok I think we can do your process based
>>>>>> account (minus a few minor inaccuracies for shared stuff perhaps,
>>>>>> but no
>>>>>> one cares about that).
>>>>> Honestly, I think you and Christian are overthinking this. Let's try
>>>>> charging the memory to every process which shares a buffer, and go from
>>>>> there.
>>>> My problem is that this needs to be bullet prove.
>>>>
>>>> For example imagine an application which allocates a lot of BOs, then
>>>> calls fork() and let the parent process die. The file descriptor lives
>>>> on in the child process, but the memory is not accounted against the
>>>> child.
>>> What exactly are you referring to by "the file descriptor" here?
>>
>> The file descriptor used to identify the connection to the driver. In
>> other words our drm_file structure in the kernel.
>>
>>> What happens to BO handles in general in this case? If both parent and
>>> child process keep the same handle for the same BO, one of them
>>> destroying the handle will result in the other one not being able to use
>>> it anymore either, won't it?
>> Correct.
>>
>> That usage is actually not useful at all, but we already had
>> applications which did exactly that by accident.
>>
>> Not to mention that somebody could do it on purpose.
> 
> Can we just prevent child processes from using their parent's DRM file
> descriptors altogether? Allowing it seems like a bad idea all around.

Existing protocols pass DRM fds between processes though, don't they?

Not child processes perhaps, but special-casing that seems like awful 
design.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-01-30 11:36 UTC|newest]

Thread overview: 170+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 16:47 [RFC] Per file OOM badness Andrey Grodzovsky
2018-01-18 16:47 ` Andrey Grodzovsky
2018-01-18 16:47 ` Andrey Grodzovsky
2018-01-18 16:47 ` [PATCH 1/4] fs: add OOM badness callback in file_operatrations struct Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-18 16:47 ` [PATCH 2/4] oom: take per file badness into account Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-18 16:47 ` [PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-19  6:01   ` Chunming Zhou
2018-01-19  6:01     ` Chunming Zhou
2018-01-19  6:01     ` Chunming Zhou
2018-01-18 16:47 ` [PATCH 4/4] drm/amdgpu: Use drm_oom_badness for amdgpu Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-18 16:47   ` Andrey Grodzovsky
2018-01-30  9:24   ` Daniel Vetter
2018-01-30  9:24     ` Daniel Vetter
2018-01-30 12:42     ` Andrey Grodzovsky
2018-01-30 12:42       ` Andrey Grodzovsky
2018-01-30 12:42       ` Andrey Grodzovsky
2018-01-18 17:00 ` [RFC] Per file OOM badness Michal Hocko
2018-01-18 17:00   ` Michal Hocko
2018-01-18 17:00   ` Michal Hocko
2018-01-18 17:13   ` Michal Hocko
2018-01-18 17:13     ` Michal Hocko
2018-01-18 20:01     ` Eric Anholt
2018-01-19  8:20       ` Michal Hocko
2018-01-19  8:20         ` Michal Hocko
2018-01-19  8:20         ` Michal Hocko
2018-01-19  8:39         ` Christian König
2018-01-19  8:39           ` Christian König
2018-01-19  8:39           ` Christian König
2018-01-19  9:32           ` Michel Dänzer
2018-01-19  9:32             ` Michel Dänzer
2018-01-19  9:32             ` Michel Dänzer
2018-01-19  9:58             ` Christian König
2018-01-19  9:58               ` Christian König
2018-01-19  9:58               ` Christian König
2018-01-19 10:02               ` Michel Dänzer
2018-01-19 10:02                 ` Michel Dänzer
2018-01-19 10:02                 ` Michel Dänzer
2018-01-19 15:07                 ` Michel Dänzer
2018-01-19 15:07                   ` Michel Dänzer
2018-01-21  6:50                   ` Eric Anholt
2018-01-19 10:40           ` Michal Hocko
2018-01-19 10:40             ` Michal Hocko
2018-01-19 10:40             ` Michal Hocko
2018-01-19 11:37             ` Christian König
2018-01-19 11:37               ` Christian König
2018-01-19 11:37               ` Christian König
2018-01-19 12:13               ` Michal Hocko
2018-01-19 12:13                 ` Michal Hocko
2018-01-19 12:13                 ` Michal Hocko
2018-01-19 12:20                 ` Michal Hocko
2018-01-19 12:20                   ` Michal Hocko
2018-01-19 12:20                   ` Michal Hocko
2018-01-19 16:54                   ` Christian König
2018-01-19 16:54                     ` Christian König
2018-01-19 16:54                     ` Christian König
2018-01-23 11:39                     ` Michal Hocko
2018-01-23 11:39                       ` Michal Hocko
2018-01-23 11:39                       ` Michal Hocko
2018-01-19 16:48               ` Michel Dänzer
2018-01-19 16:48                 ` Michel Dänzer
2018-01-19 16:48                 ` Michel Dänzer
2018-01-19  8:35       ` Christian König
2018-01-19  8:35         ` Christian König
2018-01-19  6:01     ` He, Roger
2018-01-19  8:25       ` Michal Hocko
2018-01-19  8:25         ` Michal Hocko
2018-01-19 10:02         ` roger
2018-01-19 10:02           ` roger
2018-01-23 15:27   ` Roman Gushchin
2018-01-23 15:27     ` Roman Gushchin
2018-01-23 15:27     ` Roman Gushchin
2018-01-23 15:36     ` Michal Hocko
2018-01-23 15:36       ` Michal Hocko
2018-01-23 15:36       ` Michal Hocko
2018-01-23 16:39       ` Michel Dänzer
2018-01-23 16:39         ` Michel Dänzer
2018-01-23 16:39         ` Michel Dänzer
2018-01-24  9:28         ` Michal Hocko
2018-01-24  9:28           ` Michal Hocko
2018-01-24  9:28           ` Michal Hocko
2018-01-24 10:27           ` Michel Dänzer
2018-01-24 10:27             ` Michel Dänzer
2018-01-24 10:27             ` Michel Dänzer
2018-01-24 11:01             ` Michal Hocko
2018-01-24 11:01               ` Michal Hocko
2018-01-24 11:01               ` Michal Hocko
2018-01-24 11:23               ` Michel Dänzer
2018-01-24 11:23                 ` Michel Dänzer
2018-01-24 11:23                 ` Michel Dänzer
2018-01-24 11:50                 ` Michal Hocko
2018-01-24 11:50                   ` Michal Hocko
2018-01-24 11:50                   ` Michal Hocko
2018-01-24 12:11                   ` Christian König
2018-01-24 12:11                     ` Christian König
2018-01-30  9:31                     ` Daniel Vetter
2018-01-30  9:31                       ` Daniel Vetter
2018-01-30  9:31                       ` Daniel Vetter
2018-01-30  9:43                       ` Michel Dänzer
2018-01-30  9:43                         ` Michel Dänzer
2018-01-30  9:43                         ` Michel Dänzer
2018-01-30 10:40                         ` Christian König
2018-01-30 10:40                           ` Christian König
2018-01-30 10:40                           ` Christian König
2018-01-30 11:02                           ` Michel Dänzer
2018-01-30 11:02                             ` Michel Dänzer
2018-01-30 11:02                             ` Michel Dänzer
2018-01-30 11:28                             ` Christian König
2018-01-30 11:28                               ` Christian König
2018-01-30 11:34                               ` Michel Dänzer
2018-01-30 11:34                                 ` Michel Dänzer
2018-01-30 11:34                                 ` Michel Dänzer
2018-01-30 11:36                                 ` Nicolai Hähnle [this message]
2018-01-30 11:36                                   ` Nicolai Hähnle
2018-01-30 11:36                                   ` Nicolai Hähnle
2018-01-30 11:42                                   ` Michel Dänzer
2018-01-30 11:42                                     ` Michel Dänzer
2018-01-30 11:42                                     ` Michel Dänzer
2018-01-30 11:56                                     ` Christian König
2018-01-30 11:56                                       ` Christian König
2018-01-30 11:56                                       ` Christian König
2018-01-30 15:52                                       ` Michel Dänzer
2018-01-30 15:52                                         ` Michel Dänzer
2018-01-30 15:52                                         ` Michel Dänzer
2018-01-30 10:42                         ` Daniel Vetter
2018-01-30 10:42                           ` Daniel Vetter
2018-01-30 10:42                           ` Daniel Vetter
2018-01-30 10:48                           ` Michel Dänzer
2018-01-30 10:48                             ` Michel Dänzer
2018-01-30 10:48                             ` Michel Dänzer
2018-01-30 11:35                             ` Nicolai Hähnle
2018-01-30 11:35                               ` Nicolai Hähnle
2018-01-30 11:35                               ` Nicolai Hähnle
2018-01-24 14:31                   ` Michel Dänzer
2018-01-24 14:31                     ` Michel Dänzer
2018-01-24 14:31                     ` Michel Dänzer
2018-01-30  9:29                   ` Michel Dänzer
2018-01-30  9:29                     ` Michel Dänzer
2018-01-30  9:29                     ` Michel Dänzer
2018-01-30 10:28                     ` Michal Hocko
2018-01-30 10:28                       ` Michal Hocko
2018-01-30 10:28                       ` Michal Hocko
2018-03-26 14:36                       ` Lucas Stach
2018-03-26 14:36                         ` Lucas Stach
2018-03-26 14:36                         ` Lucas Stach
2018-04-04  9:09                         ` Michel Dänzer
2018-04-04  9:09                           ` Michel Dänzer
2018-04-04  9:09                           ` Michel Dänzer
2018-04-04  9:36                           ` Lucas Stach
2018-04-04  9:36                             ` Lucas Stach
2018-04-04  9:36                             ` Lucas Stach
2018-04-04  9:46                             ` Michel Dänzer
2018-04-04  9:46                               ` Michel Dänzer
2018-04-04  9:46                               ` Michel Dänzer
2018-01-19  5:39 ` He, Roger
2018-01-19  8:17   ` Christian König
2018-01-19  8:17     ` Christian König
2018-01-19  8:17     ` Christian König
2018-01-22 23:23 ` Andrew Morton
2018-01-22 23:23   ` Andrew Morton
2018-01-22 23:23   ` Andrew Morton
2018-01-23  1:59   ` Andrey Grodzovsky
2018-01-23  1:59     ` Andrey Grodzovsky
  -- strict thread matches above, loose matches on Subject: below --
2015-09-04 12:53 Christian König

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=82d5894f-f4ea-98cc-068a-5d470f5267df@gmail.com \
    --to=nhaehnle@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=guro@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=michel@daenzer.net \
    /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.