All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Pratyush Anand <panand@redhat.com>
Cc: geoff@infradead.org, kexec@lists.infradead.org,
	Dave Young <dyoung@redhat.com>, James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
Date: Wed, 14 Dec 2016 13:44:57 +0000	[thread overview]
Message-ID: <20161214134457.GJ17982@leverpostej> (raw)
In-Reply-To: <3a6ac655-bfa6-0d90-6351-731ce36e99eb@redhat.com>

Hi,

On Wed, Dec 14, 2016 at 05:51:05PM +0530, Pratyush Anand wrote:
> 
> On Wednesday 14 December 2016 05:07 PM, Mark Rutland wrote:
> >I see in an earlier message that the need for sha256 was being discussed
> >in another thread. Do either of you happen to have a pointer to that.
> 
> patch 0/2 of this series.

AFAICT, that just says the the existing sha256 check is slow, not *why*
a sha256 check of some description is necessary. I'm still at a loss as
to why it is considered necessary, rather than being a debugging aid or
sanity check.

> >To me, it seems like it doesn't come with much benefit for the kdump
> >case given that's best-effort anyway, and as above the verification code
> >could have been be corrupted. In the non-kdump case it's not strictly
> >necessary and seems like a debugging aid rather than a necessary piece
> >of functionality -- if that's the case, a 20 second delay isn't the end
> >of the world...
> 
> Even for the non-kdump ie `kexec -l` case we do not have a
> functionality to bypass sha verification in kexec-tools. --lite
> option with the kexec-tools was discouraged and not accepted.

Ok. Do you have a pointer to the thread regarding that, for context?

> So,it is 20s for both `kexec -l` and `kexec -p`.

Well, unless we can have a --{no-,}sha-check, and make the default NO
for arm64.

> Also other arch like x86_64 takes negligible time in sha verification.

That's certainly an argument for not changing the other architectures,
but given it's slow for arm64, we could have a different default...

Thanks,
Mark.

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

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
Date: Wed, 14 Dec 2016 13:44:57 +0000	[thread overview]
Message-ID: <20161214134457.GJ17982@leverpostej> (raw)
In-Reply-To: <3a6ac655-bfa6-0d90-6351-731ce36e99eb@redhat.com>

Hi,

On Wed, Dec 14, 2016 at 05:51:05PM +0530, Pratyush Anand wrote:
> 
> On Wednesday 14 December 2016 05:07 PM, Mark Rutland wrote:
> >I see in an earlier message that the need for sha256 was being discussed
> >in another thread. Do either of you happen to have a pointer to that.
> 
> patch 0/2 of this series.

AFAICT, that just says the the existing sha256 check is slow, not *why*
a sha256 check of some description is necessary. I'm still at a loss as
to why it is considered necessary, rather than being a debugging aid or
sanity check.

> >To me, it seems like it doesn't come with much benefit for the kdump
> >case given that's best-effort anyway, and as above the verification code
> >could have been be corrupted. In the non-kdump case it's not strictly
> >necessary and seems like a debugging aid rather than a necessary piece
> >of functionality -- if that's the case, a 20 second delay isn't the end
> >of the world...
> 
> Even for the non-kdump ie `kexec -l` case we do not have a
> functionality to bypass sha verification in kexec-tools. --lite
> option with the kexec-tools was discouraged and not accepted.

Ok. Do you have a pointer to the thread regarding that, for context?

> So,it is 20s for both `kexec -l` and `kexec -p`.

Well, unless we can have a --{no-,}sha-check, and make the default NO
for arm64.

> Also other arch like x86_64 takes negligible time in sha verification.

That's certainly an argument for not changing the other architectures,
but given it's slow for arm64, we could have a different default...

Thanks,
Mark.

  reply	other threads:[~2016-12-14 13:44 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22  4:32 [PATCH 0/2] kexec-tools: arm64: Add dcache enabling facility Pratyush Anand
2016-11-22  4:32 ` Pratyush Anand
2016-11-22  4:32 ` [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory Pratyush Anand
2016-11-22  4:32   ` Pratyush Anand
2016-11-25 18:30   ` James Morse
2016-11-25 18:30     ` James Morse
2016-12-14  9:38     ` Pratyush Anand
2016-12-14  9:38       ` Pratyush Anand
2016-12-14 10:12       ` Pratyush Anand
2016-12-14 10:12         ` Pratyush Anand
2016-12-14 11:16         ` James Morse
2016-12-14 11:16           ` James Morse
2016-12-14 11:37           ` Mark Rutland
2016-12-14 11:37             ` Mark Rutland
2016-12-14 12:11             ` James Morse
2016-12-14 12:11               ` James Morse
2016-12-14 12:21             ` Pratyush Anand
2016-12-14 12:21               ` Pratyush Anand
2016-12-14 13:44               ` Mark Rutland [this message]
2016-12-14 13:44                 ` Mark Rutland
2016-12-14 14:13                 ` Pratyush Anand
2016-12-14 14:13                   ` Pratyush Anand
2016-12-14 12:13           ` Pratyush Anand
2016-12-14 12:13             ` Pratyush Anand
2016-12-14 11:16       ` James Morse
2016-12-14 11:16         ` James Morse
2016-12-14 11:28         ` Mark Rutland
2016-12-14 11:28           ` Mark Rutland
2016-11-22  4:32 ` [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory Pratyush Anand
2016-11-22  4:32   ` Pratyush Anand
2016-11-22 18:57   ` Geoff Levand
2016-11-22 18:57     ` Geoff Levand
2016-11-23  1:46     ` Pratyush Anand
2016-11-23  1:46       ` Pratyush Anand
2016-11-23  2:03       ` Dave Young
2016-11-23  2:03         ` Dave Young
2016-11-23  2:11         ` Pratyush Anand
2016-11-23  2:11           ` Pratyush Anand
2016-11-23  8:08           ` Simon Horman
2016-11-23  8:08             ` Simon Horman
2016-11-23  8:17             ` Pratyush Anand
2016-11-23  8:17               ` Pratyush Anand
2016-11-22 18:56 ` [PATCH 0/2] kexec-tools: arm64: Add dcache enabling facility Geoff Levand
2016-11-22 18:56   ` Geoff Levand
2016-11-23  1:39   ` Pratyush Anand
2016-11-23  1:39     ` Pratyush Anand
2016-11-25 18:30   ` James Morse
2016-11-25 18:30     ` James Morse

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=20161214134457.GJ17982@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=dyoung@redhat.com \
    --cc=geoff@infradead.org \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=panand@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.