Lines Matching refs:list

108 Method 1, using a list in execbuf->buffers that's not allowed to be reordered.
109 This is useful if a list of required objects is already tracked somewhere.
111 the caller as a signal that an object is twice on the list. This is useful if
112 the list is constructed from userspace input and the ABI requires userspace to
115 int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
124 	list_for_each_entry (entry, list, head) {
140 	list_for_each_entry_continue_reverse (entry, list, head)
157 Method 2, using a list in execbuf->buffers that can be reordered. Same semantics
159 list-reordering allows for a bit more idiomatic code.
161 int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
167 	list_for_each_entry (entry, list, head) {
172 			list_for_each_entry_continue_reverse (entry2, list, head)
184 			 * Move buf to head of the list, this will point
189 			list_add(&entry->head, list);
199 void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
203 	list_for_each_entry (entry, list, head)
209 Method 3 is useful if the list of objects is constructed ad-hoc and not upfront,
222 - Since the list of objects is dynamically constructed (and might very well be
224   no need to keep any object on a persistent list when it's not locked. We can
226 - On the other hand the dynamic object list construction also means that the -EALREADY return
230 list of starting nodes (passed in from userspace) using one of the above
234 objects acquired with the fixed list. But the w/w mutex debug checks will catch
248 void __unlock_objs(struct list_head *list)
252 	list_for_each_entry_safe (entry, temp, list, locked_list) {
260 void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
278 			__unlock_objs(list);
281 			list_add(&entry->locked_list, list);
285 		/* locked a new object, add it to the list */
286 		list_add_tail(&entry->locked_list, list);
293 void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
295 	__unlock_objs(list);