Re: Signal handling in a page fault handler

On Wed, Apr 04, 2018 at 11:32:54AM +0200, Daniel Vetter wrote: > So we've done some experiments for the case where the fault originated > from kernel context (copy_to|from_user and friends). The fixup code seems > to retry the copy once after the fault (in copy_user_handle_tail), if that > fails

Re: Signal handling in a page fault handler

On Wed, Apr 04, 2018 at 05:15:46PM +0200, Daniel Vetter wrote: > On Wed, Apr 4, 2018 at 4:39 PM, Matthew Wilcox wrote: > > I actually have plans to allow mutex_lock_{interruptible,killable} to > > return -EWOULDBLOCK if a flag is set. So this doesn't seem entirely > >

Re: Signal handling in a page fault handler

On Wed, Apr 4, 2018 at 6:24 PM, Matthew Wilcox wrote: > On Wed, Apr 04, 2018 at 05:15:46PM +0200, Daniel Vetter wrote: >> On Wed, Apr 4, 2018 at 4:39 PM, Matthew Wilcox wrote: >> > I actually have plans to allow mutex_lock_{interruptible,killable} to >>

Re: Signal handling in a page fault handler

On Wed, Apr 4, 2018 at 4:39 PM, Matthew Wilcox wrote: > On Wed, Apr 04, 2018 at 11:32:54AM +0200, Daniel Vetter wrote: >> So we've done some experiments for the case where the fault originated >> from kernel context (copy_to|from_user and friends). The fixup code seems >> to

Re: Signal handling in a page fault handler

On Mon, Apr 02, 2018 at 07:10:58AM -0700, Matthew Wilcox wrote: > > Souptick and I have been auditing the various page fault handler routines > and we've noticed that graphics drivers assume that a signal should be > able to interrupt a page fault. In contrast, the page cache takes great > care

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 02:20:43PM +0100, Chris Wilson wrote: > Quoting Matthew Wilcox (2018-04-03 14:10:25) > > On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote: > > > Quoting Matthew Wilcox (2018-04-02 15:10:58) > > > > I don't think the graphics drivers really want to be interrupted

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote: > I think the TTM page fault handler originally set the standard for this. > First, IMO any critical section that waits for the GPU (like typically the > page fault handler does), should be locked at least killable. The need for >

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 07:48:29AM -0700, Matthew Wilcox wrote: > On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote: > > I think the TTM page fault handler originally set the standard for this. > > First, IMO any critical section that waits for the GPU (like typically the > > page

Re: Signal handling in a page fault handler

On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote: > Quoting Matthew Wilcox (2018-04-02 15:10:58) > > Souptick and I have been auditing the various page fault handler routines > > and we've noticed that graphics drivers assume that a signal should be > > able to interrupt a page fault.

Re: Signal handling in a page fault handler

Quoting Matthew Wilcox (2018-04-03 14:10:25) > On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote: > > Quoting Matthew Wilcox (2018-04-02 15:10:58) > > > I don't think the graphics drivers really want to be interrupted by > > > any signal. > > > > Assume the worst case and we may block

Re: Signal handling in a page fault handler

On 04/03/2018 02:33 PM, Chris Wilson wrote: Quoting Matthew Wilcox (2018-04-02 15:10:58) Souptick and I have been auditing the various page fault handler routines and we've noticed that graphics drivers assume that a signal should be able to interrupt a page fault. In contrast, the page cache

Re: Signal handling in a page fault handler

Quoting Matthew Wilcox (2018-04-02 15:10:58) > > Souptick and I have been auditing the various page fault handler routines > and we've noticed that graphics drivers assume that a signal should be > able to interrupt a page fault. In contrast, the page cache takes great > care to allow only fatal