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) &&
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) &&
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
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
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, 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 &
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 &
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)
+
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
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
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:
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
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) &&
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) &&
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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:
>
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 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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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 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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
---
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
---
90 matches
Mail list logo