[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191218091906.cmzgqnwyekak5dzv@gondor.apana.org.au>
Date: Wed, 18 Dec 2019 17:19:07 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Will Deacon <will@...nel.org>
Cc: mst@...hat.com, jasowang@...hat.com,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, paulmck@...nel.org,
peterz@...radead.org, stern@...land.harvard.edu
Subject: Re: read_barrier_depends() usage in vhost.c
Will Deacon <will@...nel.org> wrote:
>
>> --->8
>>
>> // drivers/vhost/vhost.c
>> static int get_indirect(struct vhost_virtqueue *vq,
>> struct iovec iov[], unsigned int iov_size,
>> unsigned int *out_num, unsigned int *in_num,
>> struct vhost_log *log, unsigned int *log_num,
>> struct vring_desc *indirect)
>> {
>> [...]
>>
>> /* We will use the result as an address to read from, so most
>> * architectures only need a compiler barrier here. */
>> read_barrier_depends();
>>
>> --->8
>>
>> Unfortunately, although the barrier is commented (hurrah!), it's not
>> particularly enlightening about the accesses making up the dependency
>> chain, and I don't understand the supposed need for a compiler barrier
>> either (read_barrier_depends() doesn't generally provide this).
>>
>> Does anybody know which accesses are being ordered here? Usually you'd need
>> a READ_ONCE()/rcu_dereference() beginning the chain, but I haven't managed
>> to find one...
I think what it's trying to separate is using indirect->addr as a
base and then reading from that through copy_from_iter.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists