All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mitsuhiro Tanino <mitsuhiro.tanino.gm@hitachi.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [Patch 0/2] Exclude hwpoison page from vmcore dump
Date: Thu, 01 Nov 2012 19:32:45 +0900	[thread overview]
Message-ID: <50924FCD.2020100@hitachi.com> (raw)
In-Reply-To: <20121031141426.GE1865@redhat.com>

Hi Vivek,

(2012/10/31 23:14), Vivek Goyal wrote:
> If hwpoision functionality is not available in hardware, then respective
> bit will not be even set in struct page and it will be saved by default.
> So it should not matter whether hardware has hwpoision functionality
> or not.

Thanks, I understand.

> I think that removing hwpoisno pages by default makes sense. If somebody
> does have a reasonable case of not doing so, then we could either
> introduce anther filtering level (based on type) or add another command
> line option like (--no-hwposion-filtering) etc.

I agree with you.
If somebody requests to support for disabling the filter of hwpoison pages,
this option will be discussed.

Regards,
Mitshuhiro Tanino (mitsuhiro.tanino.gm@hitachi.com)


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Mitsuhiro Tanino <mitsuhiro.tanino.gm@hitachi.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [Patch 0/2] Exclude hwpoison page from vmcore dump
Date: Thu, 01 Nov 2012 19:32:45 +0900	[thread overview]
Message-ID: <50924FCD.2020100@hitachi.com> (raw)
In-Reply-To: <20121031141426.GE1865@redhat.com>

Hi Vivek,

(2012/10/31 23:14), Vivek Goyal wrote:
> If hwpoision functionality is not available in hardware, then respective
> bit will not be even set in struct page and it will be saved by default.
> So it should not matter whether hardware has hwpoision functionality
> or not.

Thanks, I understand.

> I think that removing hwpoisno pages by default makes sense. If somebody
> does have a reasonable case of not doing so, then we could either
> introduce anther filtering level (based on type) or add another command
> line option like (--no-hwposion-filtering) etc.

I agree with you.
If somebody requests to support for disabling the filter of hwpoison pages,
this option will be discussed.

Regards,
Mitshuhiro Tanino (mitsuhiro.tanino.gm@hitachi.com)


  reply	other threads:[~2012-11-01 10:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-30 14:06 [Patch 0/2] Exclude hwpoison page from vmcore dump Mitsuhiro Tanino
2012-10-30 14:06 ` Mitsuhiro Tanino
2012-10-30 14:37 ` Vivek Goyal
2012-10-30 14:37   ` Vivek Goyal
2012-10-31 13:51   ` Mitsuhiro Tanino
2012-10-31 13:51     ` Mitsuhiro Tanino
2012-10-31 14:14     ` Vivek Goyal
2012-10-31 14:14       ` Vivek Goyal
2012-11-01 10:32       ` Mitsuhiro Tanino [this message]
2012-11-01 10:32         ` Mitsuhiro Tanino
2012-11-01 10:40         ` Eric W. Biederman
2012-11-01 10:40           ` Eric W. Biederman
2012-10-31 14:04   ` [PATCH 0/2 v2] " Mitsuhiro Tanino
2012-10-31 14:04     ` Mitsuhiro Tanino
2012-10-31 14:05   ` [PATCH 1/2 v2] makedumpfile: Add a default action to exclude hwpoison page from vmcore Mitsuhiro Tanino
2012-10-31 14:05     ` Mitsuhiro Tanino
2012-11-05  6:04     ` Atsushi Kumagai
2012-11-05  6:04       ` Atsushi Kumagai
2012-10-31 14:05   ` [PATCH 2/2 v2] kexec: Export PG_hwpoison flag into vmcoreinfo Mitsuhiro Tanino
2012-10-31 14:05     ` Mitsuhiro Tanino
2013-02-08  8:49     ` Atsushi Kumagai
2013-02-08  8:49       ` Atsushi Kumagai
2013-02-12  3:07       ` Mitsuhiro Tanino
2013-02-12  3:07         ` Mitsuhiro Tanino
2013-02-12 10:58         ` Eric W. Biederman
2013-02-12 10:58           ` Eric W. Biederman
2013-02-12 13:29           ` Mitsuhiro Tanino
2013-02-12 13:29             ` Mitsuhiro Tanino
2013-02-15  8:48       ` Mitsuhiro Tanino
2013-02-15  8:48         ` Mitsuhiro Tanino
2013-02-15  9:35         ` Atsushi Kumagai
2013-02-15  9:35           ` Atsushi Kumagai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50924FCD.2020100@hitachi.com \
    --to=mitsuhiro.tanino.gm@hitachi.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.