On Wed, Aug 7, 2013 at 10:28 AM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: >> Also there's no retry loop w/ ida_pre_get() and since that's outside the >> big kms lock, there could be a (small) chance that someone else already >> consumed the allocation done in ida_pre_get(). And then we'll return >> -EAGAIN which is a rather confusing error from an init function. I >> guess you could just move the ida_pre_get() inside the kms lock and >> avoid that race. > > OK, I'm not really sure what the whole drm locking situation is. If > it's OK to do a GFP_KERNEL alloc inside the "big kms lock" (BKL v2?), > I might as well use the ida_simple_get interface. The big kms lock is just a pile of nested mutexes which all may not be held from shrinker callbacks and similar places. So you can allocate GFP_KERNEL memory with impunity. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
