All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Maurizio Lombardi <mlombard@redhat.com>,
	rppt@kernel.org, bp@alien8.de, tglx@linutronix.de,
	x86@kernel.org, pjones@redhat.com, konrad@kernel.org,
	george.kennedy@oracle.com, rafael@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3] iscsi_ibft: fix crash due to KASLR physical memory remapping
Date: Wed, 11 Aug 2021 07:57:25 +0100	[thread overview]
Message-ID: <YRN01YySPVucdCF0@infradead.org> (raw)
In-Reply-To: <YRK9fxhyPgEzWKce@localhost.localdomain>

On Tue, Aug 10, 2021 at 01:55:11PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 10, 2021 at 06:00:24PM +0100, Christoph Hellwig wrote:
> > > Fix this bug by saving the address of the physical location
> > > of the ibft; later the driver will use isa_bus_to_virt() to get
> > > the correct virtual address.
> > 
> > That sound rather broken.  Why not save the physical address in
> > find_ibft_region and then later ioremap that when a virtual address is
> > needed like all other code accessing magic I/O memory?
> 
> That is kind of what he does. The physical address is saved as a global
> static variable and also the physical address is memreserved. Then
> later on the physical address is used to create the virtual address.

Except that it uses isa_bus_to_virt, which is really broken.

> Or are you thinking of making the find_ibft_region reserve the physical
> address, and _cache_ the physical address so there is no global
> variable ?

No.  Just switch to ioremap/early_ioremap insted of this isa_bus_to_virt
mess.

  reply	other threads:[~2021-08-11  6:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 13:52 [PATCH V3] iscsi_ibft: fix crash due to KASLR physical memory remapping Maurizio Lombardi
2021-07-29 17:03 ` Konrad Rzeszutek Wilk
2021-07-29 19:20   ` Maurizio Lombardi
2021-07-29 19:31 ` Mike Rapoport
2021-08-01  2:44   ` Konrad Rzeszutek Wilk
2021-08-10 17:00 ` Christoph Hellwig
2021-08-10 17:55   ` Konrad Rzeszutek Wilk
2021-08-11  6:57     ` Christoph Hellwig [this message]
2021-08-11  7:20       ` Mike Rapoport
2021-09-01 16:47 ` Guenter Roeck

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=YRN01YySPVucdCF0@infradead.org \
    --to=hch@infradead.org \
    --cc=bp@alien8.de \
    --cc=george.kennedy@oracle.com \
    --cc=konrad@darnok.org \
    --cc=konrad@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlombard@redhat.com \
    --cc=pjones@redhat.com \
    --cc=rafael@kernel.org \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.