Dmitry Safonov <dima@xxxxxxxxxx> wrote: > On Sat, 2018-07-28 at 14:18 -0700, David Miller wrote: > > From: Dmitry Safonov <dima@xxxxxxxxxx> > > Date: Sat, 28 Jul 2018 17:26:55 +0100 > > > > > Well, I think, I'll rework my patches set according to critics and > > > separate compat xfrm layer. I've already a selftest to check that > > 32/64 > > > bit xfrm works - so the most time-taking part is done. > > > > The way you've done the compat structures using __packed is only > > going > > to work on x86, just FYI. > > Thanks for pointing, so I'll probably cover it under something like > HAS_COMPAT_XFRM. > (if there isn't any better idea). You can do that, I suspect you can use CONFIG_COMPAT_FOR_U64_ALIGNMENT as AFAICR the only reason for the compat problem is different alignment requirements of 64bit integer types in the structs, not e.g. due to "long" size differences. Instead of __packed, you can use the "compat" data types, e.g. compat_u64 instead of u64: struct compat_xfrm_lifetime_cur { compat_u64 bytes, packets, add_time, use_time; }; /* same size on i386, but only 4 byte alignment required even on x86_64*/ You might be able to reuse https://git.breakpoint.cc/cgit/fw/net-next.git/commit/?h=xfrm_config_compat_07&id=f64430e6d9e297f3990f485a4832e273751b9869 in your patch set. I can try to submit the first few patches (which are not related to compat, they just add const qualifiers) for inclusion later this week. -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html