Hi, I've been looking at the xas_retry() based loops under PREEMPT_RT constraints that is xarray::xa_lock owner got preempted by a task with higher priority and this task is performing a xas_retry() based loop. Since the xarray::xa_lock owner got preempted it can't make any progress until the task the higher priority completes its task. Based on my understanding this the XA_RETRY_ENTRY state is transient while a node is removed from the tree. That is, it is first removed from the tree, then set to XA_RETRY_ENTRY and then kfree()ed. Any RCU reader that retrieved this node before it was removed, will see this flag and will iterate the array from beginning at which point it won't see this node again. The XA_ZERO_ENTRY flag is different as it is not transient. It should be the responsibility of the reader not to start iterating the tree from the beginning because this state won't change. Most reader simply go to the next entry and I *assume* that for instance mapping_get_entry() or find_get_entry() in mm/filemap.c won't see here the XA_ZERO_ENTRY. Is this correct? Sebastian
