Date: Wed, 10 May 2017 20:47:33 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 189219] [dummynet] [patch] using dummynet on sparc64 and configuring a pipe is an insta-panic Message-ID: <bug-189219-2472-IQeNhgkjPt@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-189219-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-189219-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D189219 --- Comment #11 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Wed May 10 20:46:59 UTC 2017 New revision: 318155 URL: https://svnweb.freebsd.org/changeset/base/318155 Log: MFC: r311817 In dummynet(4), random chunks of memory are casted to struct dn_*, potentially leading to fatal unaligned accesses on architectures with strict alignment requirements. This change fixes dummynet(4) as far as accesses to 64-bit members of struct dn_* are concerned, tripping up on sparc64 with accesses to 32-bit members happening to be correctly aligned there. In other words, this only fixes the tip of the iceberg; larger parts of dummynet(4) still need to be rewritten in order to properly work on all of !x86. In principle, considering the amount of code in dummynet(4) that needs this erroneous pattern corrected, an acceptable workaround would be to declare all struct dn_* packed, forcing compilers to do byte-accesses as a side-effect. However, given that the structs in question aren't laid out well either, this would break ABI/KBI. While at it, replace all existing bcopy(9) calls with memcpy(9) for performance reasons, as there is no need to check for overlap in these cases. PR: 189219 Changes: _U stable/10/ stable/10/sys/netpfil/ipfw/ip_dummynet.c --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-189219-2472-IQeNhgkjPt>