Displaying 5 results from an estimated 5 matches for "d5a73cadf3fd".
2015 Dec 30
2
[PATCH 08/34] asm-generic: smp_store_mb should use smp_mb
...-#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0)
> +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0)
> #endif
>
> #ifndef smp_mb__before_atomic
>
The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd
("lcoking/barriers, arch: Use smp barriers in smp_store_release()").
I think you can drop your version.
arnd
2015 Dec 30
2
[PATCH 08/34] asm-generic: smp_store_mb should use smp_mb
...-#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0)
> +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0)
> #endif
>
> #ifndef smp_mb__before_atomic
>
The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd
("lcoking/barriers, arch: Use smp barriers in smp_store_release()").
I think you can drop your version.
arnd
2015 Dec 30
0
[PATCH 08/34] asm-generic: smp_store_mb should use smp_mb
...do { WRITE_ONCE(var, value); mb(); } while (0)
> > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0)
> > #endif
> >
> > #ifndef smp_mb__before_atomic
> >
>
> The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd
> ("lcoking/barriers, arch: Use smp barriers in smp_store_release()").
Sorry which tree do you mean exactly?
> I think you can drop your version.
>
> arnd
Will drop mine, thanks.
I kind of dislike that if I just drop it, some arches will temporarily
regress to a slower im...
2015 Dec 30
46
[PATCH 00/34] arch: barrier cleanup + __smp_XXX barriers for virt
This is really trying to cleanup some virt code, as suggested by Peter, who
said
> You could of course go fix that instead of mutilating things into
> sort-of functional state.
This work is needed for virtio, so it's probably easiest to
merge it through my tree - is this fine by everyone?
Arnd, if you agree, could you ack this please?
Note to arch maintainers: please don't
2015 Dec 30
46
[PATCH 00/34] arch: barrier cleanup + __smp_XXX barriers for virt
This is really trying to cleanup some virt code, as suggested by Peter, who
said
> You could of course go fix that instead of mutilating things into
> sort-of functional state.
This work is needed for virtio, so it's probably easiest to
merge it through my tree - is this fine by everyone?
Arnd, if you agree, could you ack this please?
Note to arch maintainers: please don't