On Wed, 11 Dec 2013 15:46:53 +0100 Thomas Hellstrom <thellstrom@xxxxxxxxxx> wrote: > > I think the kernel just has to trust userspace on this. I can't think > > of any way of not involving userspace, so if somebody really wants to > > hack mesa to gain some fps advantage on a multiseat system, let them ;) > > > > Basically, they already can hack mesa to pass invalid buffers to cause > > a hang/crash the kernel. So we already trust userspace more than this > > new functionality would. > > Yes, but these are two different things. Letting user-space pin buffers > by design is building in a software DOS in the kernel. > I don't think even Microsoft is allowing this, and AFAICT we've avoided > that since the very dawn of kernel buffer management. > > Not having a perfect command stream parser or proper GPU hang recovery > mechanism is something else, and something we wish > to have but don't at the moment. > > Allowing a new type of DOS just because we have other flaws isn't moving > things forward, but i guess in the end it's your choice. The worst case with the scoring is that a new client will work somewhat slower than it otherwise would. I wouldn't call this a DOS. Instead I would compare it to nice levels. Still, I agree with your concern that a user could disturb another user. This wouldn't be an issue within a single user environment, as the user obviously wanted it if he went that far. Perhaps we could solve that by taking the process's UID into account inside the kernel. If there are multiple UIDs with 3d processes running, reserve a chunk of VRAM for each? - Lauri _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
