On Fri, 2017-08-25 at 05:58 +0000, Seymour, Shane M wrote: > > From: Bart Van Assche [mailto:Bart.VanAssche@xxxxxxx] > > [ ... ] > > 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.
