xas_retry() based loops on PREEMPT_RT.

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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