search for: volatile_memcpy

The virtio_ring header file uses the struct device without a forward declaration. Signed-off-by: Shunsuke Mie <mie at igel.co.jp> --- Changes from v2: https://lore.kernel.org/virtualization/20230410074929-mutt-send-email-mst at kernel.org/ - Fix a typo of commit title include/linux/virtio_ring.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/virtio_ring.h

The virtio_ring header file uses the struct device without a forward declaration. Signed-off-by: Shunsuke Mie <mie at igel.co.jp> --- include/linux/virtio_ring.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h index 8b95b69ef694..77a9c2f52919 100644 --- a/include/linux/virtio_ring.h +++ b/include/linux/virtio_ring.h @@ -58,6

...uses, but it behaves intuitively enough that I think it’s desirable. > > As Eli pointed out, that precludes lowering a volatile memcpy into a call the memcpy library function. The usual "memcpy" library function may well use the same overlapping-memory trick, and there is no "volatile_memcpy" libc function which would provide a guarantee of not touching bytes multiple times. Perhaps it's okay to just always emit an inline loop instead of falling back to a memcpy call. In which circumstances does this matter? > But, possibly option 3 would be better. Maybe it's better...

> On Jun 11, 2019, at 6:27 AM, Guillaume Chatelet <gchatelet at google.com> wrote: > > I spent some time reading the C standard <https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf>: > > 5.1.2.3 Program execution > 2. Accessing a volatile object, modifying an object, modifying a file, or calling