From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fMItA-0001MW-9g for kexec@lists.infradead.org; Fri, 25 May 2018 20:00:38 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <20180521025337.GA4627@dhcp-128-65.nay.redhat.com> <20180521120215.117d963a7619eb0d1f54bced@linux-foundation.org> <20180523070641.GA1689@dhcp-128-65.nay.redhat.com> <877enucqr0.fsf@xmission.com> <20180523222236.5a96732e@ezekiel.suse.cz> <20180524014905.GB2031@dhcp-128-65.nay.redhat.com> <20180524085708.31aa311d@ezekiel.suse.cz> <87k1rt3tdu.fsf@xmission.com> <20180525065943.03bcb911@ezekiel.suse.cz> Date: Fri, 25 May 2018 15:00:13 -0500 In-Reply-To: <20180525065943.03bcb911@ezekiel.suse.cz> (Petr Tesarik's message of "Fri, 25 May 2018 06:59:43 +0200") Message-ID: <87d0xjwlo2.fsf@xmission.com> MIME-Version: 1.0 Subject: Re: [PATCH] kdump: add default crashkernel reserve kernel config options 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: Petr Tesarik Cc: dzickus@redhat.com, Neil Horman , Tony Luck , bhe@redhat.com, Michael Ellerman , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Hari Bathini , Benjamin Herrenschmidt , Martin Schwidefsky , Cong Wang , Andrew Morton , Dave Young , Ingo Molnar , Vivek Goyal UGV0ciBUZXNhcmlrIDxwdGVzYXJpa0BzdXNlLmN6PiB3cml0ZXM6Cgo+IFYgVGh1LCAyNCBNYXkg MjAxOCAxMTozNDowNSAtMDUwMAo+IGViaWVkZXJtQHhtaXNzaW9uLmNvbSAoRXJpYyBXLiBCaWVk ZXJtYW4pIG5hcHPDoW5vOgo+Cj4+IFBldHIgVGVzYXJpayA8cHRlc2FyaWtAc3VzZS5jej4gd3Jp dGVzOgo+PiAKPj4gMj4gT24gVGh1LCAyNCBNYXkgMjAxOCAwOTo0OTowNSArMDgwMAo+PiA+IERh dmUgWW91bmcgPGR5b3VuZ0ByZWRoYXQuY29tPiB3cm90ZToKPj4gPiAgCj4+ID4+IEhpIFBldHIs Cj4+ID4+IAo+PiA+PiBPbiAwNS8yMy8xOCBhdCAxMDoyMnBtLCBQZXRyIFRlc2FyaWsgd3JvdGU6 Cj4+ID4+Wy4uLl0gIAo+PiA+PiA+IEluIHNob3J0LCBpZiBvbmUgc2l6ZSBmaXRzIG5vbmUsIHdo YXQgZ29vZCBpcyBpdCB0byBoYXJkY29kZSB0aGF0ICJvbmUKPj4gPj4gPiBzaXplIiBpbnRvIHRo ZSBrZXJuZWwgaW1hZ2U/ICAgIAo+PiA+PiAKPj4gPj4gSSBhZ3JlZWQgd2l0aCBhbGwgdGhlIHRo aW5ncyB0aGF0IHdlIGNhbiBub3Qga25vdyB0aGUgZXhhY3QgbWVtb3J5Cj4+ID4+IHJlcXVpcmVt ZW50IGZvciAxMDAlIHVzZSBjYXNlcy4gIEJ1dCB0aGF0IGRvZXMgbm90IG1lYW5zIHRoaXMgaXMg dXNlbGVzcwo+PiA+PiBpdCBpcyBzdGlsbCB1c2VmdWwgZm9yIGNvbW1vbiB1c2UgY2FzZXMgb2Yg bm8gc3BlY2lhbCBhbmQgbWVtb3J5IGhvZwo+PiA+PiByZXF1aXJlbWVudHMgYXMgSSBtZW50aW9u ZWQgaW4gYW5vdGhlciByZXBseSBpdCBjYW4gc2ltcGxpZnkgdGhlIGtkdW1wCj4+ID4+IGRlcGxv eW1lbnQgZm9yIHRob3NlIHBlb3BsZSB3aG8gZG8gbm90IG5lZWQgdGhlIHNwZWNpYWwgc2V0dXAu ICAKPj4gPgo+PiA+IEkgc3RpbGwgdGVuZCB0byBkaXNhZ3JlZS4gVGhpcyAiY29tbW9uLWNhc2Ui IHJlc2VydmF0aW9uIGRlcGVuZHMgb24KPj4gPiB0aGluZ3MgdGhhdCBhcmUgZGVmaW5lZCBieSB1 c2VyIHNwYWNlLiBJdCBzdXJlbHkgZG9lcyBub3QgbWFrZSBpdAo+PiA+IGVhc2llciB0byBidWls ZCBhIGRpc3RyaWJ1dGlvbiBrZXJuZWwuIFRvZGF5LCBJIGdldCBidWcgcmVwb3J0cyB0aGF0Cj4+ ID4gdGhlIG51bWJlciBjYWxjdWxhdGVkIGFuZCBhZGRlZCB0byB0aGUgYm9vdCBsb2FkZXIgY29u ZmlndXJhdGlvbiBieSB0aGUKPj4gPiBpbnN0YWxsZXIgaXMgaW5hY2N1cmF0ZS4gSWYgSSBwdXQg YSBmaXhlZCBudW1iZXIgaW50byBhIGtlcm5lbCBjb25maWcKPj4gPiBvcHRpb24sIEkgd2lsbCBz dGFydCBnZXR0aW5nIGJ1Z3MgdGhhdCB0aGlzIG51bWJlciBpcyBpbmNvcnJlY3QgKGZvcgo+PiA+ IHNvbWUgc3lzdGVtcykuCj4+ID4gIAo+PiA+PiBGb3IgZXhhbXBsZSwgaWYgdGhpcyBpcyBhIHdv cmtzdGF0aW9uIEkganVzdCB3YW50IHRvIGJyZWFrIGludG8gYSBzaGVsbAo+PiA+PiB0byBjb2xs ZWN0IHNvbWUgcGFuaWMgaW5mbywgdGhlbiBJIGp1c3QgbmVlZCBhIHZlcnkgbWluaW1hbCBpbml0 cmQsIHRoZW4KPj4gPj4gdGhlIEtjb25maWcgd2lsbCB3b3JrIGp1c3QgZmluZS4gIAo+PiA+Cj4+ ID4gV2hhdCBpcyAiYSB2ZXJ5IG1pbmltYWwgaW5pdHJkIj8gTGFzdCB0aW1lIEkgaGFkIHRvIG1h a2UgYSBzaWduaWZpY2FudAo+PiA+IGFkanVzdG1lbnQgdG8gdGhlIGVzdGltYXRpb24gZm9yIG9w ZW5TVVNFLCB0aGlzIHdhcyBjYXVzZWQgYnkgZ3Jvd2luZwo+PiA+IHVzZXItc3BhY2UgcmVxdWly ZW1lbnRzIChzeXN0ZW1kIGluIHRoaXMgY2FzZSwgYnV0IEkgZG9uJ3Qgd2FudCB0bwo+PiA+IHN0 YXJ0IGZsYW1ld2FycyBvbiB0aGF0IHRvcGljLCBwbGVhc2UpLgo+PiA+Cj4+ID4gQW55d2F5LCBp ZiB5b3Ugd2FudCB0byBpbXByb3ZlIHRoZSAiY29tbW9uIGNhc2UiLCB0aGVuIGxvb2sgaG93IElC TQo+PiA+IHRyaWVzIHRvIHNvbHZlIGl0IGZvciBmaXJtd2FyZS1hc3Npc3RlZCBkdW1wIChmYWR1 bXApIG9uIHBvd2VycGM6Cj4+ID4KPj4gPiBodHRwczovL3BhdGNod29yay5vemxhYnMub3JnL3Bh dGNoLzkwNTAyNi8KPj4gPgo+PiA+IFRoZSBtYWluIGlkZWEgaXM6Cj4+ID4gIAo+PiA+PiBJbnN0 ZWFkIG9mIHNldHRpbmcgYXNpZGUgYSBzaWduaWZpY2FudCBjaHVuayBvZiBtZW1vcnkgbm9ib2R5 IGNhbiB1c2UsCj4+ID4+IFsuLi5dIHJlc2VydmUgYSBzaWduaWZpY2FudCBjaHVuayBvZiBtZW1v cnkgdGhhdCB0aGUga2VybmVsIGlzIHByZXZlbnRlZAo+PiA+PiBmcm9tIHVzaW5nIFsuLi5dLCBi dXQgYXBwbGljYXRpb25zIGFyZSBmcmVlIHRvIHVzZSBpdC4gIAo+PiA+Cj4+ID4gVGhhdCB3b3Jr cyBncmVhdCwgYmVjYXVzZSB1c2VyIHNwYWNlIHBhZ2VzIGFyZSBmaWx0ZXJlZCBvdXQgaW4gdGhl Cj4+ID4gY29tbW9uIGNhc2UsIHNvIHRoZXkgY2FuIGJlIHVzZWQgZnJlZWx5IGJ5IHRoZSBwYW5p YyBrZXJuZWwuICAKPj4gCj4+IFRoZXkgYWJzb2x1dGVseSBjYW4gbm90IGJlIHVzZWQgaW4gdGhl IGtkdW1wIGNhc2UuCj4+IAo+PiBUaGUga2R1bXAgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGV5IGFy ZSBwYWdlcyBuby1vbmUgaW5pdGlhdGVzIGFueSBJL08KPj4gdG8uICBUbyBhdm9pZCB0aGUgcHJv YmxlbSBvZiBkZXZpY2VzIGRvaW5nIERNQSBhcyB0aGUgbmV3IGtlcm5lbCBzdGFydHMKPj4gYW5k IHJ1bnMuCj4KPiBHb29kIHBvaW50LiBUaGlzIG1lYW5zIHRoYXQgbWVtb3J5IHJlc2VydmVkIGZv ciB0aGlzIHB1cnBvc2Ugd291bGQgYWxzbwo+IGhhdmUgdG8gYmUgZXhjbHVkZWQgZnJvbSBhbGxv Y2F0aW9ucyB0aGF0IG1heSBiZSBldmVudHVhbGx5IHVzZWQgZm9yCj4gRE1BIHRyYW5zZmVycy4K ClRoaW5rIG9mIGEgbmV0d29yayBjYXJkLiAgVGhlIERNQSdzIGZvciBpbmNvbW1pbmcgcGFja2V0 cyBjYW4gYmUKaW5kZWZpbml0ZWx5IGRlbGF5ZWQgaW50byB0aGUgZnV0dXJlIHVubGVzcyB0aGF0 IG5ldHdvcmsgY2FyZCBpcwpyZXByb2dyYW1tZWQuICBJZiB0aGUgZHVtcCBrZXJuZWwgZG9lcyBu b3QgbG9hZCB0aGUgZHJpdmVyIHRoYXQgd29uJ3QKaGFwcGVuLgoKPj4gIFNlY29uZGFyaWx5IHRv IGF2b2lkIHByb2JsZW1zIHdpdGggY3B1cyB0aGF0IHJlZnVzZWQgdG8gaGFsdC4KPgo+IExldCdz IGZhY2UgaXQgLSBpZiBzb21lIENQVXMgcmVmdXNlZCB0byBoYWx0LCBhbGwgYmV0cyBhcmUgb2Zm LiBUaGUKPiBjb2RlIHJ1bm5pbmcgb24gc3VjaCBhIENQVSBjYW4gYnJlYWsgbWFueSBvdGhlciB0 aGluZ3MgYmVzaWRlcyBtZW1vcnksCj4gbW9zdCBpbXBvcnRhbnRseSwgaXQgbWF5IG1lZGRsZSB3 aXRoIHRoZSBIVyByZWdpc3RlcnMgb2YgY3J1Y2lhbAo+IGRldmljZXMgaW4gdGhlIHN5c3RlbS4g VG8gYmUgbGVzcyBhYnN0cmFjdCwgSSBoYXZlIHNlZW4gYSBmYWlsdXJlIHRvCj4gc3RvcCBhIENQ VSBpbiB0aGUgY3Jhc2hlZCBrZXJuZWwgYSBmZXcgdGltZXMsIGFuZCB0aGUgcGFuaWMga2VybmVs Cj4gY291bGQgbmV2ZXIgc3VjY2Vzc2Z1bGx5IHNhdmUgYW55dGhpbmc7IGl0IGFsd2F5cyBjcmFz aGVkIGF0IGJvb3Qgb3IgYQo+IGxpdHRsZSBiaXQgbGF0ZXIuCgpDcmFzaGluZyBhdCBib290IGlz IGNvbXBhcmF0aXZlbHkgZ29vZC4gIFRoYXQgaXMgcGFydCBvZiB0aGUgZGVzaWduCmNyaXRlcmlh LiAgSXQgaXMgYmV0dGVyIHRvIGZhaWwgdG8gc3RhcnR1cCB0aGUga2VybmVsIHRoYW4gdG8gc3Rh cnQgYQpjb3JydXB0ZWQga2VybmVsIGFuZCBtYW5nbGUgYSB1c2VycyBkYXRhLgoKQnV0IEkgZG8g c2VlIGhvdyBpdCBjYW4gYmUgYSBjcmFwIHNob290IHdoZW4gZGVhbGluZyB3aXRoIGFub3RoZXIg Y3B1LgoKVGhlIHVsdGltYXRlIHBvaW50IGlzIHRoYXQgdGhlIGFic29sdXRlIGJlc3Qgd2UgY2Fu IGRvIGlzIHRvIHJ1biBhCmtlcm5lbCBpbiBtZW1vcnkgdGhhdCB3ZSBuZXZlciB1c2UgZm9yIGFu eXRoaW5nIGVsc2UgYW5kIHRoZW4gd2UgaGF2ZSBhCmZpZ2h0aW5nIGNoYW5jZSBvZiBnZXR0aW5n IHRoZSBzeXN0ZW0gd29ya2luZyBhbmQgZ2V0dGluZyBhIHJlcG9ydCBvZgp0aGUgZmFpbHVyZSBv dXQgdG8gc29tZXdoZXJlLgoKPiBBbnl3YXksIG9mIGNvdXJzZSB3ZSB3b3VsZCBzdGlsbCBoYXZl IHRvIGtlZXAgdGhlIGN1cnJlbnQgbWV0aG9kLAo+IGJlY2F1c2UgdXNlciBwYWdlcyBhcmUgbm90 IGFsd2F5cyBmaWx0ZXJlZC4gRm9yIGV4YW1wbGUsIGEgbWFqb3IgU1VTRQo+IGFjY291bnQgcnVu cyBhIGRhdGFiYXNlIGluIHVzZXIgc3BhY2UgYW5kIGFsc28gaW5zcGVjdHMgaXRzIGRhdGEKPiBz dHJ1Y3R1cmVzIGluIGNhc2Ugb2YgYSBzeXN0ZW0gY3Jhc2guCgpBbmQgSSB1bmRlcnN0YW5kIHRo ZSBtZW1vcnkgcHJlc3N1cmVzIHRoYXQgd2lsbCBlbmNvdXJhZ2UgcGVvcGxlIHRvIHVzZQp1c2Vy IHBhZ2VzIGZvciBleHRyYSBtZW1vcnkgdG8gcnVuIHRoZSBkdW1wIGNhcHR1cmUga2VybmVsIGlu LiAgU2hvcnQgb2YKdGhlIHByZXNlbmNlIG9mIGFuIElPTU1VIHRoYXQgYWxsIERNQSB0cmFuc2Zl cnMgbXVzdCBnbyB0aHJvdWdoIEkgZG9uJ3QKc2VlIGhvdyB0aG9zZSB1c2VyIHBhZ2VzIGNvdWxk IHJlbGlhYmx5IGJlIHVzZWQuCgpFcmljCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmtleGVjIG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5pbmZyYWRl YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8va2V4ZWMK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968214AbeEYUA1 convert rfc822-to-8bit (ORCPT ); Fri, 25 May 2018 16:00:27 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:47114 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967858AbeEYUA0 (ORCPT ); Fri, 25 May 2018 16:00:26 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Petr Tesarik Cc: Dave Young , dzickus@redhat.com, Neil Horman , Tony Luck , bhe@redhat.com, Michael Ellerman , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Martin Schwidefsky , Benjamin Herrenschmidt , Hari Bathini , Cong Wang , Andrew Morton , Ingo Molnar , Vivek Goyal References: <20180521025337.GA4627@dhcp-128-65.nay.redhat.com> <20180521120215.117d963a7619eb0d1f54bced@linux-foundation.org> <20180523070641.GA1689@dhcp-128-65.nay.redhat.com> <877enucqr0.fsf@xmission.com> <20180523222236.5a96732e@ezekiel.suse.cz> <20180524014905.GB2031@dhcp-128-65.nay.redhat.com> <20180524085708.31aa311d@ezekiel.suse.cz> <87k1rt3tdu.fsf@xmission.com> <20180525065943.03bcb911@ezekiel.suse.cz> Date: Fri, 25 May 2018 15:00:13 -0500 In-Reply-To: <20180525065943.03bcb911@ezekiel.suse.cz> (Petr Tesarik's message of "Fri, 25 May 2018 06:59:43 +0200") Message-ID: <87d0xjwlo2.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1fMIsx-00062Z-96;;;mid=<87d0xjwlo2.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.174.25;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18bHhnQsqFjfCBp6MC/X/zQCyYv0kSf2AU= X-SA-Exim-Connect-IP: 97.119.174.25 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Petr Tesarik X-Spam-Relay-Country: X-Spam-Timing: total 1043 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.4 (0.2%), b_tie_ro: 1.69 (0.2%), parse: 0.82 (0.1%), extract_message_metadata: 14 (1.4%), get_uri_detail_list: 2.6 (0.3%), tests_pri_-1000: 8 (0.8%), tests_pri_-950: 0.99 (0.1%), tests_pri_-900: 0.81 (0.1%), tests_pri_-400: 30 (2.9%), check_bayes: 29 (2.8%), b_tokenize: 9 (0.9%), b_tok_get_all: 11 (1.1%), b_comp_prob: 3.1 (0.3%), b_tok_touch_all: 3.3 (0.3%), b_finish: 0.55 (0.1%), tests_pri_0: 293 (28.1%), check_dkim_signature: 0.49 (0.0%), check_dkim_adsp: 3.6 (0.3%), tests_pri_500: 691 (66.2%), poll_dns_idle: 686 (65.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] kdump: add default crashkernel reserve kernel config options X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Petr Tesarik writes: > V Thu, 24 May 2018 11:34:05 -0500 > ebiederm@xmission.com (Eric W. Biederman) napsáno: > >> Petr Tesarik writes: >> >> 2> On Thu, 24 May 2018 09:49:05 +0800 >> > Dave Young wrote: >> > >> >> Hi Petr, >> >> >> >> On 05/23/18 at 10:22pm, Petr Tesarik wrote: >> >>[...] >> >> > In short, if one size fits none, what good is it to hardcode that "one >> >> > size" into the kernel image? >> >> >> >> I agreed with all the things that we can not know the exact memory >> >> requirement for 100% use cases. But that does not means this is useless >> >> it is still useful for common use cases of no special and memory hog >> >> requirements as I mentioned in another reply it can simplify the kdump >> >> deployment for those people who do not need the special setup. >> > >> > I still tend to disagree. This "common-case" reservation depends on >> > things that are defined by user space. It surely does not make it >> > easier to build a distribution kernel. Today, I get bug reports that >> > the number calculated and added to the boot loader configuration by the >> > installer is inaccurate. If I put a fixed number into a kernel config >> > option, I will start getting bugs that this number is incorrect (for >> > some systems). >> > >> >> For example, if this is a workstation I just want to break into a shell >> >> to collect some panic info, then I just need a very minimal initrd, then >> >> the Kconfig will work just fine. >> > >> > What is "a very minimal initrd"? Last time I had to make a significant >> > adjustment to the estimation for openSUSE, this was caused by growing >> > user-space requirements (systemd in this case, but I don't want to >> > start flamewars on that topic, please). >> > >> > Anyway, if you want to improve the "common case", then look how IBM >> > tries to solve it for firmware-assisted dump (fadump) on powerpc: >> > >> > https://patchwork.ozlabs.org/patch/905026/ >> > >> > The main idea is: >> > >> >> Instead of setting aside a significant chunk of memory nobody can use, >> >> [...] reserve a significant chunk of memory that the kernel is prevented >> >> from using [...], but applications are free to use it. >> > >> > That works great, because user space pages are filtered out in the >> > common case, so they can be used freely by the panic kernel. >> >> They absolutely can not be used in the kdump case. >> >> The kdump requirement is that they are pages no-one initiates any I/O >> to. To avoid the problem of devices doing DMA as the new kernel starts >> and runs. > > Good point. This means that memory reserved for this purpose would also > have to be excluded from allocations that may be eventually used for > DMA transfers. Think of a network card. The DMA's for incomming packets can be indefinitely delayed into the future unless that network card is reprogrammed. If the dump kernel does not load the driver that won't happen. >> Secondarily to avoid problems with cpus that refused to halt. > > Let's face it - if some CPUs refused to halt, all bets are off. The > code running on such a CPU can break many other things besides memory, > most importantly, it may meddle with the HW registers of crucial > devices in the system. To be less abstract, I have seen a failure to > stop a CPU in the crashed kernel a few times, and the panic kernel > could never successfully save anything; it always crashed at boot or a > little bit later. Crashing at boot is comparatively good. That is part of the design criteria. It is better to fail to startup the kernel than to start a corrupted kernel and mangle a users data. But I do see how it can be a crap shoot when dealing with another cpu. The ultimate point is that the absolute best we can do is to run a kernel in memory that we never use for anything else and then we have a fighting chance of getting the system working and getting a report of the failure out to somewhere. > Anyway, of course we would still have to keep the current method, > because user pages are not always filtered. For example, a major SUSE > account runs a database in user space and also inspects its data > structures in case of a system crash. And I understand the memory pressures that will encourage people to use user pages for extra memory to run the dump capture kernel in. Short of the presence of an IOMMU that all DMA transfers must go through I don't see how those user pages could reliably be used. Eric