Displaying 3 results from an estimated 3 matches for "gup_get_ptr".
2016 Nov 25
0
[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
...rikes me as surprising. Is there some mutual exclusion that
> prevents writes from occuring wherever a READ_ONCE() happens to a PTE?
>
> Otherwise, how is tearing not a problem? Does it have some pattern like
> the lockref cmpxchg?
On x86 PAE we play silly games, see arch/x86/mm/gup.c:gup_get_ptr().
Those two loads really should be READ_ONCE()/LOAD_SINGLE().
2016 Nov 25
5
[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
On 11/25/2016 05:17 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote:
>> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote:
>
>>> What are use cases for such primitive that won't be OK with "read once
>>> _and_ atomically"?
>>
>> I have none to hand.
>
> Whatever triggers the
2016 Nov 25
5
[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
On 11/25/2016 05:17 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote:
>> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote:
>
>>> What are use cases for such primitive that won't be OK with "read once
>>> _and_ atomically"?
>>
>> I have none to hand.
>
> Whatever triggers the