Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1730880 > unrolled thread

Re: [PATCH v3 11/13] xen/pvcalls: implement poll command

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 11/13] xen/pvcalls: implement poll command Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-09-12 16:20 +0200
    Re: [PATCH v3 11/13] xen/pvcalls: implement poll command Stefano Stabellini <sstabellini@kernel.org> - 2017-09-13 00:20 +0200
      Re: [PATCH v3 11/13] xen/pvcalls: implement poll command Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-09-13 01:10 +0200
        Re: [PATCH v3 11/13] xen/pvcalls: implement poll command Stefano Stabellini <sstabellini@kernel.org> - 2017-09-13 01:20 +0200
        Re: [PATCH v3 11/13] xen/pvcalls: implement poll command Stefano Stabellini <sstabellini@kernel.org> - 2017-09-13 01:20 +0200

#1730880 — Re: [PATCH v3 11/13] xen/pvcalls: implement poll command

>>> +
>>> +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?

-boris

[toc] | [next] | [standalone]

#1731266

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.

[toc] | [prev] | [next] | [standalone]

#1731276

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.

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.

-boris

[toc] | [prev] | [next] | [standalone]

#1731278

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.

[toc] | [prev] | [next] | [standalone]

#1731279

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web