From: Tyler O. <tyl...@gm...> - 2012-06-19 21:38:50
|
This patch has been submitted as ID 3536420. On Mon, Jun 18, 2012 at 7:30 PM, Tyler Olmstead <tyl...@gm...> wrote: > Here's a patch that fixes the problem. I have only tested it on my > target (arm926ejs), so tests on other architectures would be > worthwhile. Hope this helps, and let me know if I can do anything > else. > > -- Tyler > > diff --git a/agent/mibgroup/ip-mib/data_access/defaultrouter_linux.c > b/agent/mibgroup/ip-mib/data_access/defaultrouter_linux.c > index 702128b..4cb5dd9 100644 > --- a/agent/mibgroup/ip-mib/data_access/defaultrouter_linux.c > +++ b/agent/mibgroup/ip-mib/data_access/defaultrouter_linux.c > @@ -11,7 +11,7 @@ > > #include "ip-mib/ipDefaultRouterTable/ipDefaultRouterTable.h" > > -#include <asm/types.h> > +#include <stdint.h> > #ifdef HAVE_LINUX_RTNETLINK_H > #include <linux/netlink.h> > #include <linux/rtnetlink.h> > @@ -93,9 +93,18 @@ _load(netsnmp_container *container) > netsnmp_defaultrouter_entry *entry; > int nlsk; > struct sockaddr_nl addr; > - unsigned char rcvbuf[RCVBUF_SIZE]; > int rcvbuf_size = RCVBUF_SIZE; > - unsigned char sndbuf[SNDBUF_SIZE]; > + > + /* Buffers must be memory aligned. Message structure internal alignment is > + * maintained by the netlink API. */ > + unsigned char rcvbufmem[RCVBUF_SIZE + sizeof(intmax_t)]; > + unsigned char *rcvbuf = rcvbufmem + > + sizeof(intmax_t) - (((intptr_t)rcvbufmem) % sizeof(intmax_t)); > + > + unsigned char sndbufmem[SNDBUF_SIZE + sizeof(intmax_t)]; > + unsigned char *sndbuf = sndbufmem + > + sizeof(intmax_t) - (((intptr_t)sndbufmem) % sizeof(intmax_t)); > + > struct nlmsghdr *hdr; > struct rtmsg *rthdr; > int count; > > > On Mon, Jun 11, 2012 at 8:46 PM, Magnus Fromreide <ma...@ly...> wrote: >> On Mon, 2012-06-11 at 16:32 -0700, Tyler Olmstead wrote: >>> Hi all, >>> >>> I have cross-compiled net-snmp 5.7.1 for a custom port of Linux 2.6.37 >>> on an armv5tejl core (AM1808). I have encountered some alignment traps >>> in syslog after MIB-walking. >>> >>> According to objdump, most of the traps seem to be triggered by an >>> unaligned access to stack memory in defaultrouter_linux.c:static int >>> _load(netsnmp_container *container). Has anyone else encountered this? >>> Is this a known issue or should I submit a patch? >> >> I have not heard of this before so a patch or enough information to let >> us debug this would be highly appreciated. >> >> /MF >> |