On Sat, May 8, 2021 at 1:54 AM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, May 7, 2021 at 3:12 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> >
> > From: Arnd Bergmann <arnd@xxxxxxxx>
> >
> > The get_unaligned()/put_unaligned() implementations are much more complex
> > than necessary, now that all architectures use the same code.
>
> Thanks for doing this, it looks good to me.
>
> I suspect it's still slightly unnecessarily complicated - why is that
> get_unaligned() not just
>
> #define get_unaligned(ptr) \
> __get_unaligned_t(typeof(*__ptr), __ptr)
>
> Because I'm not seeing the reason for doing that "__auto_type __ptr"
> thing - the argument to a "typeof()" isn't actually evaluated.
Both versions are equally correct, I picked the __auto_type version
because this tends to produce smaller preprocessor output when you have
multiple layers of nested macros with 'ptr' expanding to something
complicated, and the get_unaligned() itself being expanded multiple
times again.
When I recently experimented with possible changes to cmpxchg() and
get_user(), it had a measurable impact on compile time with clang on
those macros.
get_unaligned() doesn't appear to be used much in nested macros
at all, so it probably won't actually help here, and I can just do the
simpler version instead.
I forgot to mention in the changelog that this version does not actually
require the argument to be a scalar, not sure if this is something
we want or not. It does allow developers to write something like
__be32 get_ip_saddr(struct sk_buff *skb)
{
struct iphdr *iph = ip_hdr(skb);
return get_unaligned(iph).saddr;
}
and get the expected result. While this seems handy, it also makes it
harder to change the macro back to one that only works on scalars
after such usage becomes widespread.
Arnd
