From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pg0-x233.google.com ([2607:f8b0:400e:c05::233]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1cqEHU-0002Xr-76 for kexec@lists.infradead.org; Tue, 21 Mar 2017 07:32:38 +0000 Received: by mail-pg0-x233.google.com with SMTP id n190so89978801pga.0 for ; Tue, 21 Mar 2017 00:32:15 -0700 (PDT) Date: Tue, 21 Mar 2017 16:34:53 +0900 From: AKASHI Takahiro Subject: Re: [PATCH v33 00/14] add kdump support Message-ID: <20170321073452.GA17298@linaro.org> References: <20170315095656.24992-1-takahiro.akashi@linaro.org> <1489750991.17202.40.camel@infradead.org> <1489759373.17202.44.camel@infradead.org> <20170317153358.GI5940@leverpostej> <1489765628.17202.59.camel@infradead.org> <20170317162421.GK5940@leverpostej> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170317162421.GK5940@leverpostej> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Mark Rutland , David Woodhouse Cc: marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, geoff@infradead.org, james.morse@arm.com, bauerman@linux.vnet.ibm.com, dyoung@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org T24gRnJpLCBNYXIgMTcsIDIwMTcgYXQgMDQ6MjQ6MjFQTSArMDAwMCwgTWFyayBSdXRsYW5kIHdy b3RlOgo+IE9uIEZyaSwgTWFyIDE3LCAyMDE3IGF0IDAzOjQ3OjA4UE0gKzAwMDAsIERhdmlkIFdv b2Rob3VzZSB3cm90ZToKPiA+IE9uIEZyaSwgMjAxNy0wMy0xNyBhdCAxNTozMyArMDAwMCwgTWFy ayBSdXRsYW5kIHdyb3RlOgo+ID4gTm8sIGluIHRoaXMgY2FzZSB0aGUgQ1BVcyAqd2VyZSogb2Zm bGluZWQgY29ycmVjdGx5LCBvciBhdCBsZWFzdCAiYXMKPiA+IGRlc2lnbmVkIiwgYnkgc21wX3Nl bmRfY3Jhc2hfc3RvcCgpLiBBbmQgaWYgdGhhdCBoYWRuJ3Qgd29ya2VkLCBhcwo+ID4gdmVyaWZp ZWQgYnkgKml0cyogc3luY2hyb25pc2F0aW9uIG1ldGhvZCBiYXNlZCBvbiB0aGUgYXRvbWljX3QK PiA+IHdhaXRpbmdfZm9yX2NyYXNoX2lwaSwgdGhlbiAqaXQqIHdvdWxkIGhhdmUgY29tcGxhaW5l ZCBmb3IgaXRzZWxmOgo+ID4gCj4gPiAJaWYgKGF0b21pY19yZWFkKCZ3YWl0aW5nX2Zvcl9jcmFz aF9pcGkpID4gMCkKPiA+IAkJcHJfd2FybmluZygiU01QOiBmYWlsZWQgdG8gc3RvcCBzZWNvbmRh cnkgQ1BVcyAlKnBibFxuIiwKPiA+IAkJCcKgwqDCoGNwdW1hc2tfcHJfYXJncyhjcHVfb25saW5l X21hc2spKTsKPiA+IAo+ID4gSXQncyBqdXN0IHRoYXQgc21wX3NlbmRfY3Jhc2hfc3RvcCgpIChv ciBtb3JlIHNwZWNpZmljYWxseQo+ID4gaXBpX2NwdV9jcmFzaF9zdG9wKCkpIGRvZXNuJ3QgdG91 Y2ggdGhlIG9ubGluZSBjcHUgbWFzay4gVW5saWtlIHRoZQo+ID4gQVJNMzIgZXF1aXZhbGVudCBm dW5jdGlvbiBtYWNoaWVuX2NyYXNoX25vbnBhbmljX2NvcmUoKSwgd2hpY2ggZG9lcy4KPiA+IAo+ ID4gSXQgd2Fzbid0IGNsZWFyIGlmIHRoYXQgd2FzICppbnRlbnRpb25hbCosIHRvIGFsbG93IHRo ZSBvcmlnaW5hbAo+ID4gY29udGVudHMgb2YgdGhlIG9ubGluZSBtYXNrIGJlZm9yZSB0aGUgY3Jh c2ggdG8gYmUgc2VlbiBpbiB0aGUKPiA+IHJlc3VsdGluZyB2bWNvcmUuLi4gb3IgcHVyZWx5IGFu IGFjY2lkZW50LsKgCgpZZXMsIGl0IGlzIGludGVudGlvbmFsLiBJIHJlbW92ZWQgJ29mZmxpbmUn IGNvZGUgaW4gbXkgdjE0ICgyMDE2LzMvNCkuCkFzIHlvdSBhc3N1bWVkLCBJJ2QgZXhwZWN0ICdv bmxpbmUnIHN0YXR1cyBvZiBhbGwgQ1BVcyB0byBiZSBrZXB0CnVuY2hhbmdlZCBpbiB0aGUgY29y ZSBkdW1wLgoKSWYgeW91IGNhbiBhZ3JlZSwgSSB3b3VsZCBsaWtlIHRvIG1vZGlmeSB0aGlzIGRp c3B1dGVkIHdhcm5pbmcgY29kZSB0bzoKCj09PTg8PT09CmRpZmYgLS1naXQgYS9hcmNoL2FybTY0 L2luY2x1ZGUvYXNtL3NtcC5oIGIvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9zbXAuaAppbmRleCBj ZWEwMDlmMjY1N2QuLjU1ZjA4YzVhY2ZhZCAxMDA2NDQKLS0tIGEvYXJjaC9hcm02NC9pbmNsdWRl L2FzbS9zbXAuaAorKysgYi9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL3NtcC5oCkBAIC0xNDksNiAr MTQ5LDcgQEAgc3RhdGljIGlubGluZSB2b2lkIGNwdV9wYW5pY19rZXJuZWwodm9pZCkKIGJvb2wg Y3B1c19hcmVfc3R1Y2tfaW5fa2VybmVsKHZvaWQpOwogCiBleHRlcm4gdm9pZCBzbXBfc2VuZF9j cmFzaF9zdG9wKHZvaWQpOworZXh0ZXJuIGJvb2wgc21wX2NyYXNoX3N0b3BfZmFpbGVkKHZvaWQp OwogCiAjZW5kaWYgLyogaWZuZGVmIF9fQVNTRU1CTFlfXyAqLwogCmRpZmYgLS1naXQgYS9hcmNo L2FybTY0L2tlcm5lbC9tYWNoaW5lX2tleGVjLmMgYi9hcmNoL2FybTY0L2tlcm5lbC9tYWNoaW5l X2tleGVjLmMKaW5kZXggNjhiOTZlYTEzYjRjLi4yOWUxY2Y4Y2NhOTUgMTAwNjQ0Ci0tLSBhL2Fy Y2gvYXJtNjQva2VybmVsL21hY2hpbmVfa2V4ZWMuYworKysgYi9hcmNoL2FybTY0L2tlcm5lbC9t YWNoaW5lX2tleGVjLmMKQEAgLTE0NiwxMiArMTQ2LDE1IEBAIHZvaWQgbWFjaGluZV9rZXhlYyhz dHJ1Y3Qga2ltYWdlICpraW1hZ2UpCiB7CiAJcGh5c19hZGRyX3QgcmVib290X2NvZGVfYnVmZmVy X3BoeXM7CiAJdm9pZCAqcmVib290X2NvZGVfYnVmZmVyOworCWJvb2wgaW5fa2V4ZWNfY3Jhc2gg PSAoa2ltYWdlID09IGtleGVjX2NyYXNoX2ltYWdlKTsKKwlib29sIHN0dWNrX2NwdXMgPSBjcHVz X2FyZV9zdHVja19pbl9rZXJuZWwoKTsKIAogCS8qCiAJICogTmV3IGNwdXMgbWF5IGhhdmUgYmVj b21lIHN0dWNrX2luX2tlcm5lbCBhZnRlciB3ZSBsb2FkZWQgdGhlIGltYWdlLgogCSAqLwotCUJV R19PTigoY3B1c19hcmVfc3R1Y2tfaW5fa2VybmVsKCkgfHwgKG51bV9vbmxpbmVfY3B1cygpID4g MSkpICYmCi0JCQkhV0FSTl9PTihraW1hZ2UgPT0ga2V4ZWNfY3Jhc2hfaW1hZ2UpKTsKKwlCVUdf T04oIWluX2tleGVjX2NyYXNoICYmIChzdHVja19jcHVzIHx8IChudW1fb25saW5lX2NwdXMoKSA+ IDEpKSk7CisJV0FSTihpbl9rZXhlY19jcmFzaCAmJiAoc3R1Y2tfY3B1cyB8fCBzbXBfY3Jhc2hf c3RvcF9mYWlsZWQoKSksCisJCSJTb21lIENQVXMgbWF5IGJlIHN0YWxlLCBrZHVtcCB3aWxsIGJl IHVucmVsaWFibGUuXG4iKTsKIAogCXJlYm9vdF9jb2RlX2J1ZmZlcl9waHlzID0gcGFnZV90b19w aHlzKGtpbWFnZS0+Y29udHJvbF9jb2RlX3BhZ2UpOwogCXJlYm9vdF9jb2RlX2J1ZmZlciA9IHBo eXNfdG9fdmlydChyZWJvb3RfY29kZV9idWZmZXJfcGh5cyk7CmRpZmYgLS1naXQgYS9hcmNoL2Fy bTY0L2tlcm5lbC9zbXAuYyBiL2FyY2gvYXJtNjQva2VybmVsL3NtcC5jCmluZGV4IGE3ZTI5MjEx NDNjNC4uODAxNjkxNDU5MWQyIDEwMDY0NAotLS0gYS9hcmNoL2FybTY0L2tlcm5lbC9zbXAuYwor KysgYi9hcmNoL2FybTY0L2tlcm5lbC9zbXAuYwpAQCAtODMzLDcgKzgzMyw3IEBAIHN0YXRpYyB2 b2lkIGlwaV9jcHVfc3RvcCh1bnNpZ25lZCBpbnQgY3B1KQogfQogCiAjaWZkZWYgQ09ORklHX0tF WEVDX0NPUkUKLXN0YXRpYyBhdG9taWNfdCB3YWl0aW5nX2Zvcl9jcmFzaF9pcGk7CitzdGF0aWMg YXRvbWljX3Qgd2FpdGluZ19mb3JfY3Jhc2hfaXBpID0gQVRPTUlDX0lOSVQoMCk7CiAjZW5kaWYK IAogc3RhdGljIHZvaWQgaXBpX2NwdV9jcmFzaF9zdG9wKHVuc2lnbmVkIGludCBjcHUsIHN0cnVj dCBwdF9yZWdzICpyZWdzKQpAQCAtOTkwLDcgKzk5MCwxMiBAQCB2b2lkIHNtcF9zZW5kX2NyYXNo X3N0b3Aodm9pZCkKIAogCWlmIChhdG9taWNfcmVhZCgmd2FpdGluZ19mb3JfY3Jhc2hfaXBpKSA+ IDApCiAJCXByX3dhcm5pbmcoIlNNUDogZmFpbGVkIHRvIHN0b3Agc2Vjb25kYXJ5IENQVXMgJSpw YmxcbiIsCi0JCQkgICBjcHVtYXNrX3ByX2FyZ3MoY3B1X29ubGluZV9tYXNrKSk7CisJCQkgICBj cHVtYXNrX3ByX2FyZ3MoJm1hc2spKTsKK30KKworYm9vbCBzbXBfY3Jhc2hfc3RvcF9mYWlsZWQo dm9pZCkKK3sKKwlyZXR1cm4gKGF0b21pY19yZWFkKCZ3YWl0aW5nX2Zvcl9jcmFzaF9pcGkpID4g MCk7CiB9CiAjZW5kaWYKPT09Pjg9PT0KCgoKSW4gY2FzZSBvZiBmYWlsdXJlIGluIG9mZmxpbmlu ZywgdGhpcyBjYW4gZ2VuZXJhdGUgc3VjaCBhIG1lc3NhZ2UgbGlrZToKCiAgICBTTVA6IHN0b3Bw aW5nIHNlY29uZGFyeSBDUFVzCiAgICBTTVA6IGZhaWxlZCB0byBzdG9wIHNlY29uZGFyeSBDUFVz IDAsMi03CiAgICBTdGFydGluZyBjcmFzaGR1bXAga2VybmVsLi4uCiAgICBTb21lIENQVXMgbWF5 IGJlIHN0YWxlLCBrZHVtcCB3aWxsIGJlIHVucmVsaWFibGUuCiAgICAtLS0tLS0tLS0tLS1bIGN1 dCBoZXJlIF0tLS0tLS0tLS0tLS0KICAgIFdBUk5JTkc6IENQVTogMSBQSUQ6IDExNDEgYXQgL2hv bWUvYWthc2hpL2FybS9hcm12OC9saW5hcm8vbGludXgtYWFyY2g2NC9hcmNoL2FybTY0L2tlcm5l bC9tYWNoaW5lX2tleGVjLmM6MTU3IG1hY2hpbmVfa2V4ZWMrMHg0NC8weDI4MAoKCj4gTG9va2lu ZyBhdCB0aGlzLCB0aGVyZSdzIGEgbGFyZ2VyIG1lc3MuCj4gCj4gVGhlIHdhaXRpbmdfZm9yX2Ny YXNoX2lwaSBkYW5jZSBvbmx5IHRlbGxzIHVzIGlmIENQVXMgaGF2ZSB0YWtlbiB0aGUKPiBJUEks IG5vdCB3ZXRoZXIgdGhleSd2ZSBiZWVuIG9mZmxpbmVkIChpLmUuIGFjdHVhbGx5IGxlZnQgdGhl IGtlcm5lbCkuCj4gV2UgbmVlZCBzb21ldGhpbmcgY2xvc2VyIHRvIHRoZSB1c3VhbCBjcHVfe2Rp c2FibGUsZGllLGtpbGx9IGRhbmNlLAo+IGNsZWFyaW5nIG9ubGluZSBhcyBhcHByb3ByaWF0ZS4K CkZpcnN0LCBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIG5vIHN1cmUgd2F5IHRvIGNvbmZpcm0gd2hl dGhlciBDUFVzCnN1Y2Nlc3NmdWxseSBsZWZ0IHRoZSBrZXJuZWwuCkV2ZW4gaWYgd2UgZG8gc29t ZXRoaW5nIGxpa2UgdGhpcyBpbiBpcGlfY3B1X2NyYXNoX3N0b3AoKToKICAgIGF0b21pY19kZWMo JndhaXRpbmdfZm9yX2NyYXNoX2lwaSk7CiAgICBjcHVfZGllKGNwdSk7CiAgICBhdG9taWNfaW5j KCZ3YWl0aW5nX2Zvcl9jcmFzaF9pcGkpOwp0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCB3ZSBy ZWFjaCB0aGUgc2Vjb25kIHVwZGF0ZV9jcHVfYm9vdF9zdGF0dXMoKQppbiBmYWlsdXJlIG9mIGNw dV9kaWUoKS4KClNlY29uZCwgd2hpbGUgImdyYWNlZnVsIiBjcHUgc2h1dGRvd24gd291bGQgYmUg ZmluZSwgdGhlIGJhc2ljIGlkZWEKaW4ga2R1bXAgZGVzaWduLCBJIGJlbGlldmUsIGlzIHRoYXQg d2Ugc2hvdWxkIGRvIG1pbmltdW0gdGhpbmdzIG5lZWRlZAphbmQgdGVhciBkb3duIGFsbCB0aGUg Y3B1cyBhcyBxdWlja2x5IGFzIHBvc3NpYmxlIGluIG9yZGVyIG5vdCBvbmx5IHRvIG1ha2UKdGhl IHJlYm9vdCBtb3JlIHN1Y2Nlc3NmdWwgYnV0IGFsc28gdG8gcmV0YWluIHRoZSBrZXJuZWwgc3Rh dGUgKG1lbW9yeSBjb250ZW50cykKYXMgY2xvc2UgYXMgdG8gdGhlIG1vbWVudCBhdCB0aGUgcGFu aWMuIChUaGUgbGF0dGVyIGlzIGFyZ3VhYmxlLikKClRoYXQgc2FpZCwgSSB3aWxsIGFwcHJlY2lh dGUgeW91IGlmIHlvdSBoYXZlIGFueSBzdWdnZXN0aW9ucwpyZWdhcmRpbmcgd2hhdCBiZSBhZGRl ZCBmb3Igc2FmZXIgc2h1dGRvd24gaGVyZS4KCgpUaGFua3MsCi1UYWthaGlybyBBS0FTSEkKCj4g SWYgQ1BVcyBoYXZlbid0IGxlZnQgdGhlIGtlcm5lbCwgd2Ugc3RpbGwgbmVlZCB0byB3YXJuIGFi b3V0IHRoYXQuCj4gCj4gPiBGV0lXIGlmIEkgdHJpZ2dlciBhIGNyYXNoIG9uIENQVSAxIG15IGtk dW1wIChzdGlsbCA0LjkuOCt2MzIpIGRvZXNuJ3Qgd29yay4KPiA+IEkgZW5kIHVwIGJvb3Rpbmcg dGhlIGtkdW1wIGtlcm5lbCBvbiBDUFUjMSBhbmQgdGhlbiBpdCBnZXRzIGRpc3RpbmN0bHkgdW5o YXBweS4uLgo+ID4gCj4gPiBbwqDCoMKgwqAwLjAwMDAwMF0gQm9vdGluZyBMaW51eCBvbiBwaHlz aWNhbCBDUFUgMHgxCj4gPiAuLi4KPiA+IFvCoMKgwqDCoDAuMDE3MTI1XSBEZXRlY3RlZCBQSVBU IEktY2FjaGUgb24gQ1BVMQo+ID4gW8KgwqDCoMKgMC4wMTcxMzhdIEdJQ3YzOiBDUFUxOiBmb3Vu ZCByZWRpc3RyaWJ1dG9yIDAgcmVnaW9uIDA6MHgwMDAwMDAwMGYwMjgwMDAwCj4gPiBbwqDCoMKg wqAwLjAxNzE0N10gQ1BVMTogQm9vdGVkIHNlY29uZGFyeSBwcm9jZXNzb3IgWzQxMWZkMDczXQo+ ID4gW8KgwqDCoMKgMC4wMTczMzldIERldGVjdGVkIFBJUFQgSS1jYWNoZSBvbiBDUFUyCj4gPiBb wqDCoMKgwqAwLjAxNzM0N10gR0lDdjM6IENQVTI6IGZvdW5kIHJlZGlzdHJpYnV0b3IgMiByZWdp b24gMDoweDAwMDAwMDAwZjAyYzAwMDAKPiA+IFvCoMKgwqDCoDAuMDE3MzU0XSBDUFUyOiBCb290 ZWQgc2Vjb25kYXJ5IHByb2Nlc3NvciBbNDExZmQwNzNdCj4gPiBbwqDCoMKgwqAwLjAxNzUzN10g RGV0ZWN0ZWQgUElQVCBJLWNhY2hlIG9uIENQVTMKPiA+IFvCoMKgwqDCoDAuMDE3NTQ1XSBHSUN2 MzogQ1BVMzogZm91bmQgcmVkaXN0cmlidXRvciAzIHJlZ2lvbiAwOjB4MDAwMDAwMDBmMDJlMDAw MAo+ID4gW8KgwqDCoMKgMC4wMTc1NTFdIENQVTM6IEJvb3RlZCBzZWNvbmRhcnkgcHJvY2Vzc29y IFs0MTFmZDA3M10KPiA+IFvCoMKgwqDCoDAuMDE3NTc2XSBCcm91Z2h0IHVwIDQgQ1BVcwo+ID4g W8KgwqDCoMKgMC4wMTc1ODddIFNNUDogVG90YWwgb2YgNCBwcm9jZXNzb3JzIGFjdGl2YXRlZC4K PiA+IC4uLgo+ID4gW8KgwqDCoDMxLjc0NTgwOV0gSU5GTzogcmN1X3NjaGVkIGRldGVjdGVkIHN0 YWxscyBvbiBDUFVzL3Rhc2tzOgo+ID4gW8KgwqDCoDMxLjc1MTI5OV3CoAkxLS4uLjogKDMwIEdQ cyBiZWhpbmQpIGlkbGU9YzkwLzAvMCBzb2Z0aXJxPTAvMCBmcXM9MMKgCj4gPiBbwqDCoMKgMzEu NzU3NTU3XcKgCTItLi4uOiAoMzAgR1BzIGJlaGluZCkgaWRsZT02MDgvMC8wIHNvZnRpcnE9MC8w IGZxcz0wwqAKPiA+IFvCoMKgwqAzMS43NjM4MTRdwqAJMy0uLi46ICgzMCBHUHMgYmVoaW5kKSBp ZGxlPTYwNC8wLzAgc29mdGlycT0wLzAgZnFzPTDCoAo+ID4gW8KgwqDCoDMxLjc3MDA2OV3CoAko ZGV0ZWN0ZWQgYnkgMCwgdD01MjUyIGppZmZpZXMsIGc9LTI3MCwgYz0tMjcxLCBxPTApCj4gPiBb wqDCoMKgMzEuNzc2MTYxXSBUYXNrIGR1bXAgZm9yIENQVSAxOgo+ID4gW8KgwqDCoDMxLjc3OTM4 MV0gc3dhcHBlci8xwqDCoMKgwqDCoMKgwqBSwqDCoHJ1bm5pbmcgdGFza8KgwqDCoMKgwqDCoMKg wqAwwqDCoMKgwqDCoDDCoMKgwqDCoMKgwqAxIDB4MDAwMDAwODAKPiA+IFvCoMKgwqAzMS43ODY0 NDZdIFRhc2sgZHVtcCBmb3IgQ1BVIDI6Cj4gPiBbwqDCoMKgMzEuNzg5NjY2XSBzd2FwcGVyLzLC oMKgwqDCoMKgwqDCoFLCoMKgcnVubmluZyB0YXNrwqDCoMKgwqDCoMKgwqDCoDDCoMKgwqDCoMKg MMKgwqDCoMKgwqDCoDEgMHgwMDAwMDA4MAo+ID4gW8KgwqDCoDMxLjc5NjcyNV0gVGFzayBkdW1w IGZvciBDUFUgMzoKPiA+IFvCoMKgwqAzMS43OTk5NDVdIHN3YXBwZXIvM8KgwqDCoMKgwqDCoMKg UsKgwqBydW5uaW5nIHRhc2vCoMKgwqDCoMKgwqDCoMKgMMKgwqDCoMKgwqAwwqDCoMKgwqDCoMKg MSAweDAwMDAwMDgwCj4gPiAKPiA+IElzIHNvbWUgb2YgdGhhdCBwbGF0Zm9ybS1zcGVjaWZpYz8K PiAKPiBUaGF0IHNvdW5kcyBsaWtlIHRpbWVyIGludGVycnVwdHMgYXJlbid0IGJlaW5nIHRha2Vu Lgo+IAo+IEdpdmVuIHRoYXQgdGhlIENQVXMgaGF2ZSBjb21lIHVwLCBteSBzdXNwaWNpb24gd291 bGQgYmUgdGhhdCB0aGUgR0lDJ3MKPiBiZWVuIGxlZnQgaW4gc29tZSBvZGQgc3RhdGUsIHRoYXQg dGhlIGtkdW1wIGtlcm5lbCBoYXNuJ3QgbWFuYWdlZCB0bwo+IHJlY292ZXIgZnJvbS4KPiAKPiBN YXJjIG1heSBoYXZlIGFuIGlkZWEuCj4gCj4gVGhhbmtzLAo+IE1hcmsuCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwprZXhlYyBtYWlsaW5nIGxpc3QKa2V4 ZWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2tleGVjCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: takahiro.akashi@linaro.org (AKASHI Takahiro) Date: Tue, 21 Mar 2017 16:34:53 +0900 Subject: [PATCH v33 00/14] add kdump support In-Reply-To: <20170317162421.GK5940@leverpostej> References: <20170315095656.24992-1-takahiro.akashi@linaro.org> <1489750991.17202.40.camel@infradead.org> <1489759373.17202.44.camel@infradead.org> <20170317153358.GI5940@leverpostej> <1489765628.17202.59.camel@infradead.org> <20170317162421.GK5940@leverpostej> Message-ID: <20170321073452.GA17298@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Mar 17, 2017 at 04:24:21PM +0000, Mark Rutland wrote: > On Fri, Mar 17, 2017 at 03:47:08PM +0000, David Woodhouse wrote: > > On Fri, 2017-03-17 at 15:33 +0000, Mark Rutland wrote: > > No, in this case the CPUs *were* offlined correctly, or at least "as > > designed", by smp_send_crash_stop(). And if that hadn't worked, as > > verified by *its* synchronisation method based on the atomic_t > > waiting_for_crash_ipi, then *it* would have complained for itself: > > > > if (atomic_read(&waiting_for_crash_ipi) > 0) > > pr_warning("SMP: failed to stop secondary CPUs %*pbl\n", > > ???cpumask_pr_args(cpu_online_mask)); > > > > It's just that smp_send_crash_stop() (or more specifically > > ipi_cpu_crash_stop()) doesn't touch the online cpu mask. Unlike the > > ARM32 equivalent function machien_crash_nonpanic_core(), which does. > > > > It wasn't clear if that was *intentional*, to allow the original > > contents of the online mask before the crash to be seen in the > > resulting vmcore... or purely an accident.? Yes, it is intentional. I removed 'offline' code in my v14 (2016/3/4). As you assumed, I'd expect 'online' status of all CPUs to be kept unchanged in the core dump. If you can agree, I would like to modify this disputed warning code to: ===8<=== diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h index cea009f2657d..55f08c5acfad 100644 --- a/arch/arm64/include/asm/smp.h +++ b/arch/arm64/include/asm/smp.h @@ -149,6 +149,7 @@ static inline void cpu_panic_kernel(void) bool cpus_are_stuck_in_kernel(void); extern void smp_send_crash_stop(void); +extern bool smp_crash_stop_failed(void); #endif /* ifndef __ASSEMBLY__ */ diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c index 68b96ea13b4c..29e1cf8cca95 100644 --- a/arch/arm64/kernel/machine_kexec.c +++ b/arch/arm64/kernel/machine_kexec.c @@ -146,12 +146,15 @@ void machine_kexec(struct kimage *kimage) { phys_addr_t reboot_code_buffer_phys; void *reboot_code_buffer; + bool in_kexec_crash = (kimage == kexec_crash_image); + bool stuck_cpus = cpus_are_stuck_in_kernel(); /* * New cpus may have become stuck_in_kernel after we loaded the image. */ - BUG_ON((cpus_are_stuck_in_kernel() || (num_online_cpus() > 1)) && - !WARN_ON(kimage == kexec_crash_image)); + BUG_ON(!in_kexec_crash && (stuck_cpus || (num_online_cpus() > 1))); + WARN(in_kexec_crash && (stuck_cpus || smp_crash_stop_failed()), + "Some CPUs may be stale, kdump will be unreliable.\n"); reboot_code_buffer_phys = page_to_phys(kimage->control_code_page); reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys); diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index a7e2921143c4..8016914591d2 100644 --- a/arch/arm64/kernel/smp.c +++ b/arch/arm64/kernel/smp.c @@ -833,7 +833,7 @@ static void ipi_cpu_stop(unsigned int cpu) } #ifdef CONFIG_KEXEC_CORE -static atomic_t waiting_for_crash_ipi; +static atomic_t waiting_for_crash_ipi = ATOMIC_INIT(0); #endif static void ipi_cpu_crash_stop(unsigned int cpu, struct pt_regs *regs) @@ -990,7 +990,12 @@ void smp_send_crash_stop(void) if (atomic_read(&waiting_for_crash_ipi) > 0) pr_warning("SMP: failed to stop secondary CPUs %*pbl\n", - cpumask_pr_args(cpu_online_mask)); + cpumask_pr_args(&mask)); +} + +bool smp_crash_stop_failed(void) +{ + return (atomic_read(&waiting_for_crash_ipi) > 0); } #endif ===>8=== In case of failure in offlining, this can generate such a message like: SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 0,2-7 Starting crashdump kernel... Some CPUs may be stale, kdump will be unreliable. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1141 at /home/akashi/arm/armv8/linaro/linux-aarch64/arch/arm64/kernel/machine_kexec.c:157 machine_kexec+0x44/0x280 > Looking at this, there's a larger mess. > > The waiting_for_crash_ipi dance only tells us if CPUs have taken the > IPI, not wether they've been offlined (i.e. actually left the kernel). > We need something closer to the usual cpu_{disable,die,kill} dance, > clearing online as appropriate. First, I don't think there is no sure way to confirm whether CPUs successfully left the kernel. Even if we do something like this in ipi_cpu_crash_stop(): atomic_dec(&waiting_for_crash_ipi); cpu_die(cpu); atomic_inc(&waiting_for_crash_ipi); there is no guarantee that we reach the second update_cpu_boot_status() in failure of cpu_die(). Second, while "graceful" cpu shutdown would be fine, the basic idea in kdump design, I believe, is that we should do minimum things needed and tear down all the cpus as quickly as possible in order not only to make the reboot more successful but also to retain the kernel state (memory contents) as close as to the moment at the panic. (The latter is arguable.) That said, I will appreciate you if you have any suggestions regarding what be added for safer shutdown here. Thanks, -Takahiro AKASHI > If CPUs haven't left the kernel, we still need to warn about that. > > > FWIW if I trigger a crash on CPU 1 my kdump (still 4.9.8+v32) doesn't work. > > I end up booting the kdump kernel on CPU#1 and then it gets distinctly unhappy... > > > > [????0.000000] Booting Linux on physical CPU 0x1 > > ... > > [????0.017125] Detected PIPT I-cache on CPU1 > > [????0.017138] GICv3: CPU1: found redistributor 0 region 0:0x00000000f0280000 > > [????0.017147] CPU1: Booted secondary processor [411fd073] > > [????0.017339] Detected PIPT I-cache on CPU2 > > [????0.017347] GICv3: CPU2: found redistributor 2 region 0:0x00000000f02c0000 > > [????0.017354] CPU2: Booted secondary processor [411fd073] > > [????0.017537] Detected PIPT I-cache on CPU3 > > [????0.017545] GICv3: CPU3: found redistributor 3 region 0:0x00000000f02e0000 > > [????0.017551] CPU3: Booted secondary processor [411fd073] > > [????0.017576] Brought up 4 CPUs > > [????0.017587] SMP: Total of 4 processors activated. > > ... > > [???31.745809] INFO: rcu_sched detected stalls on CPUs/tasks: > > [???31.751299]? 1-...: (30 GPs behind) idle=c90/0/0 softirq=0/0 fqs=0? > > [???31.757557]? 2-...: (30 GPs behind) idle=608/0/0 softirq=0/0 fqs=0? > > [???31.763814]? 3-...: (30 GPs behind) idle=604/0/0 softirq=0/0 fqs=0? > > [???31.770069]? (detected by 0, t=5252 jiffies, g=-270, c=-271, q=0) > > [???31.776161] Task dump for CPU 1: > > [???31.779381] swapper/1???????R??running task????????0?????0??????1 0x00000080 > > [???31.786446] Task dump for CPU 2: > > [???31.789666] swapper/2???????R??running task????????0?????0??????1 0x00000080 > > [???31.796725] Task dump for CPU 3: > > [???31.799945] swapper/3???????R??running task????????0?????0??????1 0x00000080 > > > > Is some of that platform-specific? > > That sounds like timer interrupts aren't being taken. > > Given that the CPUs have come up, my suspicion would be that the GIC's > been left in some odd state, that the kdump kernel hasn't managed to > recover from. > > Marc may have an idea. > > Thanks, > Mark.