Lines Matching refs:can

10 can be shared across contexts/processes, exist in different memory
12 PRIME / dmabuf, they can even be shared across devices.  So there are
24 simplified understanding of the problem you can ignore this.
36 The older tasks waits until it can acquire the contended lock. The younger tasks
73     very first lock operation can never fail.
77     slowpath until the contended lock can be acquired).
110 Furthermore the lock helper can use propagate the -EALREADY return code back to
157 Method 2, using a list in execbuf->buffers that can be reordered. Same semantics
211 and edges can only be changed when holding the locks of all involved nodes. w/w
213 - They can handle lock-acquisition in any order which allows us to start walking
224   no need to keep any object on a persistent list when it's not locked. We can
227   code can't be propagated.
229 Note also that methods #1 and #2 and method #3 can be combined, e.g. to first lock a
237 Also, method 3 can't fail the lock acquisition step since it doesn't return
300 prevention is obviously overkill, since with grabbing just one lock you can't
302 api can be used with a NULL context.
336    - Normal lockdep errors that can result in deadlocks.
338   Some of the lockdep errors that can result in deadlocks:
341    - 'normal' deadlocks that can occur.