linux-kernel - Re: read_barrier_depends() usage in vhost.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9de4e853-3230-bd2c-c109-07d41b4ff6d6@redhat.com>
Date:   Fri, 20 Dec 2019 11:40:16 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        Will Deacon <will@...nel.org>
Cc:     mst@...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


On 2019/12/18 下午5:19, Herbert Xu wrote:
> 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,


The question is that there's a smp_rmb() before in vhost_get_vq_desc(), 
isn't it sufficient to do this?

Thanks