Lines Matching full:list

134 Method 1, using a list in execbuf->buffers that's not allowed to be reordered.
135 This is useful if a list of required objects is already tracked somewhere.
137 the caller as a signal that an object is twice on the list. This is useful if
138 the list is constructed from userspace input and the ABI requires userspace to
141   int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
150 	list_for_each_entry (entry, list, head) {
166 	list_for_each_entry_continue_reverse (entry, list, head)
183 Method 2, using a list in execbuf->buffers that can be reordered. Same semantics
185 list-reordering allows for a bit more idiomatic code::
187   int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
193 	list_for_each_entry (entry, list, head) {
198 			list_for_each_entry_continue_reverse (entry2, list, head)
210 			 * Move buf to head of the list, this will point
215 			list_add(&entry->head, list);
225   void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
229 	list_for_each_entry (entry, list, head)
235 Method 3 is useful if the list of objects is constructed ad-hoc and not upfront,
250 - Since the list of objects is dynamically constructed (and might very well be
252   no need to keep any object on a persistent list when it's not locked. We can
254 - On the other hand the dynamic object list construction also means that the -EALREADY return
258 list of starting nodes (passed in from userspace) using one of the above
262 objects acquired with the fixed list. But the w/w mutex debug checks will catch
276   void __unlock_objs(struct list_head *list)
280 	list_for_each_entry_safe (entry, temp, list, locked_list) {
288   void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
306 			__unlock_objs(list);
309 			list_add(&entry->locked_list, list);
313 		/* locked a new object, add it to the list */
314 		list_add_tail(&entry->locked_list, list);
321   void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
323 	__unlock_objs(list);
342   We maintain the following invariants for the wait list:
348       may come after other waiters without contexts in the list.