All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <dkiper@net-space.pl>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: Backport request
Date: Mon, 13 Jan 2014 14:38:29 +0100	[thread overview]
Message-ID: <20140113133829.GA20951@router-fw-old.local.net-space.pl> (raw)
In-Reply-To: <52D3DDD20200007800113009@nat28.tlf.novell.com>

On Mon, Jan 13, 2014 at 11:36:34AM +0000, Jan Beulich wrote:
> >>> On 13.01.14 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> > On 13/01/14 11:13, Jan Beulich wrote:
> >>>>> On 13.01.14 at 10:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
> >>> "x86: map portion of kexec crash area that is within the direct map
> >>> area" to staging-4.3 ASAP, as following the backport of
> >>> 8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
> >>> kernel area", kexec loading is broken in exactly the same way as it was
> >>> in staging.
> >>
> >> Not without explaining how it is broken: According to my own
> >> checking as well as Daniel's there was no need for the kexec area
> >> to be mapped at all in the old implementation.
> >>
> >> Furthermore, I'd prefer to revert 8d611a00 (dff90d0c on 4.2)
> >> instead if there really is an issue. That's largely because, as
> >> noted in the extra comment I added to 0896bd8b, the change is
> >> still incomplete (and hence not much better than the code with
> >> Daniel's change reverted).
> >
> > In that comment it says:
> >
> >   "That's primarily because map_domain_page()
> >    (needed when the area is outside the direct mapping range) may be
> >    unusable when wanting to kexec due to a crash,"
> >
> > But map_domain_page() is only used when loading the crash image, not
> > during exec.
>
> That's good to know, but I don't think it's a good idea either. Seeing
> that map_domain_page() is being used in the code _at all_ may
> make someone try to use it in a path that is used during kexec. And
> it being used by other functions in the same file may also result in
> one of those functions suddenly also getting used on a kexec path.
>
> Together with the issue of the area potentially ending up in a
> PFN compression hole, to me this is enough reason to still expect
> that these uses get dropped again.

map_domain_page() is used during kexec and crash image load.
However, it is not used when a given image is executed.

Daniel

  reply	other threads:[~2014-01-13 13:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-13  9:49 Backport request Andrew Cooper
2014-01-13 10:47 ` David Vrabel
2014-01-13 11:13 ` Jan Beulich
2014-01-13 11:30   ` David Vrabel
2014-01-13 11:36     ` Jan Beulich
2014-01-13 13:38       ` Daniel Kiper [this message]
2017-03-01 12:31 Juergen Gross
2017-03-21  7:58 ` Juergen Gross
2017-04-05 13:24 ` Ian Jackson
2018-02-28 13:56 Corey Minyard
2018-02-28 14:18 ` Greg KH
2019-07-16 22:08 Thomas Gleixner
2019-07-16 23:01 ` Greg KH
2019-07-17 23:38 ` Sasha Levin
2019-07-18  7:57   ` Thomas Gleixner
2020-12-15 16:02 Daniel Vetter
2020-12-19 12:42 ` Greg KH
2020-12-19 13:56   ` Daniel Vetter
2022-08-24 11:20 Juergen Gross
2022-08-24 12:10 ` Greg Kroah-Hartman
2022-08-24 13:52   ` Juergen Gross
2022-08-25 11:59     ` Greg Kroah-Hartman
2023-07-25 11:13 backport request Ard Biesheuvel
2023-07-25 11:17 ` Ard Biesheuvel
2023-07-25 12:29 ` Greg KH
2023-07-25 12:51   ` Ard Biesheuvel
2023-07-25 13:21     ` Greg KH
2023-07-25 13:25       ` Ard Biesheuvel
2023-07-25 13:41         ` Greg KH
2023-07-25 13:48           ` Ard Biesheuvel
2023-07-27 10:59 ` Greg KH
2023-08-01  7:17 Backport request Hemdan, Hagar Gamal Halim
2023-08-01  7:24 ` Greg KH

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=20140113133829.GA20951@router-fw-old.local.net-space.pl \
    --to=dkiper@net-space.pl \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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.