Read-mostly 연결 리스트를 RCU로 보호하기

RCU list 순회 의미론

RCU의 가장 흔한 용도 중 하나는 `include/linux/list.h`의 `struct list_head`로 만든 read-mostly 연결 리스트를 보호하는 것이다. RCU 전용 list macro가 필요한 memory ordering을 포함하므로 사용자가 포인터 barrier를 직접 조합할 필요가 줄어든다.

`rcu_read_lock()` 아래에서 순회하는 동안 writer는 리스트를 변경할 수 있다. Reader는 lock을 잡기 전에 추가되었고 unlock할 때까지 남아 있는 원소를 모두 보지만, 순회와 동시에 추가되거나 제거된 원소는 볼 수도 있고 못 볼 수도 있다. `list_replace_rcu()`와 겹친 reader는 old 또는 new 원소 중 하나만 보며, 둘 다 보거나 둘 다 놓치지는 않는다.

.. _list_rcu_doc:

Using RCU to Protect Read-Mostly Linked Lists
=============================================

One of the most common uses of RCU is protecting read-mostly linked lists
(``struct list_head`` in list.h).  One big advantage of this approach is
that all of the required memory ordering is provided by the list macros.
This document describes several list-based RCU use cases.

When iterating a list while holding the rcu_read_lock(), writers may
modify the list.  The reader is guaranteed to see all of the elements
which were added to the list before they acquired the rcu_read_lock()
and are still on the list when they drop the rcu_read_unlock().
Elements which are added to, or removed from the list may or may not
be seen.  If the writer calls list_replace_rcu(), the reader may see
either the old element or the new element; they will not see both,
nor will they see neither.

예제 1: 삭제 후 파괴 지연

프로세스 전체 목록은 `task_struct::tasks`를 list node로 사용하며 `for_each_process()`가 `next_task()`와 `list_entry_rcu()`를 통해 lockless 순회한다. Reader는 `rcu_read_lock()`과 unlock 사이에서 각 `task_struct`를 사용한다.

`release_task()`는 `tasklist_lock` writer lock 아래 `list_del_rcu(&p->tasks)`로 원소를 제거한다. 이 lock은 writer끼리의 pointer 변경을 직렬화하지만 reader는 잡지 않는다. 이어 `call_rcu(&p->rcu, delayed_put_task_struct)`가 기존 reader가 모두 끝난 뒤 실제 파괴를 수행한다.

`list_del_rcu()`는 새 reader가 더는 원소를 찾지 못하게 하지만 이미 해당 원소에 도달한 reader의 `p->tasks.next`는 유효하게 남아야 한다. Grace period 뒤의 callback이 이 수명을 보장한다. 이런 패턴은 reader가 참조할 가능성이 있는 동안 객체의 존재 자체를 보장하므로 existence lock이라고도 부른다.

Example 1: Read-mostly list: Deferred Destruction
-------------------------------------------------

A widely used usecase for RCU lists in the kernel is lockless iteration over
all processes in the system. ``task_struct::tasks`` represents the list node that
links all the processes. The list can be traversed in parallel to any list
additions or removals.

The traversal of the list is done using ``for_each_process()`` which is defined
by the 2 macros::

        #define next_task(p) \
                list_entry_rcu((p)->tasks.next, struct task_struct, tasks)

        #define for_each_process(p) \
                for (p = &init_task ; (p = next_task(p)) != &init_task ; )

The code traversing the list of all processes typically looks like::

        rcu_read_lock();
        for_each_process(p) {
                /* Do something with p */
        }
        rcu_read_unlock();

The simplified and heavily inlined code for removing a process from a
task list is::

        void release_task(struct task_struct *p)
        {
                write_lock(&tasklist_lock);
                list_del_rcu(&p->tasks);
                write_unlock(&tasklist_lock);
                call_rcu(&p->rcu, delayed_put_task_struct);
        }

When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)``
via __exit_signal() and __unhash_process() under ``tasklist_lock``
writer lock protection.  The list_del_rcu() invocation removes
the task from the list of all tasks. The ``tasklist_lock``
prevents concurrent list additions/removals from corrupting the
list. Readers using ``for_each_process()`` are not protected with the
``tasklist_lock``. To prevent readers from noticing changes in the list
pointers, the ``task_struct`` object is freed only after one or more
grace periods elapse, with the help of call_rcu(), which is invoked via
put_task_struct_rcu_user(). This deferring of destruction ensures that
any readers traversing the list will see valid ``p->tasks.next`` pointers
and deletion/freeing can happen in parallel with traversal of the list.
This pattern is also called an **existence lock**, since RCU refrains
from invoking the delayed_put_task_struct() callback function until
all existing readers finish, which guarantees that the ``task_struct``
object in question will remain in existence until after the completion
of all RCU readers that might possibly have a reference to that object.

예제 2: 락 밖에서 값 사용, in-place 갱신 없음

Read lock 아래 값을 계산한 뒤 lock을 풀고 그 값을 사용하는 알고리즘은 RCU 전환에 적합할 수 있다. 네트워크 route처럼 외부 세계 상태를 추적하는 자료는 본질적으로 약간 오래될 수 있으므로 packet 전송 내내 routing table을 고정할 필요가 없다. 원소가 주로 추가·삭제되고 in-place로 바뀌지 않는다는 점도 RCU에 유리하다.

`audit_filter_task()`의 reader-writer lock 버전은 `read_lock(&auditsc_lock)`과 `list_for_each_entry()`를 쓴다. RCU 버전은 이를 `rcu_read_lock()`과 `list_for_each_entry_rcu()`로 바꾼다. `_rcu()` 순회 macro는 `READ_ONCE()`와 RCU critical section 밖에서 잘못 사용했는지 확인하는 진단을 추가한다.

Writer의 `audit_del_rule()`과 `audit_add_rule()`은 각각 `list_del_rcu()`, `list_add_rcu()`, `list_add_tail_rcu()`를 사용하고 제거 객체는 `call_rcu(&e->rcu, audit_free_rule)`로 늦게 해제한다. 모든 caller가 `audit_filter_mutex`를 이미 잡으므로 별도 `auditsc_lock`은 없앨 수 있다. 일반적인 경우라면 reader-writer lock의 writer 부분을 spinlock으로 바꿔 writer끼리 직렬화한다.

RCU list 갱신 macro는 weakly ordered CPU에 필요한 barrier를 포함한다. 특히 `list_del_rcu()`는 일반 `list_del()`의 pointer poisoning을 하지 않는다. Poison value를 넣으면 동시에 순회하는 reader가 유효한 next pointer 대신 poison을 따라가 실패하기 때문이다.

Example 2: Read-Side Action Taken Outside of Lock: No In-Place Updates
----------------------------------------------------------------------

Some reader-writer locking use cases compute a value while holding
the read-side lock, but continue to use that value after that lock is
released.  These use cases are often good candidates for conversion
to RCU.  One prominent example involves network packet routing.
Because the packet-routing data tracks the state of equipment outside
of the computer, it will at times contain stale data.  Therefore, once
the route has been computed, there is no need to hold the routing table
static during transmission of the packet.  After all, you can hold the
routing table static all you want, but that won't keep the external
Internet from changing, and it is the state of the external Internet
that really matters.  In addition, routing entries are typically added
or deleted, rather than being modified in place.  This is a rare example
of the finite speed of light and the non-zero size of atoms actually
helping make synchronization be lighter weight.

A straightforward example of this type of RCU use case may be found in
the system-call auditing support.  For example, a reader-writer locked
implementation of ``audit_filter_task()`` might be as follows::

        static enum audit_state audit_filter_task(struct task_struct *tsk, char **key)
        {
                struct audit_entry *e;
                enum audit_state   state;

                read_lock(&auditsc_lock);
                /* Note: audit_filter_mutex held by caller. */
                list_for_each_entry(e, &audit_tsklist, list) {
                        if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
                                if (state == AUDIT_STATE_RECORD)
                                        *key = kstrdup(e->rule.filterkey, GFP_ATOMIC);
                                read_unlock(&auditsc_lock);
                                return state;
                        }
                }
                read_unlock(&auditsc_lock);
                return AUDIT_BUILD_CONTEXT;
        }

Here the list is searched under the lock, but the lock is dropped before
the corresponding value is returned.  By the time that this value is acted
on, the list may well have been modified.  This makes sense, since if
you are turning auditing off, it is OK to audit a few extra system calls.

This means that RCU can be easily applied to the read side, as follows::

        static enum audit_state audit_filter_task(struct task_struct *tsk, char **key)
        {
                struct audit_entry *e;
                enum audit_state   state;

                rcu_read_lock();
                /* Note: audit_filter_mutex held by caller. */
                list_for_each_entry_rcu(e, &audit_tsklist, list) {
                        if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
                                if (state == AUDIT_STATE_RECORD)
                                        *key = kstrdup(e->rule.filterkey, GFP_ATOMIC);
                                rcu_read_unlock();
                                return state;
                        }
                }
                rcu_read_unlock();
                return AUDIT_BUILD_CONTEXT;
        }

The read_lock() and read_unlock() calls have become rcu_read_lock()
and rcu_read_unlock(), respectively, and the list_for_each_entry()
has become list_for_each_entry_rcu().  The **_rcu()** list-traversal
primitives add READ_ONCE() and diagnostic checks for incorrect use
outside of an RCU read-side critical section.

The changes to the update side are also straightforward. A reader-writer lock
might be used as follows for deletion and insertion in these simplified
versions of audit_del_rule() and audit_add_rule()::

        static inline int audit_del_rule(struct audit_rule *rule,
                                         struct list_head *list)
        {
                struct audit_entry *e;

                write_lock(&auditsc_lock);
                list_for_each_entry(e, list, list) {
                        if (!audit_compare_rule(rule, &e->rule)) {
                                list_del(&e->list);
                                write_unlock(&auditsc_lock);
                                return 0;
                        }
                }
                write_unlock(&auditsc_lock);
                return -EFAULT;                /* No matching rule */
        }

        static inline int audit_add_rule(struct audit_entry *entry,
                                         struct list_head *list)
        {
                write_lock(&auditsc_lock);
                if (entry->rule.flags & AUDIT_PREPEND) {
                        entry->rule.flags &= ~AUDIT_PREPEND;
                        list_add(&entry->list, list);
                } else {
                        list_add_tail(&entry->list, list);
                }
                write_unlock(&auditsc_lock);
                return 0;
        }

Following are the RCU equivalents for these two functions::

        static inline int audit_del_rule(struct audit_rule *rule,
                                         struct list_head *list)
        {
                struct audit_entry *e;

                /* No need to use the _rcu iterator here, since this is the only
                 * deletion routine. */
                list_for_each_entry(e, list, list) {
                        if (!audit_compare_rule(rule, &e->rule)) {
                                list_del_rcu(&e->list);
                                call_rcu(&e->rcu, audit_free_rule);
                                return 0;
                        }
                }
                return -EFAULT;                /* No matching rule */
        }

        static inline int audit_add_rule(struct audit_entry *entry,
                                         struct list_head *list)
        {
                if (entry->rule.flags & AUDIT_PREPEND) {
                        entry->rule.flags &= ~AUDIT_PREPEND;
                        list_add_rcu(&entry->list, list);
                } else {
                        list_add_tail_rcu(&entry->list, list);
                }
                return 0;
        }

Normally, the write_lock() and write_unlock() would be replaced by a
spin_lock() and a spin_unlock(). But in this case, all callers hold
``audit_filter_mutex``, so no additional locking is required. The
auditsc_lock can therefore be eliminated, since use of RCU eliminates the
need for writers to exclude readers.

The list_del(), list_add(), and list_add_tail() primitives have been
replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu().
The **_rcu()** list-manipulation primitives add memory barriers that are
needed on weakly ordered CPUs.  The list_del_rcu() primitive omits the
pointer poisoning debug-assist code that would otherwise cause concurrent
readers to fail spectacularly.

So, when readers can tolerate stale data and when entries are either added or
deleted, without in-place modification, it is very easy to use RCU!

예제 3: In-place 갱신 대신 copy-replace

여러 필드를 in-place로 바꾸면 lockless reader가 old/new 필드를 섞어 볼 수 있다. Reader-writer lock 버전의 `audit_upd_rule()`은 writer lock 아래 `action`과 `field_count`를 직접 바꾸지만, 같은 동작을 RCU에서 그대로 수행하면 일관성이 깨진다.

RCU 버전은 새 `audit_entry`를 `kmalloc()`으로 할당하고 `audit_copy_rule()`로 old 값을 복사한 뒤 새 필드를 수정한다. `list_replace_rcu(&e->list, &ne->list)`가 old 원소를 완성된 new 원소로 원자적으로 교체하고 `call_rcu()`가 old 객체를 늦게 해제한다. 이 copy-update-replace 순서가 Read-Copy Update라는 이름의 직접적인 예다.

실제 `update_lsm_rule()`도 비슷한 패턴을 사용한다. Open vSwitch의 `ct_limit_set()`은 zone별 connection-tracking limit 객체를 RCU hlist에서 새 객체로 교체하고 old limit를 `kfree_rcu()`로 회수한다.

Example 3: Handling In-Place Updates
------------------------------------

The system-call auditing code does not update auditing rules in place.  However,
if it did, the reader-writer-locked code to do so might look as follows
(assuming only ``field_count`` is updated, otherwise, the added fields would
need to be filled in)::

        static inline int audit_upd_rule(struct audit_rule *rule,
                                         struct list_head *list,
                                         __u32 newaction,
                                         __u32 newfield_count)
        {
                struct audit_entry *e;
                struct audit_entry *ne;

                write_lock(&auditsc_lock);
                /* Note: audit_filter_mutex held by caller. */
                list_for_each_entry(e, list, list) {
                        if (!audit_compare_rule(rule, &e->rule)) {
                                e->rule.action = newaction;
                                e->rule.field_count = newfield_count;
                                write_unlock(&auditsc_lock);
                                return 0;
                        }
                }
                write_unlock(&auditsc_lock);
                return -EFAULT;                /* No matching rule */
        }

The RCU version creates a copy, updates the copy, then replaces the old
entry with the newly updated entry.  This sequence of actions, allowing
concurrent reads while making a copy to perform an update, is what gives
RCU (*read-copy update*) its name.

The RCU version of audit_upd_rule() is as follows::

        static inline int audit_upd_rule(struct audit_rule *rule,
                                         struct list_head *list,
                                         __u32 newaction,
                                         __u32 newfield_count)
        {
                struct audit_entry *e;
                struct audit_entry *ne;

                list_for_each_entry(e, list, list) {
                        if (!audit_compare_rule(rule, &e->rule)) {
                                ne = kmalloc(sizeof(*entry), GFP_ATOMIC);
                                if (ne == NULL)
                                        return -ENOMEM;
                                audit_copy_rule(&ne->rule, &e->rule);
                                ne->rule.action = newaction;
                                ne->rule.field_count = newfield_count;
                                list_replace_rcu(&e->list, &ne->list);
                                call_rcu(&e->rcu, audit_free_rule);
                                return 0;
                        }
                }
                return -EFAULT;                /* No matching rule */
        }

Again, this assumes that the caller holds ``audit_filter_mutex``.  Normally, the
writer lock would become a spinlock in this sort of code.

The update_lsm_rule() does something very similar, for those who would
prefer to look at real Linux-kernel code.

Another use of this pattern can be found in the openswitch driver's *connection
tracking table* code in ``ct_limit_set()``.  The table holds connection tracking
entries and has a limit on the maximum entries.  There is one such table
per-zone and hence one *limit* per zone.  The zones are mapped to their limits
through a hashtable using an RCU-managed hlist for the hash chains. When a new
limit is set, a new limit object is allocated and ``ct_limit_set()`` is called
to replace the old limit object with the new one using list_replace_rcu().
The old limit object is then freed after a grace period using kfree_rcu().

예제 4: Stale data 거부

System V IPC처럼 stale data를 허용할 수 없는 경로는 RCU만으로 충분하지 않다. `shm_lock()`은 per-entry spinlock 아래 `deleted` flag를 검사하며 삭제된 원소를 없는 것으로 취급한다. Search 함수는 이 lock을 잡은 채 반환해야 caller가 값을 사용하는 동안 삭제와 변경을 막을 수 있다.

예시의 `audit_filter_task()`는 RCU 순회로 후보를 찾은 뒤 `spin_lock(&e->lock)`을 잡고 `e->deleted`를 확인한다. 삭제되지 않았다면 RCU read lock은 풀 수 있지만 per-entry lock은 유지한 채 객체를 반환한다. 이후 caller는 `e->lock`이 잡힌 동안만 객체가 유효하고 값이 stale하지 않다고 믿을 수 있다.

`audit_del_rule()`은 같은 per-entry lock 아래 `list_del_rcu()`와 `e->deleted = 1`을 수행하고 unlock 뒤 `call_rcu()`를 등록한다. In-place update까지 함께 지원하려면 `audit_upd_rule()`이 `list_replace_rcu()` 동안 old와 replacement 양쪽 lock을 모두 다루는 추가 protocol이 필요하다.

Quick Quiz의 답은 search 함수가 반환 전에 entry lock을 풀면 caller가 어차피 stale data를 처리할 수 있기 때문이다. Stale data가 허용된다면 `deleted` flag 자체가 필요 없고, 허용되지 않는다면 반환값을 쓰는 전체 구간에서 lock을 유지해야 한다.

Example 4: Eliminating Stale Data
---------------------------------

The auditing example above tolerates stale data, as do most algorithms
that are tracking external state.  After all, given there is a delay
from the time the external state changes before Linux becomes aware
of the change, and so as noted earlier, a small quantity of additional
RCU-induced staleness is generally not a problem.

However, there are many examples where stale data cannot be tolerated.
One example in the Linux kernel is the System V IPC (see the shm_lock()
function in ipc/shm.c).  This code checks a *deleted* flag under a
per-entry spinlock, and, if the *deleted* flag is set, pretends that the
entry does not exist.  For this to be helpful, the search function must
return holding the per-entry spinlock, as shm_lock() does in fact do.

.. _quick_quiz:

Quick Quiz:
        For the deleted-flag technique to be helpful, why is it necessary
        to hold the per-entry lock while returning from the search function?

:ref:`Answer to Quick Quiz <quick_quiz_answer>`

If the system-call audit module were to ever need to reject stale data, one way
to accomplish this would be to add a ``deleted`` flag and a ``lock`` spinlock to the
``audit_entry`` structure, and modify audit_filter_task() as follows::

        static struct audit_entry *audit_filter_task(struct task_struct *tsk, char **key)
        {
                struct audit_entry *e;
                enum audit_state   state;

                rcu_read_lock();
                list_for_each_entry_rcu(e, &audit_tsklist, list) {
                        if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
                                spin_lock(&e->lock);
                                if (e->deleted) {
                                        spin_unlock(&e->lock);
                                        rcu_read_unlock();
                                        return NULL;
                                }
                                rcu_read_unlock();
                                if (state == AUDIT_STATE_RECORD)
                                        *key = kstrdup(e->rule.filterkey, GFP_ATOMIC);
                                /* As long as e->lock is held, e is valid and
                                 * its value is not stale */
                                return e;
                        }
                }
                rcu_read_unlock();
                return NULL;
        }

The ``audit_del_rule()`` function would need to set the ``deleted`` flag under the
spinlock as follows::

        static inline int audit_del_rule(struct audit_rule *rule,
                                         struct list_head *list)
        {
                struct audit_entry *e;

                /* No need to use the _rcu iterator here, since this
                 * is the only deletion routine. */
                list_for_each_entry(e, list, list) {
                        if (!audit_compare_rule(rule, &e->rule)) {
                                spin_lock(&e->lock);
                                list_del_rcu(&e->list);
                                e->deleted = 1;
                                spin_unlock(&e->lock);
                                call_rcu(&e->rcu, audit_free_rule);
                                return 0;
                        }
                }
                return -EFAULT;                /* No matching rule */
        }

This too assumes that the caller holds ``audit_filter_mutex``.

Note that this example assumes that entries are only added and deleted.
Additional mechanism is required to deal correctly with the update-in-place
performed by audit_upd_rule().  For one thing, audit_upd_rule() would
need to hold the locks of both the old ``audit_entry`` and its replacement
while executing the list_replace_rcu().

예제 5: Stale 객체 건너뛰기

어떤 workload에서는 제거되어 GP 뒤 파괴될 stale 객체를 reader가 일찍 건너뛰면 성능이 좋아진다. Timerfd는 `CLOCK_REALTIME`이 재설정될 때 영향을 받는 timer를 RCU 관리 `cancel_list`에 넣고 대기 process를 예정 시각보다 일찍 깨운다.

`timerfd_setup_cancel()`은 `ctx->cancel_lock` 아래 조건을 확인하고 `might_cancel`을 true로 만든 뒤 전역 `cancel_lock` 아래 `list_add_rcu()`로 등록한다. `timerfd_release()`는 반대 순서로 flag를 false로 바꾸고 `list_del_rcu()`로 제거하며 timer를 취소한 뒤 `kfree_rcu(ctx, rcu)`로 회수한다.

`timerfd_clock_was_set()`은 `rcu_read_lock()` 아래 `list_for_each_entry_rcu()`로 순회하며 `!ctx->might_cancel`인 객체를 즉시 건너뛴다. 유효한 객체는 waitqueue lock 아래 offset과 tick을 갱신하고 `wake_up_locked_poll()`로 깨운다.

순회가 add/remove와 동시에 일어나므로 reader가 이미 list에서 제거된 객체에 도달하는 것은 합법이다. RCU는 객체 메모리가 아직 유효함을 보장하고, `might_cancel` flag가 논리적으로 stale한 객체의 비싼 처리를 피하게 한다.

Example 5: Skipping Stale Objects
---------------------------------

For some use cases, reader performance can be improved by skipping
stale objects during read-side list traversal, where stale objects
are those that will be removed and destroyed after one or more grace
periods. One such example can be found in the timerfd subsystem. When a
``CLOCK_REALTIME`` clock is reprogrammed (for example due to setting
of the system time) then all programmed ``timerfds`` that depend on
this clock get triggered and processes waiting on them are awakened in
advance of their scheduled expiry. To facilitate this, all such timers
are added to an RCU-managed ``cancel_list`` when they are setup in
``timerfd_setup_cancel()``::

        static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags)
        {
                spin_lock(&ctx->cancel_lock);
                if ((ctx->clockid == CLOCK_REALTIME ||
                     ctx->clockid == CLOCK_REALTIME_ALARM) &&
                    (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) {
                        if (!ctx->might_cancel) {
                                ctx->might_cancel = true;
                                spin_lock(&cancel_lock);
                                list_add_rcu(&ctx->clist, &cancel_list);
                                spin_unlock(&cancel_lock);
                        }
                } else {
                        __timerfd_remove_cancel(ctx);
                }
                spin_unlock(&ctx->cancel_lock);
        }

When a timerfd is freed (fd is closed), then the ``might_cancel``
flag of the timerfd object is cleared, the object removed from the
``cancel_list`` and destroyed, as shown in this simplified and inlined
version of timerfd_release()::

        int timerfd_release(struct inode *inode, struct file *file)
        {
                struct timerfd_ctx *ctx = file->private_data;

                spin_lock(&ctx->cancel_lock);
                if (ctx->might_cancel) {
                        ctx->might_cancel = false;
                        spin_lock(&cancel_lock);
                        list_del_rcu(&ctx->clist);
                        spin_unlock(&cancel_lock);
                }
                spin_unlock(&ctx->cancel_lock);

                if (isalarm(ctx))
                        alarm_cancel(&ctx->t.alarm);
                else
                        hrtimer_cancel(&ctx->t.tmr);
                kfree_rcu(ctx, rcu);
                return 0;
        }

If the ``CLOCK_REALTIME`` clock is set, for example by a time server, the
hrtimer framework calls ``timerfd_clock_was_set()`` which walks the
``cancel_list`` and wakes up processes waiting on the timerfd. While iterating
the ``cancel_list``, the ``might_cancel`` flag is consulted to skip stale
objects::

        void timerfd_clock_was_set(void)
        {
                ktime_t moffs = ktime_mono_to_real(0);
                struct timerfd_ctx *ctx;
                unsigned long flags;

                rcu_read_lock();
                list_for_each_entry_rcu(ctx, &cancel_list, clist) {
                        if (!ctx->might_cancel)
                                continue;
                        spin_lock_irqsave(&ctx->wqh.lock, flags);
                        if (ctx->moffs != moffs) {
                                ctx->moffs = KTIME_MAX;
                                ctx->ticks++;
                                wake_up_locked_poll(&ctx->wqh, EPOLLIN);
                        }
                        spin_unlock_irqrestore(&ctx->wqh.lock, flags);
                }
                rcu_read_unlock();
        }

The key point is that because RCU-protected traversal of the
``cancel_list`` happens concurrently with object addition and removal,
sometimes the traversal can access an object that has been removed from
the list. In this example, a flag is used to skip such objects.

요약과 Quick Quiz 답

Stale data를 허용하는 read-mostly list가 RCU에 가장 잘 맞는다. 원소를 추가·삭제하거나 원자적으로 in-place 수정하는 경우가 가장 단순하다. 비원자적인 다중 필드 갱신은 사본을 만들고 갱신한 뒤 원본을 교체한다.

Stale data를 허용할 수 없으면 `deleted` flag와 per-entry spinlock을 결합한다. Search가 lock을 잡은 채 반환하고 caller가 반환값을 다 쓸 때까지 유지해야만 flag 검사와 실제 사용 사이의 삭제 race를 막을 수 있다.

Summary
-------

Read-mostly list-based data structures that can tolerate stale data are
the most amenable to use of RCU.  The simplest case is where entries are
either added or deleted from the data structure (or atomically modified
in place), but non-atomic in-place modifications can be handled by making
a copy, updating the copy, then replacing the original with the copy.
If stale data cannot be tolerated, then a *deleted* flag may be used
in conjunction with a per-entry spinlock in order to allow the search
function to reject newly deleted data.

.. _quick_quiz_answer:

Answer to Quick Quiz:
        For the deleted-flag technique to be helpful, why is it necessary
        to hold the per-entry lock while returning from the search function?

        If the search function drops the per-entry lock before returning,
        then the caller will be processing stale data in any case.  If it
        is really OK to be processing stale data, then you don't need a
        *deleted* flag.  If processing stale data really is a problem,
        then you need to hold the per-entry lock across all of the code
        that uses the value that was returned.

:ref:`Back to Quick Quiz <quick_quiz>`