Message ID | 20230531104233.50645-1-dqfext@gmail.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [net] neighbour: fix unaligned access to pneigh_entry | expand |
On Wed, 31 May 2023 18:42:33 +0800 Qingfang DENG wrote: > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > u8 key[]; > +#else > + u8 key[] __aligned(4); > +#endif I'd appreciate a second opinion, but to me it's very unlikely we'd save any memory even with efficient aligned access here. No reasonably key will fit into 3 bytes, right? So we can as well avoid the ifdef and make the key[] always aligned. Or preferably, if it doesn't cause compilation issues, make the type of the key u32?
On Wed, May 31, 2023 at 8:16 PM Jakub Kicinski <kuba@kernel.org> wrote: > > On Wed, 31 May 2023 18:42:33 +0800 Qingfang DENG wrote: > > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > > u8 key[]; > > +#else > > + u8 key[] __aligned(4); > > +#endif > > I'd appreciate a second opinion, but to me it's very unlikely we'd save > any memory even with efficient aligned access here. No reasonably key > will fit into 3 bytes, right? So we can as well avoid the ifdef and > make the key[] always aligned. Or preferably, if it doesn't cause > compilation issues, make the type of the key u32? Same feeling, we could avoid the CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS ifdef.
diff --git a/include/net/neighbour.h b/include/net/neighbour.h index 3fa5774bddac..c0195ed9d111 100644 --- a/include/net/neighbour.h +++ b/include/net/neighbour.h @@ -180,7 +180,11 @@ struct pneigh_entry { netdevice_tracker dev_tracker; u32 flags; u8 protocol; +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS u8 key[]; +#else + u8 key[] __aligned(4); +#endif }; /*