From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751927Ab1JNErF (ORCPT ); Fri, 14 Oct 2011 00:47:05 -0400 Received: from mail-ww0-f42.google.com ([74.125.82.42]:48797 "EHLO mail-ww0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822Ab1JNErE (ORCPT ); Fri, 14 Oct 2011 00:47:04 -0400 MIME-Version: 1.0 In-Reply-To: References: <20111010114840.GC17079@elte.hu> <20111011062253.GA3589@elte.hu> <4E947BC9.7040805@mit.edu> From: Linus Torvalds Date: Fri, 14 Oct 2011 16:46:42 +1200 X-Google-Sender-Auth: 1mDSYOFo3M9EeL7JN_p4-CWQcA4 Message-ID: Subject: Re: [RFC] fixing the UML failure root cause To: Andrew Lutomirski Cc: Ingo Molnar , richard -rw- weinberger , Adrian Bunk , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org Content-Type: multipart/mixed; boundary=0016e64c1ba2bce0ba04af3af237 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --0016e64c1ba2bce0ba04af3af237 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2011 at 8:40 PM, Andrew Lutomirski wrote: > > How does that work? =A0The tricky case is when one of those three words > spans a page boundary if the access to the first page is valid, but > the access to the second page is not. =A0When that happens, if we report > the fault as coming from the first page, then UML is likely to get > think the fault was spurious and enter an infinite loop. Hmm. Gaah, I just find that memcpy loop disgusting. We already have that ugly "uaccess_error" crap in handle_exception(), we might as well do something like the attached and just say "hey, now you can catch the page fault information for a get_user/put_user fault". Isn't that much nicer? You don't even have to check each word, you can just take the last exception info from the thread-info. Linus --0016e64c1ba2bce0ba04af3af237 Content-Type: text/x-patch; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtqoxhza0 IGFyY2gveDg2L2luY2x1ZGUvYXNtL3RocmVhZF9pbmZvLmggfCAgICAyICsrCiBhcmNoL3g4Ni9t bS9mYXVsdC5jICAgICAgICAgICAgICAgIHwgICAgNiArKysrKy0KIDIgZmlsZXMgY2hhbmdlZCwg NyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L2lu Y2x1ZGUvYXNtL3RocmVhZF9pbmZvLmggYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS90aHJlYWRfaW5m by5oCmluZGV4IGExZmU1YzEyN2I1Mi4uZThkMjQ1ZmViZmFlIDEwMDY0NAotLS0gYS9hcmNoL3g4 Ni9pbmNsdWRlL2FzbS90aHJlYWRfaW5mby5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3Ro cmVhZF9pbmZvLmgKQEAgLTQxLDYgKzQxLDggQEAgc3RydWN0IHRocmVhZF9pbmZvIHsKIAlfX3U4 CQkJc3VwZXJ2aXNvcl9zdGFja1swXTsKICNlbmRpZgogCWludAkJCXVhY2Nlc3NfZXJyOworCWlu dAkJCXVhY2Nlc3NfZXJyb3JfY29kZTsKKwl1bnNpZ25lZCBsb25nCQl1YWNjZXNzX2FkZHI7CiB9 OwogCiAjZGVmaW5lIElOSVRfVEhSRUFEX0lORk8odHNrKQkJCVwKZGlmZiAtLWdpdCBhL2FyY2gv eDg2L21tL2ZhdWx0LmMgYi9hcmNoL3g4Ni9tbS9mYXVsdC5jCmluZGV4IDBkMTdjOGM1MGFjZC4u YmJiZWU2ZTZhOTViIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9tbS9mYXVsdC5jCisrKyBiL2FyY2gv eDg2L21tL2ZhdWx0LmMKQEAgLTYyOCw4ICs2MjgsMTIgQEAgbm9fY29udGV4dChzdHJ1Y3QgcHRf cmVncyAqcmVncywgdW5zaWduZWQgbG9uZyBlcnJvcl9jb2RlLAogCWludCBzaWc7CiAKIAkvKiBB cmUgd2UgcHJlcGFyZWQgdG8gaGFuZGxlIHRoaXMga2VybmVsIGZhdWx0PyAqLwotCWlmIChmaXh1 cF9leGNlcHRpb24ocmVncykpCisJaWYgKGZpeHVwX2V4Y2VwdGlvbihyZWdzKSkgeworCQlzdHJ1 Y3QgdGhyZWFkX2luZm8gKnRpID0gY3VycmVudF90aHJlYWRfaW5mbygpOworCQl0aS0+dWFjY2Vz c19lcnJvcl9jb2RlID0gZXJyb3JfY29kZTsKKwkJdGktPnVhY2Nlc3NfYWRkciA9IGFkZHJlc3M7 CiAJCXJldHVybjsKKwl9CiAKIAkvKgogCSAqIDMyLWJpdDoK --0016e64c1ba2bce0ba04af3af237--