Re: [PATCH] powerpc: Use aligned stores in memset

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Tue, 2017-09-12 at 12:30 +0200, Florian Weimer wrote:
> On 08/18/2017 11:10 AM, Florian Weimer wrote:
> > On 08/18/2017 08:51 AM, Rajalakshmi Srinivasaraghavan wrote:
> >>
> >>
> >> On 08/18/2017 11:51 AM, Florian Weimer wrote:
> >>> On 08/18/2017 07:11 AM, Rajalakshmi Srinivasaraghavan wrote:
> >>>>     * sysdeps/powerpc/powerpc64/power8/memset.S: Store byte by byte
> >>>>     for unaligned inputs if size is less than 8.
> >>>
> >>> This makes me rather nervous.  powerpc64le was supposed to have
> >>> reasonable efficient unaligned loads and stores.  GCC happily generates
> >>> them, too.
> >>
> >> This is meant ONLY for caching inhibited accesses.  Caching Inhibited
> >> accesses are required to be Guarded and properly aligned.
> > 
> > The intent is to support memset for such memory regions, right?  This
> > change is insufficient.  You have to fix GCC as well because it will
> > inline memset of unaligned pointers, like this:
> 
> Here's a more complete example:
> 

..snip

> 
> This means that GCC introduced an unaligned store, no matter how memset
> was implemented.
> 
C will do what ever the programmer wants. We can not stop that. 

And in user mode and cache coherent memory this is not a problem as
Adhemerval explained.

So we are not going to degrade the performance of general applications
for a tiny subset of specialized device drivers. Those guy have to know
what they are doing.

But in the library (like libc) that might be called from a user mode
device driver (Xorg for example) and access Cache inhibited memory the
memcpy implementation has to check alignment and size and using the
correct instructions for each case.

That is what we are doing here. 


> I could not find the manual which has the requirement that the mem*
> functions do not use unaligned accesses.  Unless they are worded in a
> very peculiar way, right now, the GCC/glibc combination does not comply
> with a requirement that memset & Co. can be used for device memory access.
> 
> Furthermore, I find it very peculiar that over-reading device memory is
> acceptable.  Some memory-mapped devices behave strangely if memory
> locations are read out of order or multiple times, and the current glibc
> implementation accesses locations which are outside the specified object
> boundaries.
> 
Yes device driver writers have to know what they are doing.

> So I think the implementation constraint on the mem* functions is wrong.
>  It leads to a slower implementation of the mem* function for most of
> userspace which does not access device memory, and even for device
> memory, it is probably not what you want.
> 
We are just trying to make the mem* safe (not segfault or alignment
check) if used correctly. 

The definition of correctly is a bit fluid. I personally disagree with
the Xorg folks but so far they have refused to bend...


> Thanks,
> Florian
>