Date: Sat, 8 Mar 2014 18:21:46 +0000 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= <weiss@uni-mainz.de> To: 'freebsd-arm' <freebsd-arm@FreeBSD.org> Cc: "'Ian Lepore \(ian@FreeBSD.org\)'" <ian@FreeBSD.org> Subject: Crashes on arm caused by stack corruption Message-ID: <1caa439fc6a34c06b1667708306fd558@e15be-01.zdv.Uni-Mainz.DE>
next in thread | raw e-mail | index | archive | help
--_002_1caa439fc6a34c06b1667708306fd558e15be01zdvUniMainzDE_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
For quite a while I observe random or not so random crashes on i.mx6.=20
The svc stack grows into the undefined instruction exception stack,
as can be seen here. And there is corruption around the address in
the und_sp register.
db> show reg
spsr 0x600001d3
r0 0
r1 0xc246f3c0 __pcpu
r2 0xc2438100 pcpup
r3 0xc2379039
r4 0xc6460000
r5 0xc23789e2
r6 0xc23733b4
r7 0xc6460000
r8 0
r9 0x1
r10 0
r11 0xbfffe388
r12 0
usr_sp 0xbfffdf68
usr_lr 0x21e04
svc_sp 0xf183afe8
svc_lr 0xc216add8 mi_switch+0x2b8
pc 0x4278f500
und_sp 0xf183aff0
abt_sp 0xc2565000
irq_sp 0xc2561000
The strange thing is, that there is an undefined instruction
exception stack undstack allocated for each core in initarm and
assigned to und_sp.=20
But later on in cpu_switch, und_sp is loaded=20
ldr sp, [r9, #(PCB_UND_SP)]
from un_32.pcb32_und_sp. Which is intialized to=20
#define USPACE_UNDEF_STACK_TOP (USPACE_SVC_STACK_BOTTOM - 0x10)
which comes from
#define USPACE_SVC_STACK_BOTTOM (USPACE_SVC_STACK_TOP - 0x1000)
and effectively halves the svc stack.
The undefined instruction exception stack is almost not used, besides
a few words right at the beginning of the exception handling. The
exception frame is actually build on the svc stack.=20
Now undefined instruction exceptions should only happen in user mode
(VFP). Then the used part of svc stack should be small enough, so that
no harm should result. But in cpu_throw the code for manipulating
the und_sp is actually missing. So sometimes undefined instruction=20
exceptions write on the kernel stack of the wrong process/thread.
So seem to be two solutions. If I do not miss anything, I would
suggest to just drop the code, which switches the undefined=20
instruction exception stack. The other is to add the missing
part to cpu_throw. See attached patch for both possibilities.
With any of both solutions the crashes on my system are gone.=20
I think this problem affects all arm systems.
There is another problem with the handling of undefined
instructions. The first few instructions of the undefined instruction
exception handler use static variables and are definitively
not SMP save. I wonder why the code is not similar to the
prefetch abort handler or the data abort handler.
Regards
Juergen
--_002_1caa439fc6a34c06b1667708306fd558e15be01zdvUniMainzDE_
Content-Type: application/octet-stream; name="und_stack.diff"
Content-Description: und_stack.diff
Content-Disposition: attachment; filename="und_stack.diff"; size=1652;
creation-date="Sat, 08 Mar 2014 18:01:16 GMT";
modification-date="Sat, 08 Mar 2014 17:53:05 GMT"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL3N3dGNoLlMgYi9zeXMvYXJtL2FybS9zd3RjaC5TCmlu
ZGV4IDEzM2IwZDkuLmQ5ZDYwOTcgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vYXJtL3N3dGNoLlMKKysr
IGIvc3lzL2FybS9hcm0vc3d0Y2guUwpAQCAtMTg0LDYgKzE4NCwyMCBAQCBFTlRSWShjcHVfdGhy
b3cpCiAJbW92CWxyLCBwYwogCWxkcglwYywgW3I5LCAjQ0ZfQ09OVEVYVF9TV0lUQ0hdCiAKKyNp
ZmRlZglVTkRfU1RBQ0tfSU5fS1NUQUNLCisgICAgICAgIG1ycwlyMywgY3BzcgorCS8qCisJICog
V2UgY2FuIGRvIHRoYXQsIHNpbmNlCisJICogUFNSX1NWQzMyX01PREV8UFNSX1VORDMyX01PREUg
PT0gTVNSX1VORDMyX01PREUKKwkgKi8KKwlvcnIJcjIsIHIzLCAjKFBTUl9VTkQzMl9NT0RFKQor
CW1zcgljcHNyX2MsIHIyCisKKwlsZHIJc3AsIFtyNywgIyhQQ0JfVU5EX1NQKV0KKworICAgICAg
ICBtc3IJY3Bzcl9jLCByMwkJLyogUmVzdG9yZSB0aGUgb2xkIG1vZGUgKi8KKyNlbmRpZgorCiAJ
LyogUmVzdG9yZSBhbGwgdGhlIHNhdmUgcmVnaXN0ZXJzICovCiAjaWZuZGVmIF9BUk1fQVJDSF81
RQogCWFkZAlyMSwgcjcsICNQQ0JfUjgKQEAgLTMwMyw2ICszMTcsNyBAQCBFTlRSWShjcHVfc3dp
dGNoKQogCS8qIEdldCB0aGUgdXNlciBzdHJ1Y3R1cmUgZm9yIHRoZSBuZXcgcHJvY2VzcyBpbiBy
OSAqLwogCWxkcglyOSwgW3IxLCAjKFREX1BDQildCiAKKyNpZmRlZglVTkRfU1RBQ0tfSU5fS1NU
QUNLCiAgICAgICAgIG1ycwlyMywgY3BzcgogCS8qCiAJICogV2UgY2FuIGRvIHRoYXQsIHNpbmNl
CkBAIC0zMTQsNiArMzI5LDggQEAgRU5UUlkoY3B1X3N3aXRjaCkKIAlzdHIJc3AsIFtyMiwgIyhQ
Q0JfVU5EX1NQKV0KIAogICAgICAgICBtc3IJY3Bzcl9jLCByMwkJLyogUmVzdG9yZSB0aGUgb2xk
IG1vZGUgKi8KKyNlbmRpZgorCiAJLyogcmVtOiByMiA9IG9sZCBQQ0IgKi8KIAkvKiByZW06IHI5
ID0gbmV3IFBDQiAqLwogCS8qIHJlbTogaW50ZXJydXB0cyBhcmUgZW5hYmxlZCAqLwpAQCAtNDM4
LDEwICs0NTUsNiBAQCBFTlRSWShjcHVfc3dpdGNoKQogCW1vdm5lCXIwLCAjMAkJCS8qIFdlICpr
bm93KiB2ZWN0b3JfcGFnZSdzIFZBIGlzIDB4MCAqLwogCW1vdm5lCWxyLCBwYwogCWxkcm5lCXBj
LCBbcjEwLCAjQ0ZfVExCX0ZMVVNISURfU0VdCi0JLyoKLQkgKiBXZSBjYW4gZG8gdGhhdCwgc2lu
Y2UKLQkgKiBQU1JfU1ZDMzJfTU9ERXxQU1JfVU5EMzJfTU9ERSA9PSBNU1JfVU5EMzJfTU9ERQot
CSAqLwogCiAuTGNzX2NvbnRleHRfc3dpdGNoZWQ6CiAKQEAgLTQ2MCw2ICs0NzMsNyBAQCBFTlRS
WShjcHVfc3dpdGNoKQogCiAJLyogcmVtOiByOSA9IG5ldyBQQ0IgKi8KIAorI2lmZGVmCVVORF9T
VEFDS19JTl9LU1RBQ0sKICAgICAgICAgbXJzCXIzLCBjcHNyCiAJLyoKIAkgKiBXZSBjYW4gZG8g
dGhhdCwgc2luY2UKQEAgLTQ3MSw2ICs0ODUsOCBAQCBFTlRSWShjcHVfc3dpdGNoKQogCWxkcglz
cCwgW3I5LCAjKFBDQl9VTkRfU1ApXQogCiAgICAgICAgIG1zcgljcHNyX2MsIHIzCQkvKiBSZXN0
b3JlIHRoZSBvbGQgbW9kZSAqLworI2VuZGlmCisKIAkvKiBSZXN0b3JlIGFsbCB0aGUgc2F2ZSBy
ZWdpc3RlcnMgKi8KICNpZm5kZWYgX0FSTV9BUkNIXzVFCiAJYWRkCXI3LCByOSwgI1BDQl9SOAo=
--_002_1caa439fc6a34c06b1667708306fd558e15be01zdvUniMainzDE_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1caa439fc6a34c06b1667708306fd558>