Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)

On Tue, Apr 23, 2019 at 12:16 PM Szabolcs Nagy wrote: > > On 18/04/2019 19:17, Mathieu Desnoyers wrote: > > - On Apr 18, 2019, at 1:37 PM, Szabolcs Nagy szabolcs.n...@arm.com > > wrote: > >> you have to add a documentation comment somewhere > >> explaining if RSEQ_SIG is the value that's

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Sun, Aug 5, 2018 at 10:36 PM, Pavel Machek wrote: > Hi! > >> > I tried to use a PCIe graphics card on the MacchiatoBIN board and I hit a >> > strange problem. >> > >> > When I use the links browser in graphics mode on the framebuffer, I get >> > occasional pixel corruption. Links does memcpy,

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Sun, Aug 5, 2018 at 10:36 PM, Pavel Machek wrote: > Hi! > >> > I tried to use a PCIe graphics card on the MacchiatoBIN board and I hit a >> > strange problem. >> > >> > When I use the links browser in graphics mode on the framebuffer, I get >> > occasional pixel corruption. Links does memcpy,

Re: framebuffer corruption due to overlapping stp instructions on arm64

< snip> > I guess the semantics of a framebuffer are not strictly defined, but > the current reality is that it is expected to have memory semantics > (by Linux/glibc) > > Matt is saying fundamental properties of the underlying interconnects > (AMBA) make that impossible on ARM, but I'd like to

Re: framebuffer corruption due to overlapping stp instructions on arm64

< snip> > I guess the semantics of a framebuffer are not strictly defined, but > the current reality is that it is expected to have memory semantics > (by Linux/glibc) > > Matt is saying fundamental properties of the underlying interconnects > (AMBA) make that impossible on ARM, but I'd like to

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Fri, Aug 3, 2018 at 8:53 AM, Florian Weimer wrote: > On 08/03/2018 09:11 AM, Andrew Pinski wrote: >> >> Yes fix Links not to use memcpy on the framebuffer. >> It is undefined behavior to use device memory with memcpy. > > > Some (de facto) ABIs require that it is supported, though. For

Re: framebuffer corruption due to overlapping stp instructions on arm64

On Fri, Aug 3, 2018 at 8:53 AM, Florian Weimer wrote: > On 08/03/2018 09:11 AM, Andrew Pinski wrote: >> >> Yes fix Links not to use memcpy on the framebuffer. >> It is undefined behavior to use device memory with memcpy. > > > Some (de facto) ABIs require that it is supported, though. For

Re: New assembler warnings with binutils 2.29

On Mon, Aug 14, 2017 at 11:34:45AM +0100, Catalin Marinas wrote: > > > > Any attempts to realias these to the correct meaning as per the AAPCS > > continues to work from my limited testing of a prototype patch so far. > > This would be great. Thanks Ramana! I've submitted the patch upstream and

Re: New assembler warnings with binutils 2.29

On Mon, Aug 14, 2017 at 11:34:45AM +0100, Catalin Marinas wrote: > > > > Any attempts to realias these to the correct meaning as per the AAPCS > > continues to work from my limited testing of a prototype patch so far. > > This would be great. Thanks Ramana! I've submitted the patch upstream and

Re: New assembler warnings with binutils 2.29

On Mon, Aug 14, 2017 at 09:59:02AM +0100, Catalin Marinas wrote: On Fri, Aug 11, 2017 at 10:26:06AM +0100, Ard Biesheuvel wrote: > On 11 August 2017 at 10:22, Catalin Marinas wrote: > > On Thu, Aug 10, 2017 at 01:13:22PM -0700, Laura Abbott wrote: > >> Fedora rawhide

Re: New assembler warnings with binutils 2.29

On Mon, Aug 14, 2017 at 09:59:02AM +0100, Catalin Marinas wrote: On Fri, Aug 11, 2017 at 10:26:06AM +0100, Ard Biesheuvel wrote: > On 11 August 2017 at 10:22, Catalin Marinas wrote: > > On Thu, Aug 10, 2017 at 01:13:22PM -0700, Laura Abbott wrote: > >> Fedora rawhide recently upgraded to

Re: Compilers and RCU readers: Once more unto the breach!

On 20/05/15 15:03, Paul E. McKenney wrote: On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote: On 20/05/15 14:37, David Howells wrote: Paul E. McKenney wrote: I was thinking of "y" as a simple variable, but if it is something more complex, then the compile

Re: Compilers and RCU readers: Once more unto the breach!

On 20/05/15 14:37, David Howells wrote: Paul E. McKenney wrote: I was thinking of "y" as a simple variable, but if it is something more complex, then the compiler could do this, right? char *x; y; x = z; Yeah. I presume it has to maintain the ordering, though.

Re: Compilers and RCU readers: Once more unto the breach!

On 20/05/15 15:03, Paul E. McKenney wrote: On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote: On 20/05/15 14:37, David Howells wrote: Paul E. McKenney paul...@linux.vnet.ibm.com wrote: I was thinking of y as a simple variable, but if it is something more complex

Re: Compilers and RCU readers: Once more unto the breach!

On 20/05/15 14:37, David Howells wrote: Paul E. McKenney paul...@linux.vnet.ibm.com wrote: I was thinking of y as a simple variable, but if it is something more complex, then the compiler could do this, right? char *x; y; x = z; Yeah. I presume it has to maintain

Re: [RFC][PATCH 0/5] arch: atomic rework

On 02/06/14 18:25, David Howells wrote: Is it worth considering a move towards using C11 atomics and barriers and compiler intrinsics inside the kernel? The compiler _ought_ to be able to do these. It sounds interesting to me, if we can make it work properly and reliably. +

Re: [RFC][PATCH 0/5] arch: atomic rework

On 02/06/14 18:25, David Howells wrote: Is it worth considering a move towards using C11 atomics and barriers and compiler intrinsics inside the kernel? The compiler _ought_ to be able to do these. It sounds interesting to me, if we can make it work properly and reliably. +