On 05/01/2018 10:35 AM, Oleg Nesterov wrote:
On 04/30, Andrey Grodzovsky wrote:
On 04/30/2018 12:00 PM, Oleg Nesterov wrote:
On 04/30, Andrey Grodzovsky wrote:
What about changing PF_SIGNALED to PF_EXITING in
drm_sched_entity_do_release
- if ((current->flags & PF_SIGNALED) && current
Am 30.04.2018 um 21:28 schrieb Andrey Grodzovsky:
On 04/30/2018 02:29 PM, Christian König wrote:
Am 30.04.2018 um 18:10 schrieb Andrey Grodzovsky:
On 04/30/2018 12:00 PM, Oleg Nesterov wrote:
On 04/30, Andrey Grodzovsky wrote:
What about changing PF_SIGNALED to PF_EXITING in
drm_sched_ent
On 04/30, Andrey Grodzovsky wrote:
>
> On 04/30/2018 12:00 PM, Oleg Nesterov wrote:
> >On 04/30, Andrey Grodzovsky wrote:
> >>What about changing PF_SIGNALED to PF_EXITING in
> >>drm_sched_entity_do_release
> >>
> >>- if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
> >>+
On 04/30/2018 02:29 PM, Christian König wrote:
Am 30.04.2018 um 18:10 schrieb Andrey Grodzovsky:
On 04/30/2018 12:00 PM, Oleg Nesterov wrote:
On 04/30, Andrey Grodzovsky wrote:
What about changing PF_SIGNALED to PF_EXITING in
drm_sched_entity_do_release
- if ((current->flags & PF_SI
Am 30.04.2018 um 18:10 schrieb Andrey Grodzovsky:
On 04/30/2018 12:00 PM, Oleg Nesterov wrote:
On 04/30, Andrey Grodzovsky wrote:
What about changing PF_SIGNALED to PF_EXITING in
drm_sched_entity_do_release
- if ((current->flags & PF_SIGNALED) && current->exit_code ==
SIGKILL)
+
On 04/30/2018 12:25 PM, Eric W. Biederman wrote:
Christian König writes:
Hi Eric,
sorry for the late response, was on vacation last week.
Am 26.04.2018 um 02:01 schrieb Eric W. Biederman:
Andrey Grodzovsky writes:
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsk
Christian König writes:
> Hi Eric,
>
> sorry for the late response, was on vacation last week.
>
> Am 26.04.2018 um 02:01 schrieb Eric W. Biederman:
>> Andrey Grodzovsky writes:
>>
>>> On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsky wrote:
> here (drm_sched_enti
On 04/30/2018 12:00 PM, Oleg Nesterov wrote:
On 04/30, Andrey Grodzovsky wrote:
What about changing PF_SIGNALED to PF_EXITING in
drm_sched_entity_do_release
- if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
+ if ((current->flags & PF_EXITING) && current->exit_
On 04/30, Andrey Grodzovsky wrote:
>
> What about changing PF_SIGNALED to PF_EXITING in
> drm_sched_entity_do_release
>
> - if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
> + if ((current->flags & PF_EXITING) && current->exit_code == SIGKILL)
let me repeat, please
On 04/30, Christian König wrote:
>
> Well when the process is killed we don't care about correctness any more, we
> just want to get rid of it as quickly as possible (OOM situation etc...).
OK,
> But it is perfectly possible that a process submits some render commands and
> then calls exit() or t
Am 30.04.2018 um 16:32 schrieb Andrey Grodzovsky:
On 04/30/2018 08:08 AM, Christian König wrote:
Hi Eric,
sorry for the late response, was on vacation last week.
Am 26.04.2018 um 02:01 schrieb Eric W. Biederman:
Andrey Grodzovsky writes:
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 0
On 04/30/2018 08:08 AM, Christian König wrote:
Hi Eric,
sorry for the late response, was on vacation last week.
Am 26.04.2018 um 02:01 schrieb Eric W. Biederman:
Andrey Grodzovsky writes:
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsky wrote:
here (drm_sched_enti
Hi Eric,
sorry for the late response, was on vacation last week.
Am 26.04.2018 um 02:01 schrieb Eric W. Biederman:
Andrey Grodzovsky writes:
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsky wrote:
here (drm_sched_entity_fini) is also a bad idea, but we still want to
On 04/26/2018 11:57 AM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/26/2018 08:34 AM, Andrey Grodzovsky wrote:
On 04/25/2018 08:01 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsky wrote:
here
Andrey Grodzovsky writes:
> On 04/26/2018 08:34 AM, Andrey Grodzovsky wrote:
>>
>>
>> On 04/25/2018 08:01 PM, Eric W. Biederman wrote:
>>> Andrey Grodzovsky writes:
>>>
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
> On 04/25, Andrey Grodzovsky wrote:
>> here (drm_sched_entity_fini)
On 04/26/2018 08:34 AM, Andrey Grodzovsky wrote:
On 04/25/2018 08:01 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsky wrote:
here (drm_sched_entity_fini) is also a bad idea, but we still want
to be
able to e
On 04/25/2018 08:01 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsky wrote:
here (drm_sched_entity_fini) is also a bad idea, but we still want to be
able to exit immediately
and not wait for GPU jobs completion
Andrey Grodzovsky writes:
> On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
>> On 04/25, Andrey Grodzovsky wrote:
>>> here (drm_sched_entity_fini) is also a bad idea, but we still want to be
>>> able to exit immediately
>>> and not wait for GPU jobs completion when the reason for reaching this code
On 04/25/2018 01:17 PM, Oleg Nesterov wrote:
On 04/25, Andrey Grodzovsky wrote:
here (drm_sched_entity_fini) is also a bad idea, but we still want to be
able to exit immediately
and not wait for GPU jobs completion when the reason for reaching this code
is because of KILL
signal to the user pr
On 04/25, Andrey Grodzovsky wrote:
>
> here (drm_sched_entity_fini) is also a bad idea, but we still want to be
> able to exit immediately
> and not wait for GPU jobs completion when the reason for reaching this code
> is because of KILL
> signal to the user process who opened the device file.
Can
Andrey Grodzovsky writes:
> On 04/25/2018 11:29 AM, Eric W. Biederman wrote:
>
>> Another issue is changing wait_event_killable to wait_event_timeout where I
>> need
>> to understand
>> what TO value is acceptable for all the drivers using the scheduler, or
>> maybe it
>> should come as a prop
Andrey Grodzovsky writes:
> On 04/25/2018 03:14 AM, Daniel Vetter wrote:
>> On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote:
>>>
>>> On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
>> On
On 04/25/2018 09:55 AM, Oleg Nesterov wrote:
On 04/24, Eric W. Biederman wrote:
Let me respectfully suggest that the wait_event_killable on that code
path is wrong.
I tend to agree even if I don't know this code.
But if it can be called from f_op->release() then any usage of "current" or
sig
On 04/25, Daniel Vetter wrote:
>
> On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote:
> > On 04/24, Daniel Vetter wrote:
> >>
> >> wait_event_killabel doesn't check for fatal_signal_pending before calling
> >> schedule, so definitely has a nice race there.
> >
> > This is fine. See the signal_p
On 04/24, Eric W. Biederman wrote:
>
> Let me respectfully suggest that the wait_event_killable on that code
> path is wrong.
I tend to agree even if I don't know this code.
But if it can be called from f_op->release() then any usage of "current" or
signals looks suspicious. Simply because "curre
On 04/24/2018 05:40 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
On
On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote:
> On 04/24, Daniel Vetter wrote:
>>
>> wait_event_killabel doesn't check for fatal_signal_pending before calling
>> schedule, so definitely has a nice race there.
>
> This is fine. See the signal_pending_state() check in __schedule().
>
> And t
On 04/24, Daniel Vetter wrote:
>
> wait_event_killabel doesn't check for fatal_signal_pending before calling
> schedule, so definitely has a nice race there.
This is fine. See the signal_pending_state() check in __schedule().
And this doesn't differ from wait_event_interruptible(), it too doesn't
On 04/25/2018 03:14 AM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote:
On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer
On 04/24, Andrey Grodzovsky wrote:
>
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct
> drm_gpu_scheduler *sched,
> return;
> /**
>* The client will not que
On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote:
>
>
> On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
> > Andrey Grodzovsky writes:
> >
> > > On 04/24/2018 03:44 PM, Daniel Vetter wrote:
> > > > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> > > > > Adding
Andrey Grodzovsky writes:
> On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
>> Andrey Grodzovsky writes:
>>
>>> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> Adding the dri-devel list, since this is driver independent code
On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote:
>
>
> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> > > Adding the dri-devel list, since this is driver independent code.
> > >
> > >
> > > On 2018-04-24 05:30
On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
On 2018-04-24 05:30 PM, Andrey Grodzovs
Andrey Grodzovsky writes:
> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
>> On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
>>> Adding the dri-devel list, since this is driver independent code.
>>>
>>>
>>> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_eve
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_event_killable when you are possibly being called
Daniel Vetter writes:
> On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
>>
>> Adding the dri-devel list, since this is driver independent code.
>>
>>
>> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
>> > Avoid calling wait_event_killable when you are possibly being called
>>
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
>
> Adding the dri-devel list, since this is driver independent code.
>
>
> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
> > Avoid calling wait_event_killable when you are possibly being called
> > from get_signal routine since i
Andrey Grodzovsky writes:
> On 04/24/2018 12:23 PM, Eric W. Biederman wrote:
>> Andrey Grodzovsky writes:
>>
>>> Avoid calling wait_event_killable when you are possibly being called
>>> from get_signal routine since in that case you end up in a deadlock
>>> where you are alreay blocked in singla
On 04/24/2018 12:23 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
Avoid calling wait_event_killable when you are possibly being called
from get_signal routine since in that case you end up in a deadlock
where you are alreay blocked in singla processing any trying to wait
on a new si
Andrey Grodzovsky writes:
> Avoid calling wait_event_killable when you are possibly being called
> from get_signal routine since in that case you end up in a deadlock
> where you are alreay blocked in singla processing any trying to wait
> on a new signal.
I am curious what the call path that is
On 04/24/2018 11:46 AM, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
Thanks, so many addresses that this one slipped out...
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_event_killable when you are possibly being called
from
On 04/24/2018 11:46 AM, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
Thanks, so many addresses that this one slipped out...
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_event_killable when you are possibly being called
from
Adding the dri-devel list, since this is driver independent code.
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
> Avoid calling wait_event_killable when you are possibly being called
> from get_signal routine since in that case you end up in a deadlock
> where you are alreay blocked in singla
Avoid calling wait_event_killable when you are possibly being called
from get_signal routine since in that case you end up in a deadlock
where you are alreay blocked in singla processing any trying to wait
on a new signal.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/gpu_schedu
45 matches
Mail list logo