Alan Cox wrote:
>
> I hadn't considered a stack overrun - that would make a lot more sense than
> my ideas so far
What do you think about modifying the way the kernel stack is allocated
(That's something for 2.3).
1) at system startup one huge block (16 kB per task slot, (8 kB stack +
8 kB guard pages)) is vm_alloc'ed. The area must be 8 kB aligned.
2) if a task is created, then 2 single pages get allocated,
and inserted into the vm_alloc'ed area.
3) the task_struct is moved to the end of the stack.
(Windows 95 does it this way around)
This creates no synchronization problem, because the stack location
for every task is defined during system startup.
It solves the problem that we need 2 consecutive pages if we create
a new task.
If we have a stack overrun, then we will hit the guard page,
--> stack fault --> TSS --> Oops without any memory trashing.
I've also attached a small patch against 2.2.6 that add a
detection code for stack overruns. I think something like this
should go into the main kernel.
Regards,
Manfred
--------------DEA4428B2E30D2311E9D80F8
Content-Type: application/octet-stream;
name="patch_stack-2.2.6"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="patch_stack-2.2.6"
ZGlmZiAtciAtdSAtUCAteCBDVlMgLXggKix2IDIuMi42L2FyY2gvaTM4Ni9rZXJuZWwvcHJv
Y2Vzcy5jIGN1cnJlbnQvYXJjaC9pMzg2L2tlcm5lbC9wcm9jZXNzLmMKLS0tIDIuMi42L2Fy
Y2gvaTM4Ni9rZXJuZWwvcHJvY2Vzcy5jCVRodSBNYXIgMjUgMjE6MDE6NDEgMTk5OQorKysg
Y3VycmVudC9hcmNoL2kzODYva2VybmVsL3Byb2Nlc3MuYwlTdW4gQXByIDI1IDAwOjA5OjI2
IDE5OTkKQEAgLTQzOCwxMSArNDM4LDExIEBACiAKIHN0cnVjdCB0YXNrX3N0cnVjdCAqIGFs
bG9jX3Rhc2tfc3RydWN0KHZvaWQpCiB7CisJc3RydWN0IHRhc2tfc3RydWN0ICpyZXQ7CiAj
aWZuZGVmIEVYVFJBX1RBU0tfU1RSVUNUCi0JcmV0dXJuIChzdHJ1Y3QgdGFza19zdHJ1Y3Qg
KikgX19nZXRfZnJlZV9wYWdlcyhHRlBfS0VSTkVMLDEpOworCXJldCA9IChzdHJ1Y3QgdGFz
a19zdHJ1Y3QgKikgX19nZXRfZnJlZV9wYWdlcyhHRlBfS0VSTkVMLDEpOwogI2Vsc2UKIAlp
bnQgaW5kZXg7Ci0Jc3RydWN0IHRhc2tfc3RydWN0ICpyZXQ7CiAKIAlpbmRleCA9IHRhc2tf
c3RydWN0X3N0YWNrX3B0cjsKIAlpZiAoaW5kZXggPj0gRVhUUkFfVEFTS19TVFJVQ1QvMikK
QEAgLTQ1NiwxMiArNDU2LDI3IEBACiAJCQl0YXNrX3N0cnVjdF9zdGFja19wdHIgPSBpbmRl
eC0xOwogCQl9CiAJfQotCXJldHVybiByZXQ7CiAjZW5kaWYKKwlpZiAocmV0KSB7CisJCS8v
IHNlbnRpbmVsIGZvciBzdGFjayBvdmVycnVucy4KKwkJKCh1bnNpZ25lZCBsb25nKikocmV0
KzEpKVswXSA9IDB4ZGVhZGJlZWY7CQkKKwkJKCh1bnNpZ25lZCBsb25nKikocmV0KzEpKVsx
XSA9IDB4ZGVhZGJlZWY7CQkKKwkJKCh1bnNpZ25lZCBsb25nKikocmV0KzEpKVsyXSA9IDB4
ZGVhZGJlZWY7CQkKKwkJKCh1bnNpZ25lZCBsb25nKikocmV0KzEpKVszXSA9IDB4ZGVhZGJl
ZWY7CQkKKwl9CisJcmV0dXJuIHJldDsKIH0KIAogdm9pZCBmcmVlX3Rhc2tfc3RydWN0KHN0
cnVjdCB0YXNrX3N0cnVjdCAqcCkKIHsKKwlpZiAoICgoKHVuc2lnbmVkIGxvbmcqKShwKzEp
KVswXSAhPSAweGRlYWRiZWVmKSB8fAorCQkoKCh1bnNpZ25lZCBsb25nKikocCsxKSlbMV0g
IT0gMHhkZWFkYmVlZikgfHwKKwkJKCgodW5zaWduZWQgbG9uZyopKHArMSkpWzJdICE9IDB4
ZGVhZGJlZWYpIHx8CisJCSgoKHVuc2lnbmVkIGxvbmcqKShwKzEpKVszXSAhPSAweGRlYWRi
ZWVmKSApCisJeworCQlwcmludGsoS0VSTl9FUlIgImZyZWVfdGFza19zdHJ1Y3QoKTogc3Rh
Y2sgb3ZlcnJ1biBkZXRlY3RlZCEuXG4iKTsKKwl9CisJCQogI2lmZGVmIEVYVFJBX1RBU0tf
U1RSVUNUCiAJaW50IGluZGV4ID0gdGFza19zdHJ1Y3Rfc3RhY2tfcHRyKzE7CiAKZGlmZiAt
ciAtdSAtUCAteCBDVlMgLXggKix2IDIuMi42L2FyY2gvaTM4Ni9rZXJuZWwvdHJhcHMuYyBj
dXJyZW50L2FyY2gvaTM4Ni9rZXJuZWwvdHJhcHMuYwotLS0gMi4yLjYvYXJjaC9pMzg2L2tl
cm5lbC90cmFwcy5jCVdlZCBGZWIgMjQgMTQ6Mzc6NDYgMTk5OQorKysgY3VycmVudC9hcmNo
L2kzODYva2VybmVsL3RyYXBzLmMJU3VuIEFwciAyNSAwMDozMTowMCAxOTk5CkBAIC0xNDYs
NyArMTQ2LDE0IEBACiAJc3RvcmVfVFIoaSk7CiAJcHJpbnRrKCJQcm9jZXNzICVzIChwaWQ6
ICVkLCBwcm9jZXNzIG5yOiAlZCwgc3RhY2twYWdlPSUwOGx4KSIsCiAJCWN1cnJlbnQtPmNv
bW0sIGN1cnJlbnQtPnBpZCwgMHhmZmZmICYgaSwgNDA5NisodW5zaWduZWQgbG9uZyljdXJy
ZW50KTsKLQorCWlmICggKCgodW5zaWduZWQgbG9uZyopKGN1cnJlbnQrMSkpWzBdICE9IDB4
ZGVhZGJlZWYpIHx8CisJCSgoKHVuc2lnbmVkIGxvbmcqKShjdXJyZW50KzEpKVsxXSAhPSAw
eGRlYWRiZWVmKSB8fAorCQkoKCh1bnNpZ25lZCBsb25nKikoY3VycmVudCsxKSlbMl0gIT0g
MHhkZWFkYmVlZikgfHwKKwkJKCgodW5zaWduZWQgbG9uZyopKGN1cnJlbnQrMSkpWzNdICE9
IDB4ZGVhZGJlZWYpICkKKwl7CisJCXByaW50aygiXG4ga2VybmVsIHN0YWNrIG92ZXJydW4g
ZGV0ZWN0ZWQuIik7CisJfQorCQogCS8qCiAJICogV2hlbiBpbi1rZXJuZWwsIHdlIGFsc28g
cHJpbnQgb3V0IHRoZSBzdGFjayBhbmQgY29kZSBhdCB0aGUKIAkgKiB0aW1lIG9mIHRoZSBm
YXVsdC4uCg==
--------------DEA4428B2E30D2311E9D80F8--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/