Bug#757037: liblzop alignment problem
On 11/12/2014 01:20 AM, Simon McVittie wrote:
Control: severity 757037 grave
Control: tags 757037 + patch
I'm bumping this bug up to grave severity, because it seems it makes
this liblzo2 version entirely useless on a fairly common armel CPU (my armel
has a Marvell Kirkwood armv5tel, as used in the SheevaPlug and its
derivatives) in the default Debian configuration. It also makes liblzo2
FTBFS on such machines, because the tests fail.
Thanks.
On Sun, 09 Nov 2014 at 21:26:37 +0100, Marc Kleine-Budde wrote:
So from my point of view switching unaligned access
off in libzop with -DLZO_CFG_NO_UNALIGNED should be done on at least
ARMel. Are there other alignment sensitive platforms in debian?
(Please Cc me, I am not subscribed to this bug. Non-maintainer contributors
to Debian bugs usually aren't.)
Done
I think alignment-sensitivity is the common case, and quietly accepting
unaligned accesses (and giving the correct answer!) as is done on x86 is the
exceptional case...
Looking at the linux Kernel, there we have the
HAVE_EFFICIENT_UNALIGNED_ACCESS kconfig symbol. When an unaligned access
occurs in the kernel it's always fixed up. So the bad code will run, but
not as fast as it could.
arch/arm/Kconfig:44: select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 ||
CPU_V6K || CPU_V7) MMU
Translated to debian this mean:
armel - unaligned access will silently fail on = ARMv5
(unless configured otherwise in /proc/cpu/alignment)
will work if run on = ARMv6, e.g. Raspberry Pi, Beagle Bone
But usually you would use armhf on such a system.
armhf - ok with unaligned access
arch/arm64/Kconfig:50:select HAVE_EFFICIENT_UNALIGNED_ACCESS
arm64 - ok
arch/powerpc/Kconfig:103: select HAVE_EFFICIENT_UNALIGNED_ACCESS if
!CPU_LITTLE_ENDIAN
ppc, ppc64 - ok
ppcel - not ok
arch/x86/Kconfig:64: select HAVE_EFFICIENT_UNALIGNED_ACCESS
i386, amd64 - ok
According to http://www.ibm.com/developerworks/library/pa-dalign/
the mips family are alignment-sensitive, and so is powerpc sometimes,
although it might do automatic fixup.
According to https://bugs.launchpad.net/ubuntu/+source/zmqpp/+bug/1256886
Ubuntu armhf is alignment-sensitive (presumably Debian armhf is the same?)
The just starting lzop testcase works on my ARMv7, current debian
testing, both with armhf and armel root filesystem. /proc/cpu/alignment
shows now Problems with the user space.
I've also seen references to sparc not liking unaligned accesses.
s390 can do unaligned accesses fine according to
http://lxr.free-electrons.com/source/include/asm-s390/unaligned.h?v=2.2.26,
but realistically, who's going to test that? Not me :-)
I think the safest thing would be to use -DLZO_CFG_NO_UNALIGNED
on all Debian architectures except i386, amd64, and maybe the powerpc
family if someone can test those. I attach a patch that restricts
use of unaligned accesses to i386 and amd64 CPUs (any kernel);
it's easy to extend to whitelist other CPUs where unaligned
accesses are OK.
liblzo2 does actually try to avoid using unsafe unaligned accesses
by using a structure
typedef struct lzo_memops_TU2_struct { unsigned char a[2]; }
lzo_memops_TU2;
and only doing a type-punning assignment similar to[1]
*(lzo_memops_TU2 *) (void *) dest = *(const lzo_memops_TU2 *) (void *)
src;
Which AFAIK should boil down to some kind of memcpy() with compile time
constant length.
if that structure has required alignment 1... but it seems (recent?) gcc
might be optimizing that into a single 2-byte operation which requires
alignment. This might be a gcc bug, but then, I suspect this might be
a violation of strict aliasing (hence undefined behaviour) if you get all
language-lawyer about it. Pessimistically assuming that we have to access
byte-by-byte on miscellaneous architectures seems both quicker and safer
than working out whether this is the compiler's fault.
tl;dr: the attached patch works, I would suggest using it.
Regards,
S
[1] Actually it's a little more complicated than that; there are another
couple of layers of typedef between the source code and the reality
regards,
Marc
signature.asc
Description: OpenPGP digital signature
Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)
On 10/09/2013 02:45 PM, Thomas Preud'homme wrote:
I've deleted /var/spool/dspam/data and let dspam deliver a mail, that
produces this backtrace:
#0 0xb6f118ec in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
No symbol table info available.
#1 0xb6a5acf4 in __aeabi_ldiv0 () from
/usr/lib/arm-linux-gnueabi/dspam/libhash_drv.so No symbol table info
available.
#2 0xb6a59b9c in _hash_drv_seek (map=map@entry=0xb57073d8,
offset=offset@entry=16147856, hashcode=optimized out,
flags=flags@entry=1) at hash_drv.c:1194 header = optimized out
rec = optimized out
fpos = optimized out
iterations = 0
Ok, this bug was very likely introduced with the patch I made to handle
corrupted css file. Unfortunetely I don't have the time to fix the patch now.
Yes the bug was introduced between 3.10.2+dfsg-9 and 3.10.2+dfsg-10. As
I'm running -9 without problems.
Although the incremental diff from -9 to -10 doesn't look suspicious at
the first glance:
diff --git a/src/hash_drv.c b/src/hash_drv.c
index 349b491..daae2e7 100644
--- a/src/hash_drv.c
+++ b/src/hash_drv.c
@@ -1187,32 +1187,36 @@ unsigned long _hash_drv_seek(
unsigned long fpos;
unsigned long iterations = 0;
if (offset = map-file_len)
return 0;
fpos = sizeof(struct _hash_drv_header) +
((hashcode % header-hash_rec_max) * sizeof(struct
_hash_drv_spam_record));
According to the backtrace's line number the diff-by-zero should happen
here. But the modulo, which is IIRC implemented on ARM as
divide/multiply/difference, was here all the time.
Was there a compiler change? Maybe some new optimisations brakes the code.
rec = (void *)((unsigned long) map-addr + offset + fpos);
- while(rec-hashcode != hashcode /* Match token */
-rec-hashcode != 0/* Insert on empty */
-iterations map-max_seek) /* Max Iterations */
+ while(rec + sizeof(*rec) = map-file_len /* not end of file */
+rec-hashcode != hashcode /* Match token */
+rec-hashcode != 0/* Insert on empty */
+iterations map-max_seek) /* Max Iterations */
{
iterations++;
fpos += sizeof(struct _hash_drv_spam_record);
if (fpos = (header-hash_rec_max * sizeof(struct
_hash_drv_spam_record)))
fpos = sizeof(struct _hash_drv_header);
rec = (void *)((unsigned long) map-addr + offset + fpos);
}
+ if (rec + sizeof(*rec) map-file_len)
+return 0;
+
if (rec-hashcode == hashcode)
return fpos;
if (rec-hashcode == 0 (flags HSEEK_INSERT))
return fpos;
return 0;
}
I'm very busy for a few weeks but I'll try to take a look at it as soon as
possible.
Thanks,
Marc
signature.asc
Description: OpenPGP digital signature
Bug#722484: libdspam7-drv-hash segfaults since 3.10.2+dfsg-10
Hello, I'm Debian testing armel, and just upgraded from 3.10.2+dfsg-9 to 3.10.2+dfsg-10. My dspam crashed reproducible during the mmap of the css file, even if I delete the css and dspam creates a new one. I'll provide a backtrace this evening. Marc signature.asc Description: OpenPGP digital signature
Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)
Hello
I've deleted /var/spool/dspam/data and let dspam deliver a mail, that
produces this backtrace:
#0 0xb6f118ec in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
No symbol table info available.
#1 0xb6a5acf4 in __aeabi_ldiv0 () from
/usr/lib/arm-linux-gnueabi/dspam/libhash_drv.so
No symbol table info available.
#2 0xb6a59b9c in _hash_drv_seek (map=map@entry=0xb57073d8,
offset=offset@entry=16147856, hashcode=optimized out, flags=flags@entry=1) at
hash_drv.c:1194
header = optimized out
rec = optimized out
fpos = optimized out
iterations = 0
#3 0xb6a59cc8 in _hash_drv_set_spamrecord (map=0xb57073d8,
wrec=wrec@entry=0xb60fa1a8, map_offset=0) at hash_drv.c:1239
rec = optimized out
offset = 16147856
extents = optimized out
last_extent_size = optimized out
rec_offset = 0
#4 0xb6a59df4 in _ds_set_spamrecord (CTX=optimized out, token=optimized
out, stat=0xb5733f08) at hash_drv.c:785
rec = {hashcode = 6670524186553311232, nonspam = 1, spam = 0}
s = optimized out
#5 0xb6f336cc in _ds_set_spamrecord (CTX=0xb57007a8, token=optimized out,
stat=0xb5733f08) at storage_driver.c:133
ptr = optimized out
#6 0xb6a59ea4 in _ds_setall_spamrecords (CTX=0xb57007a8, diction=0xb570d4d0)
at hash_drv.c:736
ds_term = 0xb5733ef8
ds_c = 0xb573d9e8
ret = -2
#7 0xb6f3352c in _ds_setall_spamrecords (CTX=CTX@entry=0xb57007a8,
diction=diction@entry=0xb570d4d0) at storage_driver.c:94
ptr = optimized out
#8 0xb6f292c8 in _ds_operate (CTX=CTX@entry=0xb57007a8, headers=optimized
out, body=optimized out) at libdspam.c:1099
errcode = 0
diction = 0xb570d4d0
ds_term = 0x0
ds_c = optimized out
heap_sort = 0xefda004f
whitelist_token = 11166914970
do_whitelist = optimized out
heap_sort_items = 27
#9 0xb6f29b64 in dspam_process (CTX=CTX@entry=0xb57007a8,
message=0xb5704b18 Received: from metis.ext.pengutronix.de
(metis.ext.pengutronix.de [IPv6:2001:6f8:1178:4:290:27ff:fe1d:cc33])\n\t(using
TLSv1 with ci
pher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby...)
at libdspam.c:573
tp1 = {tv_sec = 1381179424, tv_usec = 996780}
tp2 = {tv_sec = 160472, tv_usec = -1250944800}
tzp = {tz_minuteswest = -120, tz_dsttime = 0}
header = 0xb570ce68
body = 0xb5708400
spam_result = 0
is_toe = optimized out
is_undertrain = 0
retcode = 0
#10 0x00012510 in process_message (ATX=ATX@entry=0xb57009f0,
message=message@entry=0xb5700688, username=username@entry=0xb57018c0
m...@kleine-budde.de,
result_string=0x0, result_string@entry=0xb60fd3f4) at dspam.c:541
CTX = 0xb57007a8
components = optimized out
copyback = optimized out
have_signature = optimized out
result = optimized out
i = optimized out
internally_canned = 0
original_username = 0x0
#11 0x00013268 in process_users (ATX=ATX@entry=0xb57009f0, message=0x0,
message@entry=0xb5701960) at dspam.c:1895
result_string = 0x0
result = optimized out
s = {st_dev = 0, __pad1 = 0, st_ino = 0, st_mode = 0, st_nlink = 0,
st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 0, st_blksize = 0,
st_blocks = 0, st_atim = {tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec
= 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, __unused4 = 0,
__unused5 = 0}
username = 0xb57018c0 m...@kleine-budde.de
recipient = m...@kleine-budde.de, '\000' repeats 235 times
filename = /var/spool/dspam/opt-out/kleine-budde.de/marc.nodspam,
'\000' repeats 2211 times...
optin = 0
optout = optimized out
i = optimized out
have_rcpts = optimized out
return_code = -1250949480
retcode = optimized out
node_nt = 0xb57018e0
node_rcpt = 0x0
c_nt = {iter_index = 0xb57018e0}
c_rcpt = {iter_index = 0x0}
parse_message = 0xb5700688
presult = 0x0
plus = optimized out
atsign = optimized out
mailbox = '\000' repeats 255 times
fout = 0x
#12 0x000164ac in process_connection (ptr=0x1b32e58) at daemon.c:738
processmode = '\000' repeats 255 times
server_ident = optimized out
TTX = 0x1b32e58
ATX = 0xb57009f0
input = optimized out
cmdline = 0xb5701938 DATA\r\n
token = optimized out
ptrptr = optimized out
message = 0xb5701960
parms = optimized out
p = optimized out
i = 8
locked = 8
invalid = optimized out
server_mode = 1
argv = {0x1cb00 dspam, 0xb5701848 --deliver=innocent,spam,
0xb5701860 -d, 0xb5701863 %u, 0x0 repeats 60 times}
buf = 250 OK\000AM LMTP 3.10.2 Ready, '\000' repeats 996 times
tries = 0
argc = optimized out
fd = 0x0
regards,
Bug#636531: linux-image-3.0.0-1-kirkwood: NULL pointer deref in rt2800usb_get_txwi
Package: linux-2.6 Version: 3.0.0-1 Severity: critical Tags: upstream Justification: breaks the whole system Hello, I'm running a Ralink RT2870 USB Wireless NIC on a sheeva plug in accesspoint mode. The wireless network is bridged to the internal ethernet port. linux-image and ralink firmware should be latest and greatest. After some hours of operation the kernel oopes, see below. cheers, Marc [frogger@salsvatn:~]$ brctl show bridge name bridge id STP enabled interfaces br-bs-lan 8000.001ee5e2b77c no lan wlan0 [frogger@salsvatn:~]$ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870] [frogger@salsvatn:~]$ sudo cat /etc/hostapd/hostapd.conf interface=wlan0 bridge=br-bs-lan driver=nl80211 logger_syslog=-1 logger_syslog_level=3 logger_stdout=-1 logger_stdout_level=3 dump_file=/tmp/hostapd.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=blackshift-ng5 max_num_sta=255 rts_threshold=2347 fragm_threshold=2346 ieee80211d=1 country_code=DE hw_mode=a channel=40 #hw_mode=g #channel=8 ieee80211n=1 wme_enabled=1 ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][GF][TX-STBC][RX-STBC12][MAX-AMSDU-7935][DELAYED-BA] #[SMPS-STATIC] wmm_enabled=1 # # # Low priority / AC_BK = background wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 # Note: for IEEE 802.11b mode: cWmin=5 cWmax=10 # # Normal priority / AC_BE = best effort wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0 # Note: for IEEE 802.11b mode: cWmin=5 cWmax=7 # # High priority / AC_VI = video wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 # Note: for IEEE 802.11b mode: cWmin=4 cWmax=5 txop_limit=188 # # Highest priority / AC_VO = voice wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 # Note: for IEEE 802.11b mode: cWmin=3 cWmax=4 burst=102 wpa=2 wpa_passphrase=geheim wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP rsn_pairwise=CCMP wpa_group_rekey=600 wpa_ptk_rekey=600 output on serial line: [35438.609781] Unable to handle kernel NULL pointer dereference at virtual address 00ac [35438.619110] pgd = c0004000 [35438.622930] [00ac] *pgd= [35438.626684] Internal error: Oops: 17 [#1] [35438.630707] Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge ipv6 stp ext2 arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 hmac cfg80211 rfkill sha1_generic mv_cesa aes_generic ext4 mbcache jbd2 mmc_block ehci_hcd usbcore mvsdio mmc_core mv643xx_eth libphy inet_lro [35438.658325] CPU: 0Not tainted (3.0.0-1-kirkwood #1) [35438.663670] PC is at rt2800usb_get_txwi+0x10/0x20 [rt2800usb] [35438.669456] LR is at rt2800_txdone_entry+0x34/0xe0 [rt2800lib] [35438.675313] pc : [bf1c001c]lr : [bf1b6348]psr: 8013 [35438.675319] sp : dfa93f00 ip : 0001 fp : 0021 [35438.686855] r10: 000a r9 : 0001 r8 : 003c [35438.692106] r7 : r6 : de8f8fc0 r5 : 808c21f5 r4 : dee613a8 [35438.698663] r3 : r2 : r1 : 808c21f5 r0 : dee613a8 [35438.705222] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [35438.712563] Control: 0005397f Table: 1f978000 DAC: 0017 [35438.718336] Process kworker/u:0 (pid: 1684, stack limit = 0xdfa92270) [35438.724806] Stack: (0xdfa93f00 to 0xdfa94000) [35438.729190] 3f00: 808c21f5 de8f8fc0 dee613a8 808c21f5 de64e0b4 bf1b64cc [35438.737411] 3f20: c042c4c4 de8f8fc0 de8f8fc4 bf1c0d88 de8f93c4 c040600c 0012 [35438.745635] 3f40: c108aa05 bf1c0d9c de8f93c4 df0a8920 c108aa00 bf1c0d88 de8f93c4 [35438.753858] 3f60: c040600c 0012 c108aa05 c005b9cc df0a8920 df0a8920 c0450034 c045003c [35438.762081] 3f80: dfa92000 df0a8930 c040600c 0001 0089 c005d634 df0a8920 [35438.770303] 3fa0: a013 de4e3f10 df0a8920 dfa93fd4 c005d454 [35438.778526] 3fc0: c0060a9c c0030df4 df0a8920 dfa93fd8 dfa93fd8 [35438.786749] 3fe0: de4e3f10 c0060a18 c0030df4 0013 c0030df4 004c 000c0012 [35438.794997] [bf1c001c] (rt2800usb_get_txwi+0x10/0x20 [rt2800usb]) from [bf1b6348] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) [35438.806729] [bf1b6348] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) from [bf1b64cc] (rt2800_txdone+0xd8/0x124 [rt2800lib]) [35438.818104] [bf1b64cc] (rt2800_txdone+0xd8/0x124 [rt2800lib]) from [bf1c0d9c] (rt2800usb_work_txdone+0x14/0x104 [rt2800usb]) [35438.829740] [bf1c0d9c] (rt2800usb_work_txdone+0x14/0x104 [rt2800usb]) from [c005b9cc] (process_one_work+0x248/0x3e4) [35438.840668] [c005b9cc] (process_one_work+0x248/0x3e4) from [c005d634] (worker_thread+0x1e0/0x2fc) [35438.849940] [c005d634]
Bug#619877: rpc.mountd: svc_tli_create: could not bind to requested address
On 04/11/2011 12:43 PM, Vadim Solomin wrote: I think the changes in 1:1.2.3-2 are only part of the fix. Yes - same here. I reported that already. On Thursday 07 April 2011 11:51:42 Marc Kleine-Budde wrote: Hello Lukas, it's this bug you're seeing: https://bugzilla.linux-nfs.org/show_bug.cgi?id=190 Perhaps you should consider applying the patch from bugzilla as a debian patch until it's included upstream. Without it, if --port option is used, only v1 mountd service is registered, which doesn't support long files. ACK - I think the maintainer got it :) I think you have to remove the --port from the option /etc/default/nfs-kernel-server as a workaround. Removing --port makes firewall configuration nontrivial if not impossible. sad but true :/ cheers, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Bug#619877: rpc.mountd: svc_tli_create: could not bind to requested address
Hello, the original problem of this bugreport: rpc.mountd: svc_tli_create: could not bind to requested address is not solved with version 1:1.2.3-2. (although the second problem: portmap vs. rpcbind is fixed) I think you need to import the patch attached to this bug-report: https://bugzilla.linux-nfs.org/show_bug.cgi?id=190 cheers, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Bug#621471: upgrade to 1:1.2.3-1 breaks statd, prevents mounting
using rpcbind instead of portmap works here. cheers, MArc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
