Am 20.04.21 um 16:53 schrieb Daniel Stone: > Hi, > > On Mon, 19 Apr 2021 at 11:48, Marek Olšák > wrote: > > Deadlock mitigation to recover from segfaults: > - The kernel knows which process is obliged to signal which fence. > This information is part of the Present request and supplied by > userspace. > - If the producer crashes, the kernel signals the submit fence, so > that the consumer can make forward progress. > - If the consumer crashes, the kernel signals the return fence, so > that the producer can reclaim the buffer. > - A GPU hang signals all fences. Other deadlocks will be handled > like GPU hangs. > > > 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. Exactly that's the problem. A compositor isn't immediately informed that the client crashed, instead it is still referencing the buffer and trying to use it for compositing. > > GPU hangs also look pretty similar; it's an infinite wait, until the > client resubmits a new buffer which would replace (& discard) the old. Correct. You just need to assume that all queues get destroyed and re-initialized when a GPU reset happens. > > So signal-fence-on-process-exit isn't helpful and doesn't provide any > extra reliability; it in fact probably just complicates things. Well it is when you go for partial GPU resets. Regards, Christian. > > Cheers, > Daniel > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev