lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <874ljyu98e.fsf@xmission.com> Date: Wed, 25 Apr 2018 19:01:05 -0500 From: ebiederm@...ssion.com (Eric W. Biederman) To: Andrey Grodzovsky <Andrey.Grodzovsky@....com> Cc: Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org, Alexander.Deucher@....com, Christian.Koenig@....com, David.Panariti@....com, akpm@...ux-foundation.org Subject: Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process. Andrey Grodzovsky <Andrey.Grodzovsky@....com> 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 >>> is because of KILL >>> signal to the user process who opened the device file. >> Can you hook f_op->flush method? > > But this one is called for each task releasing a reference to the the file, so > not sure I see how this solves the problem. The big question is why do you need to wait during the final closing a file? The wait can be terminated so the wait does not appear to be simply a matter of correctness. Eric
Powered by blists - more mailing lists