Re: [PATCH 07/19] Fix RCU handling of scsi_device.vpd_pg8[03]

[Bart Van Assche <Bart.VanAssche@wdc.com>]

On Fri, 2017-08-25 at 05:58 +0000, Seymour, Shane M wrote:
> > From: Bart Van Assche [mailto:Bart.VanAssche@wdc.com]
> > [ ... ]
> > My understanding of the SCSI VPD code is as follows:
> > * rcu_read_lock() / rcu_read_unlock() is used to prevent that another thread
> >   updates a VPD buffer while it is being read.
> 
> My understanding is that it doesn't do that - you can update an RCU pointer
> with rcu_assign_pointer() after someone has called rcu_read_lock() and before
> they call rcu_read_unlock(). 

Hello Shane,

You have either misinterpret my statement or the SCSI VPD handling code. If you
have a look at the SCSI VPD handling code you will see that an rcu_read_lock() /
rcu_read_unlock() pair is sufficient to prevent that the VPD buffer rcu_dereference()
points at is being modified as long as the RCU read lock is held, at least if
rcu_dereference() is only called once. The update side namely does not modify the
VPD buffer after the pointer to that buffer has been published.

> It is possible I may be being too picky (it's a personal failing sometimes)
> but is it really that a large overhead to free the RCU pointers in a way that
> RCU pointers are expected to work even if the pointers shouldn't be accessible
> to anything?

Switching to kfree_rcu() requires more changes because all unsigned char pointers
to VPD data have to be converted into pointers to a structure that contains the
VPD data and the RCU head. Anyway, I will convert the kfree() calls to RCU pointers
into kfree_rcu() pointers.

Bart.