lkml.org 
[lkml]   [2017]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 11/13] xen/pvcalls: implement poll command
    On Tue, 12 Sep 2017, Stefano Stabellini wrote:
    > On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
    > > On 09/12/2017 06:17 PM, Stefano Stabellini wrote:
    > > > On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
    > > >>>>> +
    > > >>>>> +unsigned int pvcalls_front_poll(struct file *file, struct socket *sock,
    > > >>>>> + poll_table *wait)
    > > >>>>> +{
    > > >>>>> + struct pvcalls_bedata *bedata;
    > > >>>>> + struct sock_mapping *map;
    > > >>>>> +
    > > >>>>> + if (!pvcalls_front_dev)
    > > >>>>> + return POLLNVAL;
    > > >>>>> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
    > > >>>>> +
    > > >>>>> + map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
    > > >>>> I just noticed this --- why is it READ_ONCE? Are you concerned that
    > > >>>> sk_send_head may change?
    > > >>> No, but I wanted to avoid partial reads. A caller could call
    > > >>> pvcalls_front_accept and pvcalls_front_poll on newsock almost at the
    > > >>> same time (it is probably not the correct way to use the API), I wanted
    > > >>> to make sure that "map" is either read correctly, or not read at all.
    > > >> How can you have a partial read on a pointer?
    > > > I don't think that the compiler makes any promises on translating a
    > > > pointer read into a single read instruction. Of couse, I expect gcc to
    > > > actually do it without any need for READ/WRITE_ONCE.
    > >
    > > READ_ONCE() only guarantees ordering but not atomicity. It resolves (for
    > > 64-bit pointers) to
    > >
    > > case 8: *(__u64 *)res = *(volatile __u64 *)p; break;
    > >
    > > so if compiler was breaking accesses into two then nothing would have
    > > prevented it from breaking them here (I don't think volatile declaration
    > > would affect this). Moreover, for sizes >8 bytes READ_ONCE() is
    > > __builtin_memcpy() which is definitely not atomic.
    > >
    > > So you can't rely on READ_ONCE being atomic from that perspective.
    >
    > I thought that READ_ONCE guaranteed atomicity for sizes less or equal to
    > the machine word size. It doesn't make any atomicity guarantees for
    > sizes >8 bytes.
    >
    >
    > > OTOH, I am pretty sure pointer accesses are guaranteed to be atomic. For
    > > example, atomic64_read() is READ_ONCE(u64), which (per above) is
    > > dereferencing of a 64-bit pointer in C.
    >
    > I am happy to remove the READ_ONCE and WRITE_ONCE, if we all think it is
    > safe.

    Looking at other code in Linux, it seems that they are making this
    assumption in many places. I'll remove READ/WRITE_ONCE.

    \
     
     \ /
      Last update: 2017-09-13 01:20    [W:7.671 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site