<div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 19 Apr 2021 at 11:48, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="">Deadlock mitigation to recover from segfaults:</span><br></div><div>- The kernel knows which process is obliged to signal which fence. This information is part of the Present request and supplied by userspace.<br></div><div>- If the producer crashes, the kernel signals the submit fence, so that the consumer can make forward progress.</div><div>- If the consumer crashes, the kernel signals the return fence, so that the producer can reclaim the buffer.</div><div>- A GPU hang signals all fences. Other deadlocks will be handled like GPU hangs.</div></div></blockquote><div><br></div><div>Another thought: with completely arbitrary userspace fencing, none of this is helpful either. If the compositor can't guarantee that a hostile client has submitted a fence which will never be signaled, then it won't be waiting on it, so it already needs infrastructure to handle something like this. That already handles the crashed-client case, because if the client crashes, then its connection will be dropped, which will trigger the compositor to destroy all its resources anyway, including any pending waits.</div><div><br></div><div>GPU hangs also look pretty similar; it's an infinite wait, until the client resubmits a new buffer which would replace (& discard) the old.</div><div><br></div><div>So signal-fence-on-process-exit isn't helpful and doesn't provide any extra reliability; it in fact probably just complicates things.</div><div><span style=""><br></span></div><div><span style="">Cheers,</span></div><div><span style="">Daniel </span></div></div></div>