On Wed, 2018-03-14 at 21:08 +0100, Peter Zijlstra wrote:
> On Wed, Mar 14, 2018 at 08:05:30PM +, Bart Van Assche wrote:
> > Can you clarify this further? From :
> >
> > static inline void synchronize_rcu(void)
> > {
> > synchronize_sched();
> > }
>
> You'll find that is for !CONFIG_PREEMP
On Wed, Mar 14, 2018 at 08:05:30PM +, Bart Van Assche wrote:
> Can you clarify this further? From :
>
> static inline void synchronize_rcu(void)
> {
> synchronize_sched();
> }
You'll find that is for !CONFIG_PREEMPT_RCU.
On Wed, 2018-03-14 at 11:46 -0700, t...@kernel.org wrote:
> > that are ordered with an RCU read lock (https://lwn.net/Articles/573497/).
> > See
> > also the following comment in scsi_device_quiesce():
> >
> > /*
> > * Ensure that the effect of blk_set_preempt_only() will be visible
> >
Hello, Bart.
On Tue, Mar 06, 2018 at 05:52:50PM +, Bart Van Assche wrote:
> I think the rcu_read_lock() and rcu_read_unlock() are really necessary in this
> code. In the LWN article "The RCU-barrier menagerie" it is explained that RCU
> can be used to enforce write ordering globally if the cod
On Tue, 2018-03-06 at 09:33 -0800, Tejun Heo wrote:
> 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work
> reliably") added rcu_read_[un]lock_sched() to blk_queue_enter() along
> with other changes but it doesn't seem to be doing anything.
>
> blk_queue_enter() is called with @q - the p
3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work
reliably") added rcu_read_[un]lock_sched() to blk_queue_enter() along
with other changes but it doesn't seem to be doing anything.
blk_queue_enter() is called with @q - the pointer to the target
request_queue, so the caller obviously ha
6 matches
Mail list logo
