From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DEDF2C433EF for ; Fri, 8 Apr 2022 11:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ubpsf9Zi1bpSIarMnMeC3R++NAuW0liAK651wLr+p6Y=; b=obn+dYRVj++axj x1KRsV2ZAsmyDcYJDaWnmPdeQAMMPydiJH8SSom8IgUPii9E7MvjirXO5KcU64u5xmgNT34gyUevs n2IYlBuNHlOyqyv7OJE+jPJZdslf9+7CgKDuAFa2VTzhar8riZ6vUIRHPEIqLY8cxcZTUOx0L+ywB pXuQNIM2No6r/vSD5dGEJVa+5PqAFtBRBJJ7Y75P6eHgejXQfe8qp7+/5i3VXx/TdVt9U51/It0af 09YKDkOrQyACfw69fwyrzVLLuCyuAQplHjwGvZOfZwAJaUiHr2ZM1j2Fe5hSvMBd7pVI2vFUOp1rn DmwS6jfny+/cwkxWZ/gg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncmWQ-00GVQ4-5N; Fri, 08 Apr 2022 11:11:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncmWM-00GVO4-2h for linux-arm-kernel@lists.infradead.org; Fri, 08 Apr 2022 11:11:20 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B9AED11FB; Fri, 8 Apr 2022 04:11:14 -0700 (PDT) Received: from [10.57.41.19] (unknown [10.57.41.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 00B843F73B; Fri, 8 Apr 2022 04:11:11 -0700 (PDT) Message-ID: Date: Fri, 8 Apr 2022 12:11:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH -next V2 7/7] arm64: add pagecache reading to machine check safe Content-Language: en-GB To: Tong Tiangen , Mark Rutland , james.morse@arm.com Cc: Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Catalin Marinas , Will Deacon , Alexander Viro , x86@kernel.org, "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kefeng Wang References: <20220406091311.3354723-1-tongtiangen@huawei.com> <20220406091311.3354723-8-tongtiangen@huawei.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220408_041118_250518_8D1B474D X-CRM114-Status: GOOD ( 29.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gMjAyMi0wNC0wOCAwMzo0MywgVG9uZyBUaWFuZ2VuIHdyb3RlOgo+IAo+IAo+IOWcqCAyMDIy LzQvNyAyMzo1MywgUm9iaW4gTXVycGh5IOWGmemBkzoKPj4gT24gMjAyMi0wNC0wNyAxNTo1Niwg VG9uZyBUaWFuZ2VuIHdyb3RlOgo+Pj4KPj4+Cj4+PiDlnKggMjAyMi80LzYgMTk6MjcsIE1hcmsg UnV0bGFuZCDlhpnpgZM6Cj4+Pj4gT24gV2VkLCBBcHIgMDYsIDIwMjIgYXQgMDk6MTM6MTFBTSAr MDAwMCwgVG9uZyBUaWFuZ2VuIHdyb3RlOgo+Pj4+PiBXaGVuIHVzZXIgcHJvY2VzcyByZWFkaW5n IGZpbGUsIHRoZSBkYXRhIGlzIGNhY2hlZCBpbiBwYWdlY2FjaGUgYW5kCj4+Pj4+IHRoZSBkYXRh IGJlbG9uZ3MgdG8gdGhlIHVzZXIgcHJvY2VzcywgV2hlbiBtYWNoaW5lIGNoZWNrIGVycm9yIGlz Cj4+Pj4+IGVuY291bnRlcmVkIGR1cmluZyBwYWdlY2FjaGUgcmVhZGluZywga2lsbGluZyB0aGUg dXNlciBwcm9jZXNzIGFuZAo+Pj4+PiBpc29sYXRlIHRoZSB1c2VyIHBhZ2Ugd2l0aCBoYXJkd2Fy ZSBtZW1vcnkgZXJyb3JzIGlzIGEgbW9yZSByZWFzb25hYmxlCj4+Pj4+IGNob2ljZSB0aGFuIGtl cm5lbCBwYW5pYy4KPj4+Pj4KPj4+Pj4gVGhlIF9fYXJjaF9jb3B5X21jX3RvX3VzZXIoKSBpbiBj b3B5X3RvX3VzZXJfbWMuUyBpcyBsYXJnZWx5IGJvcnJvd3MKPj4+Pj4gZnJvbSBfX2FyY2hfY29w eV90b191c2VyKCkgaW4gY29weV90b191c2VyLlMgYW5kIHRoZSBtYWluIGRpZmZlcmVuY2UKPj4+ Pj4gaXMgX19hcmNoX2NvcHlfbWNfdG9fdXNlcigpIGFkZCB0aGUgZXh0YWJsZSBlbnRyeSB0byBz dXBwb3J0IG1hY2hpbmUKPj4+Pj4gY2hlY2sgc2FmZS4KPj4+Pgo+Pj4+IEFzIHdpdGggcHJpb3Ig cGF0Y2hlcywgKndoeSogaXMgdGhlIGRpc3RpbmN0aW9uIG5lY2Vzc2FyeT8KPj4+Pgo+Pj4+IFRo aXMgcGF0Y2ggYWRkcyBhIGJ1bmNoIG9mIGNvbmRpdGlvbmFsIGxvZ2ljLCBidXQgKnN0cnVjdHVy YWxseSogaXQgCj4+Pj4gZG9lc24ndAo+Pj4+IGFsdGVyIHRoZSBoYW5kbGluZyB0byBiZSBzdWJz dGFudGlhbGx5IGRpZmZlcmVudCBmb3IgdGhlIE1DIGFuZCAKPj4+PiBub24tTUMgY2FzZXMuCj4+ Pj4KPj4+PiBUaGlzIHNlZW1zIGxpa2UgcG9pbnRsZXNzIGR1cGxpY2F0aW9uIHRoYXQganVzdCBt YWtlcyBpdCBoYXJkZXIgdG8gCj4+Pj4gbWFpbnRhaW4KPj4+PiB0aGlzIGNvZGUuCj4+Pj4KPj4+ PiBUaGFua3MsCj4+Pj4gTWFyay4KPj4+Cj4+PiBBZ3JlZWQsIFRoZSBpbXBsZW1lbnRhdGlvbiBo ZXJlIGxvb2tzIGEgbGl0dGxlIHVnbHkgYW5kIGhhcmRlciB0byAKPj4+IG1haW50YWluLgo+Pj4K Pj4+IFRoZSBwdXJwb3NlIG9mIG15IGRvaW5nIHRoaXMgaXMgbm90IGFsbCBjb3B5X3RvX3VzZXIg Y2FuIGJlIHJlY292ZXJlZC4KPj4+Cj4+PiBBIG1lbW9yeSBlcnJvciBpcyBjb25zdW1lZCB3aGVu IHJlYWRpbmcgcGFnZWNhY2hlIHVzaW5nIGNvcHlfdG9fdXNlci4KPj4+IEkgdGhpbmsgaW4gdGhp cyBzY2VuYXJpbywgb25seSB0aGUgcHJvY2VzcyBpcyBhZmZlY3RlZCBiZWNhdXNlIGl0IAo+Pj4g Y2FuJ3QgcmVhZAo+Pj4gcGFnZWNhY2hlIGRhdGEgY29ycmVjdGx5LiBKdXN0IGtpbGwgdGhlIHBy b2Nlc3MgYW5kIGRvbid0IG5lZWQgdGhlIHdob2xlCj4+PiBrZXJuZWwgcGFuaWMuCj4+Pgo+Pj4g U28gSSBuZWVkIHR3byBkaWZmZXJlbnQgY29weV90b191c2VyIGltcGxlbWVudGF0aW9uLCBvbmUg aXMgZXhpc3RpbmcgCj4+PiBfX2FyY2hfY29weV90b191c2VyLAo+Pj4gdGhpcyBmdW5jdGlvbiB3 aWxsIHBhbmljIHdoZW4gY29uc3VtaW5nIG1lbW9yeSBlcnJvcnMuIFRoZSBvdGhlciBvbmUgCj4+ PiBpcyB0aGlzIG5ldyBoZWxwZXIKPj4+IF9fYXJjaF9jb3B5X21jX3RvX3VzZXIsIHRoaXMgaW50 ZXJmYWNlIGlzIHVzZWQgd2hlbiByZWFkaW5nIAo+Pj4gcGFnZWNhY2hlLiBJdCBjYW4gcmVjb3Zl ciBmcm9tCj4+PiBjb25zdW1lIG1lbW9yeSBlcnJvci4KPj4KPj4gT0ssIGJ1dCBkbyB3ZSByZWFs bHkgbmVlZCB0d28gYWxtb3N0LWlkZW50aWNhbCBpbXBsZW1lbnRhdGlvbnMgb2YgCj4+IGV2ZXJ5 IGZ1bmN0aW9uIHdoZXJlIHRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgaG93IHRoZSBleGNlcHRpb24g dGFibGUgCj4+IGVudHJpZXMgYXJlIGFubm90YXRlZD8gQ291bGQgdGhlIGV4Y2VwdGlvbiBoYW5k bGVyIGl0c2VsZiBqdXN0IGZpZ3VyZSAKPj4gb3V0IHdobyBvd25zIHRoZSBwYWdlIHdoZXJlIHRo ZSBmYXVsdCBvY2N1cnJlZCBhbmQgZGVjaWRlIHdoYXQgYWN0aW9uIAo+PiB0byB0YWtlIGFzIGFw cHJvcHJpYXRlPwo+Pgo+PiBSb2Jpbi4KPj4KPiAKPiBUaGFuayB5b3UsIFJvYmluLgo+IAo+IEkg YWRkZWQgdGhpcyBjYWxsIHBhdGggaW4gdGhpcyBwYXRjaHNldDogZG9fc2VhKCkgLT4gZml4dXBf ZXhjZXB0aW9uKCksIAo+IHRoZSBwdXJwb3NlIGlzIHRvIHByb3ZpZGUgYSBjaGFuY2UgZm9yIHNl YSBmYXVsdCB0byBmaXh1cCAocmVmZXIgcGF0Y2ggCj4gMy83KS4KPiAKPiBJZiBmaXh1cCBzdWNj ZXNzZnVsLCBwYW5pYyBjYW4gYmUgYXZvaWRlZC4gT3RoZXJ3aXNlLCBwYW5pYyBjYW4gYmUgCj4g ZWxpbWluYXRlZCBhY2NvcmRpbmcgdG8gdGhlIG9yaWdpbmFsIGxvZ2ljLgo+IAo+IGZpeHVwX2V4 Y2VwdGlvbigpIHdpbGwgc2V0IHJlZ3MtPnBjIGFuZCBqdW1wIHRvIHJlZ3MtPnBjIHdoZW4gdGhl IAo+IGNvbnRleHQgcmVjb3Zlcnkgb2YgYW4gZXhjZXB0aW9uIG9jY3Vycy4KPiAKPiBJZiBtYy1z YWZlLWZpeHVwIGFkZGVkIHRvwqAgX19hcmNoX2NvcHlfdG9fdXNlcigpLMKgIGluICpub24gcGFn ZWNhY2hlIAo+IHJlYWRpbmcqIHNjZW5hcmlvIGVuY291bnQgbWVtb3J5IGVycm9yIHdoZW4gY2Fs bCBfX2FyY2hfY29weV90b191c2VyKCkgLCAKPiBkb19zZWEoKSAtPiBmaXh1cF9leGNlcHRpb24o KSB3aWxsIG5vdCByZXR1cm4gZmFpbCBhbmQgd2lsbCBtaXNzIHRoZSAKPiBwYW5pYyBsb2dpYyBp biBkb19zZWEoKS4KPiAKPiBTbyBJIGFkZCBuZXcgaGVscGVyIF9fYXJjaF9jb3B5X21jX3RvX3Vz ZXIoKcKgIGFuZCBhZGQgbWMtc2FmZS1maXh1cCB0byAKPiB0aGlzIGhlbHBlciwgd2hpY2ggY2Fu IGJlIHVzZWQgaW4gdGhlIHJlcXVpcmVkIHNjZW5hcmlvcy4gQXQgcHJlc2VudCwgCj4gdGhlcmUg aXMgb25seSBvbmUgcGFnZWNhY2hlIHJlYWRpbmcgc2NlbmFyaW8sIG90aGVyIHNjZW5hcmlvcyBu ZWVkIHRvIGJlIAo+IGRldmVsb3BlZC4KPiAKPiBUaGlzIGlzIG15IGN1cnJlbnQgY29uZnVzaW9u LiBPZiBjb3Vyc2UsIEkgd2lsbCB0aGluayBhYm91dCB0aGUgc29sdXRpb24gCj4gdG/CoCBzb2x2 ZSB0aGUgZHVwbGljYXRlIGNvZGUgcHJvYmxlbS4KClJpZ2h0LCBidXQgaWYgdGhlIHBvaW50IGlz IHRoYXQgZmF1bHRzIGluIHBhZ2VjYWhlIHBhZ2VzIGFyZSBzcGVjaWFsLCAKc3VyZWx5IF9fZG9f a2VybmVsX2ZhdWx0KCkgY291bGQgdWx0aW1hdGVseSBmaWd1cmUgb3V0IGZyb20gdGhlIGFkZHJl c3MgCndoZXRoZXIgdGhhdCdzIHRoZSBjYXNlIG9yIG5vdD8KCkluIGdlbmVyYWwsIGlmIHRoZSBw cmluY2lwbGUgaXMgdGhhdCB3aGV0aGVyIGEgZmF1bHQgaXMgcmVjb3ZlcmFibGUgb3IgCm5vdCBk ZXBlbmRzIG9uIHdoYXQgd2FzIGJlaW5nIGFjY2Vzc2VkLCB0aGVuIHRvIG1lIGl0IHNlZW1zIApm dW5kYW1lbnRhbGx5IG1vcmUgcm9idXN0IHRvIGJhc2UgdGhhdCBkZWNpc2lvbiBvbiBkZXRhaWxz IG9mIHRoZSBmYXVsdCAKdGhhdCBhY3R1YWxseSBvY2N1cnJlZCwgcmF0aGVyIHRoYW4gd2hhdCB0 aGUgY2FsbGVyIHRob3VnaHQgaXQgd2FzIApzdXBwb3NlZCB0byBiZSBkb2luZyBhdCB0aGUgdGlt ZS4KClRoYW5rcywKUm9iaW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVs QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C862C433EF for ; Fri, 8 Apr 2022 11:11:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6E0B6B0071; Fri, 8 Apr 2022 07:11:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F7236B0072; Fri, 8 Apr 2022 07:11:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 870636B0074; Fri, 8 Apr 2022 07:11:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 747C36B0071 for ; Fri, 8 Apr 2022 07:11:16 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 3D5F380FC9 for ; Fri, 8 Apr 2022 11:11:16 +0000 (UTC) X-FDA: 79333445352.03.D46AB1B Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 92143160007 for ; Fri, 8 Apr 2022 11:11:15 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B9AED11FB; Fri, 8 Apr 2022 04:11:14 -0700 (PDT) Received: from [10.57.41.19] (unknown [10.57.41.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 00B843F73B; Fri, 8 Apr 2022 04:11:11 -0700 (PDT) Message-ID: Date: Fri, 8 Apr 2022 12:11:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH -next V2 7/7] arm64: add pagecache reading to machine check safe Content-Language: en-GB To: Tong Tiangen , Mark Rutland , james.morse@arm.com Cc: Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Catalin Marinas , Will Deacon , Alexander Viro , x86@kernel.org, "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Kefeng Wang References: <20220406091311.3354723-1-tongtiangen@huawei.com> <20220406091311.3354723-8-tongtiangen@huawei.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 92143160007 X-Stat-Signature: oj7ofiqfmy65965omsggtru7zof7xirh X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com X-HE-Tag: 1649416275-316674 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022-04-08 03:43, Tong Tiangen wrote: > > > 在 2022/4/7 23:53, Robin Murphy 写道: >> On 2022-04-07 15:56, Tong Tiangen wrote: >>> >>> >>> 在 2022/4/6 19:27, Mark Rutland 写道: >>>> On Wed, Apr 06, 2022 at 09:13:11AM +0000, Tong Tiangen wrote: >>>>> When user process reading file, the data is cached in pagecache and >>>>> the data belongs to the user process, When machine check error is >>>>> encountered during pagecache reading, killing the user process and >>>>> isolate the user page with hardware memory errors is a more reasonable >>>>> choice than kernel panic. >>>>> >>>>> The __arch_copy_mc_to_user() in copy_to_user_mc.S is largely borrows >>>>> from __arch_copy_to_user() in copy_to_user.S and the main difference >>>>> is __arch_copy_mc_to_user() add the extable entry to support machine >>>>> check safe. >>>> >>>> As with prior patches, *why* is the distinction necessary? >>>> >>>> This patch adds a bunch of conditional logic, but *structurally* it >>>> doesn't >>>> alter the handling to be substantially different for the MC and >>>> non-MC cases. >>>> >>>> This seems like pointless duplication that just makes it harder to >>>> maintain >>>> this code. >>>> >>>> Thanks, >>>> Mark. >>> >>> Agreed, The implementation here looks a little ugly and harder to >>> maintain. >>> >>> The purpose of my doing this is not all copy_to_user can be recovered. >>> >>> A memory error is consumed when reading pagecache using copy_to_user. >>> I think in this scenario, only the process is affected because it >>> can't read >>> pagecache data correctly. Just kill the process and don't need the whole >>> kernel panic. >>> >>> So I need two different copy_to_user implementation, one is existing >>> __arch_copy_to_user, >>> this function will panic when consuming memory errors. The other one >>> is this new helper >>> __arch_copy_mc_to_user, this interface is used when reading >>> pagecache. It can recover from >>> consume memory error. >> >> OK, but do we really need two almost-identical implementations of >> every function where the only difference is how the exception table >> entries are annotated? Could the exception handler itself just figure >> out who owns the page where the fault occurred and decide what action >> to take as appropriate? >> >> Robin. >> > > Thank you, Robin. > > I added this call path in this patchset: do_sea() -> fixup_exception(), > the purpose is to provide a chance for sea fault to fixup (refer patch > 3/7). > > If fixup successful, panic can be avoided. Otherwise, panic can be > eliminated according to the original logic. > > fixup_exception() will set regs->pc and jump to regs->pc when the > context recovery of an exception occurs. > > If mc-safe-fixup added to  __arch_copy_to_user(),  in *non pagecache > reading* scenario encount memory error when call __arch_copy_to_user() , > do_sea() -> fixup_exception() will not return fail and will miss the > panic logic in do_sea(). > > So I add new helper __arch_copy_mc_to_user()  and add mc-safe-fixup to > this helper, which can be used in the required scenarios. At present, > there is only one pagecache reading scenario, other scenarios need to be > developed. > > This is my current confusion. Of course, I will think about the solution > to  solve the duplicate code problem. Right, but if the point is that faults in pagecahe pages are special, surely __do_kernel_fault() could ultimately figure out from the address whether that's the case or not? In general, if the principle is that whether a fault is recoverable or not depends on what was being accessed, then to me it seems fundamentally more robust to base that decision on details of the fault that actually occurred, rather than what the caller thought it was supposed to be doing at the time. Thanks, Robin.