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 04CCAC38142 for ; Sat, 28 Jan 2023 03:53:15 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:CC:To:Subject: From: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=6KTUfQgja2S7gIE1srx/EhWnfxvDQmiv3KRshuq8RPI=; b=ZM/06BdrNRDpYc 3B94bgj4abqUOvyN7frHzxIFnN9PQUiSuDujgmXd+Cj3/a+ZxcRaUxRYKb/BFiBRHapH8j18dXpVl s4uEPvFdgYunD+zBcxwb/Ks6ffujZWZVpSTheJalUO7m5HW2ASeS8/4xY93exCroH4tWBsVGDtihw fTpkxJDvgCMut7tpcZ5GADk4hFN4Zci8UxE9Op654GdKGRBLUKqfYf+Nl4M9DOkOrKLdTRkxSklR6 5EwnqnBOhRq59seN8aYToOjsUQNIBRF5+XTPB7Glw1GPIvYf18nDeFcg43kLM4SK8s9uT6M6NWA4Q tSWGNJ0qINLyORRXBLNw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pLcH4-00H8cQ-P0; Sat, 28 Jan 2023 03:53:06 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pLcH0-00H8aG-3E for linux-riscv@lists.infradead.org; Sat, 28 Jan 2023 03:53:04 +0000 Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4P3gTZ6nlFznVxm; Sat, 28 Jan 2023 11:50:58 +0800 (CST) Received: from [10.67.110.108] (10.67.110.108) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 28 Jan 2023 11:52:55 +0800 Message-ID: <0abbbdd4-6b85-9659-03ee-97c56a5b77c1@huawei.com> Date: Sat, 28 Jan 2023 11:52:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 From: "liaochang (A)" Subject: Re: [PATCH] riscv: kprobe: Optimize kprobe with accurate atomicity To: , , , , , , CC: , , Guo Ren References: <20230126161559.1467374-1-guoren@kernel.org> In-Reply-To: <20230126161559.1467374-1-guoren@kernel.org> X-Originating-IP: [10.67.110.108] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230127_195302_533568_7228E550 X-CRM114-Status: GOOD ( 22.07 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org SGksIEd1byBSZW4KCuWcqCAyMDIzLzEvMjcgMDoxNSwgZ3VvcmVuQGtlcm5lbC5vcmcg5YaZ6YGT Ogo+IEZyb206IEd1byBSZW4gPGd1b3JlbkBsaW51eC5hbGliYWJhLmNvbT4KPiAKPiBUaGUgcHJl dmlvdXMgaW1wbGVtZW50YXRpb24gd2FzIGJhc2VkIG9uIHRoZSBzdG9wX21hdGNoaW5lIG1lY2hh bmlzbSwKPiB3aGljaCByZWR1Y2VkIHRoZSBzcGVlZCBvZiBhcm0vZGlzYXJtX2twcm9iZS4gVXNp bmcgbWluaW11bSBlYnJlYWsKPiBpbnN0cnVjdGlvbiB3b3VsZCBnZXQgYWNjdXJhdGUgYXRvbWlj aXR5Lgo+IAo+IFRoaXMgcGF0Y2ggcmVtb3ZlcyB0aGUgcGF0Y2hfdGV4dCBvZiByaXNjdiwgd2hp Y2ggaXMgYmFzZWQgb24KPiBzdG9wX21hY2hpbmUuIFRoZW4gcmlzY3Ygb25seSByZXNlcnZlZCBw YXRjaF90ZXh0X25vc3luYywgYW5kIGRldmVsb3BlcnMKPiBuZWVkIHRvIGJlIG1vcmUgY2FyZWZ1 bCBpbiBkZWFsaW5nIHdpdGggcGF0Y2hfdGV4dCBhdG9taWNpdHkuCgpJbiB0aGUgc2VyaWUgb2Yg UklTQ1YgT1BUUFJPQkVTIFsxXSwgaXQgcGF0Y2hlcyBhIGxvbmctanVtcCBpbnN0cnVjdGlvbnMg cGFpcgpBVUlQQy9KQUxSIGluIGtlcm5lbCB0ZXh0LCBzbyBpbiBvcmRlciB0byBlbnN1cmUgb3Ro ZXIgQ1BVcyBkb2VzIG5vdCBleGVjdXRlCmluIHRoZSBpbnN0cnVjdGlvbnMgdGhhdCB3aWxsIGJl IG1vZGlmaWVkLCBpdCBpcyBzdGlsbCBuZWVkIHRvIHN0b3Agb3RoZXIgQ1BVcwp2aWEgcGF0Y2hf dGV4dCBBUEksIG9yIHlvdSBoYXZlIGFueSBiZXR0ZXIgc29sdXRpb24gdG8gYWNoaWV2ZSB0aGUg cHVycG9zZT8KClRoYW5rcy4KCj4gCj4gV2hlbiBDT05GSUdfUklTQ1ZfSVNBX0M9biwgdGhlIGVi cmVhayBjb3VsZCByZXBsYWNlIHRoZSB3aG9sZQo+IGluc3RydWN0aW9uLiBXaGVuIENPTkZJR19S SVNDVl9JU0FfQz15LCB0aGUgcGF0Y2ggdXNlcyAxNi1iaXQgbGVuZ3RoCj4gYy5lYnJlYWsgaW5z dHJ1Y3Rpb24sIHdoaWNoIG1heSBvY2N1cHkgdGhlIGZpcnN0IHBhcnQgb2YgdGhlIDMyLWJpdAo+ IGluc3RydWN0aW9uIGFuZCBsZWF2ZSBoYWxmIHRoZSByZXN0IG9mIHRoZSBicm9rZW4gaW5zdHJ1 Y3Rpb24uIEJlY2F1c2UKPiBlYnJlYWsgY291bGQgZGV0b3VyIHRoZSBmbG93IHRvIHNraXAgaXQs IGxlYXZpbmcgaXQgaW4gdGhlIGtlcm5lbCB0ZXh0Cj4gbWVtb3J5IGlzIG9rYXkuCj4gCj4gU2ln bmVkLW9mZi1ieTogR3VvIFJlbiA8Z3VvcmVuQGxpbnV4LmFsaWJhYmEuY29tPgo+IFNpZ25lZC1v ZmYtYnk6IEd1byBSZW4gPGd1b3JlbkBrZXJuZWwub3JnPgo+IC0tLQo+ICBhcmNoL3Jpc2N2L2lu Y2x1ZGUvYXNtL3BhdGNoLmggICAgIHwgIDEgLQo+ICBhcmNoL3Jpc2N2L2tlcm5lbC9wYXRjaC5j ICAgICAgICAgIHwgMzMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gIGFyY2gvcmlz Y3Yva2VybmVsL3Byb2Jlcy9rcHJvYmVzLmMgfCAyOSArKysrKysrKysrKysrKysrKystLS0tLS0t LQo+ICAzIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyksIDQyIGRlbGV0aW9ucygtKQo+ IAo+IGRpZmYgLS1naXQgYS9hcmNoL3Jpc2N2L2luY2x1ZGUvYXNtL3BhdGNoLmggYi9hcmNoL3Jp c2N2L2luY2x1ZGUvYXNtL3BhdGNoLmgKPiBpbmRleCA5YTdkNzM0NjAwMWUuLjI1MDA3ODJlNmY1 YiAxMDA2NDQKPiAtLS0gYS9hcmNoL3Jpc2N2L2luY2x1ZGUvYXNtL3BhdGNoLmgKPiArKysgYi9h cmNoL3Jpc2N2L2luY2x1ZGUvYXNtL3BhdGNoLmgKPiBAQCAtNyw2ICs3LDUgQEAKPiAgI2RlZmlu ZSBfQVNNX1JJU0NWX1BBVENIX0gKPiAgCj4gIGludCBwYXRjaF90ZXh0X25vc3luYyh2b2lkICph ZGRyLCBjb25zdCB2b2lkICppbnNucywgc2l6ZV90IGxlbik7Cj4gLWludCBwYXRjaF90ZXh0KHZv aWQgKmFkZHIsIHUzMiBpbnNuKTsKPiAgCj4gICNlbmRpZiAvKiBfQVNNX1JJU0NWX1BBVENIX0gg Ki8KPiBkaWZmIC0tZ2l0IGEvYXJjaC9yaXNjdi9rZXJuZWwvcGF0Y2guYyBiL2FyY2gvcmlzY3Yv a2VybmVsL3BhdGNoLmMKPiBpbmRleCA3NjUwMDRiNjA1MTMuLjhiZDUxZWQ4YjgwNiAxMDA2NDQK PiAtLS0gYS9hcmNoL3Jpc2N2L2tlcm5lbC9wYXRjaC5jCj4gKysrIGIvYXJjaC9yaXNjdi9rZXJu ZWwvcGF0Y2guYwo+IEBAIC05OCwzNiArOTgsMyBAQCBpbnQgcGF0Y2hfdGV4dF9ub3N5bmModm9p ZCAqYWRkciwgY29uc3Qgdm9pZCAqaW5zbnMsIHNpemVfdCBsZW4pCj4gIAlyZXR1cm4gcmV0Owo+ ICB9Cj4gIE5PS1BST0JFX1NZTUJPTChwYXRjaF90ZXh0X25vc3luYyk7Cj4gLQo+IC1zdGF0aWMg aW50IHBhdGNoX3RleHRfY2Iodm9pZCAqZGF0YSkKPiAtewo+IC0Jc3RydWN0IHBhdGNoX2luc24g KnBhdGNoID0gZGF0YTsKPiAtCWludCByZXQgPSAwOwo+IC0KPiAtCWlmIChhdG9taWNfaW5jX3Jl dHVybigmcGF0Y2gtPmNwdV9jb3VudCkgPT0gbnVtX29ubGluZV9jcHVzKCkpIHsKPiAtCQlyZXQg PQo+IC0JCSAgICBwYXRjaF90ZXh0X25vc3luYyhwYXRjaC0+YWRkciwgJnBhdGNoLT5pbnNuLAo+ IC0JCQkJCSAgICBHRVRfSU5TTl9MRU5HVEgocGF0Y2gtPmluc24pKTsKPiAtCQlhdG9taWNfaW5j KCZwYXRjaC0+Y3B1X2NvdW50KTsKPiAtCX0gZWxzZSB7Cj4gLQkJd2hpbGUgKGF0b21pY19yZWFk KCZwYXRjaC0+Y3B1X2NvdW50KSA8PSBudW1fb25saW5lX2NwdXMoKSkKPiAtCQkJY3B1X3JlbGF4 KCk7Cj4gLQkJc21wX21iKCk7Cj4gLQl9Cj4gLQo+IC0JcmV0dXJuIHJldDsKPiAtfQo+IC1OT0tQ Uk9CRV9TWU1CT0wocGF0Y2hfdGV4dF9jYik7Cj4gLQo+IC1pbnQgcGF0Y2hfdGV4dCh2b2lkICph ZGRyLCB1MzIgaW5zbikKPiAtewo+IC0Jc3RydWN0IHBhdGNoX2luc24gcGF0Y2ggPSB7Cj4gLQkJ LmFkZHIgPSBhZGRyLAo+IC0JCS5pbnNuID0gaW5zbiwKPiAtCQkuY3B1X2NvdW50ID0gQVRPTUlD X0lOSVQoMCksCj4gLQl9Owo+IC0KPiAtCXJldHVybiBzdG9wX21hY2hpbmVfY3B1c2xvY2tlZChw YXRjaF90ZXh0X2NiLAo+IC0JCQkJICAgICAgICZwYXRjaCwgY3B1X29ubGluZV9tYXNrKTsKPiAt fQo+IC1OT0tQUk9CRV9TWU1CT0wocGF0Y2hfdGV4dCk7Cj4gZGlmZiAtLWdpdCBhL2FyY2gvcmlz Y3Yva2VybmVsL3Byb2Jlcy9rcHJvYmVzLmMgYi9hcmNoL3Jpc2N2L2tlcm5lbC9wcm9iZXMva3By b2Jlcy5jCj4gaW5kZXggNDc1OTg5ZjA2ZDZkLi4yN2Y4OTYwYzMyMWMgMTAwNjQ0Cj4gLS0tIGEv YXJjaC9yaXNjdi9rZXJuZWwvcHJvYmVzL2twcm9iZXMuYwo+ICsrKyBiL2FyY2gvcmlzY3Yva2Vy bmVsL3Byb2Jlcy9rcHJvYmVzLmMKPiBAQCAtMjQsMTIgKzI0LDE4IEBAIHBvc3Rfa3Byb2JlX2hh bmRsZXIoc3RydWN0IGtwcm9iZSAqLCBzdHJ1Y3Qga3Byb2JlX2N0bGJsayAqLCBzdHJ1Y3QgcHRf cmVncyAqKTsKPiAgc3RhdGljIHZvaWQgX19rcHJvYmVzIGFyY2hfcHJlcGFyZV9zc19zbG90KHN0 cnVjdCBrcHJvYmUgKnApCj4gIHsKPiAgCXVuc2lnbmVkIGxvbmcgb2Zmc2V0ID0gR0VUX0lOU05f TEVOR1RIKHAtPm9wY29kZSk7Cj4gKyNpZmRlZiBDT05GSUdfUklTQ1ZfSVNBX0MKPiArCXUzMiBv cGNvZGUgPSBfX0JVR19JTlNOXzE2Owo+ICsjZWxzZQo+ICsJdTMyIG9wY29kZSA9IF9fQlVHX0lO U05fMzI7Cj4gKyNlbmRpZgo+ICAKPiAgCXAtPmFpbnNuLmFwaS5yZXN0b3JlID0gKHVuc2lnbmVk IGxvbmcpcC0+YWRkciArIG9mZnNldDsKPiAgCj4gLQlwYXRjaF90ZXh0KHAtPmFpbnNuLmFwaS5p bnNuLCBwLT5vcGNvZGUpOwo+IC0JcGF0Y2hfdGV4dCgodm9pZCAqKSgodW5zaWduZWQgbG9uZyko cC0+YWluc24uYXBpLmluc24pICsgb2Zmc2V0KSwKPiAtCQkgICBfX0JVR19JTlNOXzMyKTsKPiAr CXBhdGNoX3RleHRfbm9zeW5jKHAtPmFpbnNuLmFwaS5pbnNuLCAmcC0+b3Bjb2RlLCBvZmZzZXQp Owo+ICsJcGF0Y2hfdGV4dF9ub3N5bmMoKHZvaWQgKikoKHVuc2lnbmVkIGxvbmcpKHAtPmFpbnNu LmFwaS5pbnNuKSArIG9mZnNldCksCj4gKwkJCSAgJm9wY29kZSwgR0VUX0lOU05fTEVOR1RIKG9w Y29kZSkpOwo+ICsKCkkgaGF2ZSBzdWJtaXQgYSBzaW1pbGFyIG9wdGltaXphdGlvbiBmb3IgcGF0 Y2hpbmcgc2luZ2xlLXN0ZXAgc2xvdCBbMl0uCkFuZCBpdCBpcyBpbmRlZWQgc2FmZSB0byB1c2Ug Y29tcGFjdCBicmVha3BvaW50IGluIHNpbmdsZS1zdGVwIHNsb3Qgbm8gbWF0dGVyCndoYXQgdHlw ZSBvZiBwYXRjaGVkIGluc3RydWN0aW9uIGlzLgoKVGhhbmtzLgoKPiAgfQo+ICAKPiAgc3RhdGlj IHZvaWQgX19rcHJvYmVzIGFyY2hfcHJlcGFyZV9zaW11bGF0ZShzdHJ1Y3Qga3Byb2JlICpwKQo+ IEBAIC0xMTQsMTYgKzEyMCwyMyBAQCB2b2lkICphbGxvY19pbnNuX3BhZ2Uodm9pZCkKPiAgLyog aW5zdGFsbCBicmVha3BvaW50IGluIHRleHQgKi8KPiAgdm9pZCBfX2twcm9iZXMgYXJjaF9hcm1f a3Byb2JlKHN0cnVjdCBrcHJvYmUgKnApCj4gIHsKPiAtCWlmICgocC0+b3Bjb2RlICYgX19JTlNO X0xFTkdUSF9NQVNLKSA9PSBfX0lOU05fTEVOR1RIXzMyKQo+IC0JCXBhdGNoX3RleHQocC0+YWRk ciwgX19CVUdfSU5TTl8zMik7Cj4gLQllbHNlCj4gLQkJcGF0Y2hfdGV4dChwLT5hZGRyLCBfX0JV R19JTlNOXzE2KTsKPiArI2lmZGVmIENPTkZJR19SSVNDVl9JU0FfQwo+ICsJdTMyIG9wY29kZSA9 IF9fQlVHX0lOU05fMTY7Cj4gKyNlbHNlCj4gKwl1MzIgb3Bjb2RlID0gX19CVUdfSU5TTl8zMjsK PiArI2VuZGlmCj4gKwlwYXRjaF90ZXh0X25vc3luYyhwLT5hZGRyLCAmb3Bjb2RlLCBHRVRfSU5T Tl9MRU5HVEgob3Bjb2RlKSk7CgpTb3VuZHMgZ29vZCwgYnV0IGl0IHdpbGwgbGVhdmUgc29tZSBS VkkgaW5zdHJ1Y3Rpb24gdHJ1bmNhdGVkIGluIGtlcm5lbCB0ZXh0LAppIGRvdWJ0IGtlcm5lbCBi ZWhhdmlvciBkZXBlbmRzIG9uIHRoZSByZXN0IG9mIHRoZSB0cnVuY2F0ZWQgaW5zdHJ1Y3Rpb24s IHdlbGwsCml0IG5lZWRzIG1vcmUgc3RyaWN0IHRlc3RpbmcgdG8gcHJvdmUgbXkgY29uY2VybiA6 KQoKPiAgfQo+ICAKPiAgLyogcmVtb3ZlIGJyZWFrcG9pbnQgZnJvbSB0ZXh0ICovCj4gIHZvaWQg X19rcHJvYmVzIGFyY2hfZGlzYXJtX2twcm9iZShzdHJ1Y3Qga3Byb2JlICpwKQo+ICB7Cj4gLQlw YXRjaF90ZXh0KHAtPmFkZHIsIHAtPm9wY29kZSk7Cj4gKyNpZmRlZiBDT05GSUdfUklTQ1ZfSVNB X0MKPiArCXUzMiBvcGNvZGUgPSBfX0JVR19JTlNOXzE2Owo+ICsjZWxzZQo+ICsJdTMyIG9wY29k ZSA9IF9fQlVHX0lOU05fMzI7Cj4gKyNlbmRpZgo+ICsJcGF0Y2hfdGV4dF9ub3N5bmMocC0+YWRk ciwgJnAtPm9wY29kZSwgR0VUX0lOU05fTEVOR1RIKG9wY29kZSkpOwo+ICB9Cj4gIAo+ICB2b2lk IF9fa3Byb2JlcyBhcmNoX3JlbW92ZV9rcHJvYmUoc3RydWN0IGtwcm9iZSAqcCkKClsxXSAtIGh0 dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xrbWwvMjAyMzAxMjcxMzA1NDEuMTI1MDg2NS05LWNoZW5n dW9rYWkxN0BtYWlscy51Y2FzLmFjLmNuLwpbMl0gLSBodHRwczovL2xvcmUua2VybmVsLm9yZy9s a21sLzIwMjIwOTI3MDIyNDM1LjEyOTk2NS0xLWxpYW9jaGFuZzFAaHVhd2VpLmNvbS9ULwoKLS0g CkJSLApMaWFvLCBDaGFuZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KbGludXgtcmlzY3YgbWFpbGluZyBsaXN0CmxpbnV4LXJpc2N2QGxpc3RzLmluZnJh ZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51 eC1yaXNjdgo= 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC056C27C76 for ; Sat, 28 Jan 2023 03:53:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232994AbjA1DxI (ORCPT ); Fri, 27 Jan 2023 22:53:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229737AbjA1DxD (ORCPT ); Fri, 27 Jan 2023 22:53:03 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D92359E7 for ; Fri, 27 Jan 2023 19:53:01 -0800 (PST) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4P3gTZ6nlFznVxm; Sat, 28 Jan 2023 11:50:58 +0800 (CST) Received: from [10.67.110.108] (10.67.110.108) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 28 Jan 2023 11:52:55 +0800 Message-ID: <0abbbdd4-6b85-9659-03ee-97c56a5b77c1@huawei.com> Date: Sat, 28 Jan 2023 11:52:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 From: "liaochang (A)" Subject: Re: [PATCH] riscv: kprobe: Optimize kprobe with accurate atomicity To: , , , , , , CC: , , Guo Ren References: <20230126161559.1467374-1-guoren@kernel.org> In-Reply-To: <20230126161559.1467374-1-guoren@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.110.108] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Guo Ren 在 2023/1/27 0:15, guoren@kernel.org 写道: > From: Guo Ren > > The previous implementation was based on the stop_matchine mechanism, > which reduced the speed of arm/disarm_kprobe. Using minimum ebreak > instruction would get accurate atomicity. > > This patch removes the patch_text of riscv, which is based on > stop_machine. Then riscv only reserved patch_text_nosync, and developers > need to be more careful in dealing with patch_text atomicity. In the serie of RISCV OPTPROBES [1], it patches a long-jump instructions pair AUIPC/JALR in kernel text, so in order to ensure other CPUs does not execute in the instructions that will be modified, it is still need to stop other CPUs via patch_text API, or you have any better solution to achieve the purpose? Thanks. > > When CONFIG_RISCV_ISA_C=n, the ebreak could replace the whole > instruction. When CONFIG_RISCV_ISA_C=y, the patch uses 16-bit length > c.ebreak instruction, which may occupy the first part of the 32-bit > instruction and leave half the rest of the broken instruction. Because > ebreak could detour the flow to skip it, leaving it in the kernel text > memory is okay. > > Signed-off-by: Guo Ren > Signed-off-by: Guo Ren > --- > arch/riscv/include/asm/patch.h | 1 - > arch/riscv/kernel/patch.c | 33 ------------------------------ > arch/riscv/kernel/probes/kprobes.c | 29 ++++++++++++++++++-------- > 3 files changed, 21 insertions(+), 42 deletions(-) > > diff --git a/arch/riscv/include/asm/patch.h b/arch/riscv/include/asm/patch.h > index 9a7d7346001e..2500782e6f5b 100644 > --- a/arch/riscv/include/asm/patch.h > +++ b/arch/riscv/include/asm/patch.h > @@ -7,6 +7,5 @@ > #define _ASM_RISCV_PATCH_H > > int patch_text_nosync(void *addr, const void *insns, size_t len); > -int patch_text(void *addr, u32 insn); > > #endif /* _ASM_RISCV_PATCH_H */ > diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c > index 765004b60513..8bd51ed8b806 100644 > --- a/arch/riscv/kernel/patch.c > +++ b/arch/riscv/kernel/patch.c > @@ -98,36 +98,3 @@ int patch_text_nosync(void *addr, const void *insns, size_t len) > return ret; > } > NOKPROBE_SYMBOL(patch_text_nosync); > - > -static int patch_text_cb(void *data) > -{ > - struct patch_insn *patch = data; > - int ret = 0; > - > - if (atomic_inc_return(&patch->cpu_count) == num_online_cpus()) { > - ret = > - patch_text_nosync(patch->addr, &patch->insn, > - GET_INSN_LENGTH(patch->insn)); > - atomic_inc(&patch->cpu_count); > - } else { > - while (atomic_read(&patch->cpu_count) <= num_online_cpus()) > - cpu_relax(); > - smp_mb(); > - } > - > - return ret; > -} > -NOKPROBE_SYMBOL(patch_text_cb); > - > -int patch_text(void *addr, u32 insn) > -{ > - struct patch_insn patch = { > - .addr = addr, > - .insn = insn, > - .cpu_count = ATOMIC_INIT(0), > - }; > - > - return stop_machine_cpuslocked(patch_text_cb, > - &patch, cpu_online_mask); > -} > -NOKPROBE_SYMBOL(patch_text); > diff --git a/arch/riscv/kernel/probes/kprobes.c b/arch/riscv/kernel/probes/kprobes.c > index 475989f06d6d..27f8960c321c 100644 > --- a/arch/riscv/kernel/probes/kprobes.c > +++ b/arch/riscv/kernel/probes/kprobes.c > @@ -24,12 +24,18 @@ post_kprobe_handler(struct kprobe *, struct kprobe_ctlblk *, struct pt_regs *); > static void __kprobes arch_prepare_ss_slot(struct kprobe *p) > { > unsigned long offset = GET_INSN_LENGTH(p->opcode); > +#ifdef CONFIG_RISCV_ISA_C > + u32 opcode = __BUG_INSN_16; > +#else > + u32 opcode = __BUG_INSN_32; > +#endif > > p->ainsn.api.restore = (unsigned long)p->addr + offset; > > - patch_text(p->ainsn.api.insn, p->opcode); > - patch_text((void *)((unsigned long)(p->ainsn.api.insn) + offset), > - __BUG_INSN_32); > + patch_text_nosync(p->ainsn.api.insn, &p->opcode, offset); > + patch_text_nosync((void *)((unsigned long)(p->ainsn.api.insn) + offset), > + &opcode, GET_INSN_LENGTH(opcode)); > + I have submit a similar optimization for patching single-step slot [2]. And it is indeed safe to use compact breakpoint in single-step slot no matter what type of patched instruction is. Thanks. > } > > static void __kprobes arch_prepare_simulate(struct kprobe *p) > @@ -114,16 +120,23 @@ void *alloc_insn_page(void) > /* install breakpoint in text */ > void __kprobes arch_arm_kprobe(struct kprobe *p) > { > - if ((p->opcode & __INSN_LENGTH_MASK) == __INSN_LENGTH_32) > - patch_text(p->addr, __BUG_INSN_32); > - else > - patch_text(p->addr, __BUG_INSN_16); > +#ifdef CONFIG_RISCV_ISA_C > + u32 opcode = __BUG_INSN_16; > +#else > + u32 opcode = __BUG_INSN_32; > +#endif > + patch_text_nosync(p->addr, &opcode, GET_INSN_LENGTH(opcode)); Sounds good, but it will leave some RVI instruction truncated in kernel text, i doubt kernel behavior depends on the rest of the truncated instruction, well, it needs more strict testing to prove my concern :) > } > > /* remove breakpoint from text */ > void __kprobes arch_disarm_kprobe(struct kprobe *p) > { > - patch_text(p->addr, p->opcode); > +#ifdef CONFIG_RISCV_ISA_C > + u32 opcode = __BUG_INSN_16; > +#else > + u32 opcode = __BUG_INSN_32; > +#endif > + patch_text_nosync(p->addr, &p->opcode, GET_INSN_LENGTH(opcode)); > } > > void __kprobes arch_remove_kprobe(struct kprobe *p) [1] - https://lore.kernel.org/lkml/20230127130541.1250865-9-chenguokai17@mails.ucas.ac.cn/ [2] - https://lore.kernel.org/lkml/20220927022435.129965-1-liaochang1@huawei.com/T/ -- BR, Liao, Chang