El implemento de rcu_read_lock es deshabilitar prevención y barrera. Y el contexto softirq no será reemplazado. Entonces, es necesario invocar rcu_read_lock en el contexto softirq. ¿Es importante la barrera?
Sí, es necesario usar rcu_read_lock para acceder a punteros que están bajo protección rcu, incluso en contexto softirq.
Como señala, algunas implementaciones (por ejemplo, TINY_RCU) de rcu_read_lock y softirqs hacen que no haya riesgo de corrupción, incluso si no delimita las secciones críticas del lado de lectura de rcu con rcu_read_lock . Sin embargo, eso no es una garantía de la API de rcu, solo un "truco" debido a la implementación específica. Este truco podría fallar con una implementación diferente de rcu (por ejemplo: PREEMPT_RCU).
Si desea tratar los softirqs como secciones críticas explícitas del lado de lectura de rcu, debe usar la API programada de RCU: Documentation/RCU/whatisRCU.txt
La siguiente sección de un artículo escrito por el autor principal de RCU aborda directamente su pregunta: Requisitos para la parte 1 de RCU: los fundamentos: la desactivación de la preferencia no bloquea los períodos de gracia
Agregaría ese código que hace rcu_dereference fuera de rcu_read_lock activará advertencias de bloqueo si CONFIG_PROVE_RCU=y.
El rcu_read_lock es para proteger algunos recursos del kernel que se modifican de forma simultánea y que causan un error de condición de carrera.
Lo que un recurso debe evitar es: ser utilizado y modificado simultáneamente por dos tareas/contextos de software.
En Linux, la modificación simultánea puede ocurrir en:
El evento en un entorno de CPU de un solo núcleo, el 1) y el 2) aún pueden ocurrir. En la tarea de modificar un recurso crítico, una IRQ de software aumenta, ingresa el contexto de IRQ de software, ejecuta el controlador de IRQ y modifica el mismo recurso simultáneamente.
Es una buena idea invocar rcu_read_lock en un contexto softirq para propósitos de documentos, para que usted y otros desarrolladores sepan que aquí se usan datos protegidos por RCU.