The implement of rcu_read_lock is disable preempt and barrier. And the softirq context will not be preempted. So is it necessary to invoke the rcu_read_lock in softirq context. Is the barrier important?
Yes, it is necessary to use rcu_read_lock to access pointers that are under rcu protection, even in softirq context.
As you point out, some implementations (ex: TINY_RCU) of rcu_read_lock and softirqs make it so that there is no risk of corruption even if you don't delimit rcu read-side critical sections with rcu_read_lock. However, that is not a guarantee of the rcu api, only a "hack" because of the specific implementation. This hack could break with a different implementation of rcu (ex: PREEMPT_RCU).
If you wish to treat softirqs as explicit rcu read-side critical sections, you must use the RCU-sched api: Documentation/RCU/whatisRCU.txt
The following section of an article written by the main author of RCU directly addresses your question: Requirements for RCU part 1: the fundamentals - Disabling preemption does not block grace periods
I would add that code which does rcu_dereference outside of rcu_read_lock will trigger lockdep warnings if CONFIG_PROVE_RCU=y.
The rcu_read_lock is to protect some kernel resource being modify simulanteously that causes race condition error.
What a resource must to prevent is: being simultaneously use and modified by two software task/ context.
In Linux, the simultaneously modification may happens in either:
Event in a single core CPU environment, the 1) and 2) may still happens. On task modifying a critical resource, a software IRQ raise, enter the software IRQ context, run IRQ handler and modifying the same resource simultaneously.
It is a good idea to invoke rcu_read_lock in a softirq context for document purposes, so you and other developers know that RCU
protected data is used here.