linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	rppt@kernel.org, penberg@kernel.org, geert@linux-m68k.org,
	giancarlo.ferrari@nokia.com
Subject: Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
Date: Mon, 1 Feb 2021 14:39:46 +0000	[thread overview]
Message-ID: <20210201143943.GA15399@p4> (raw)
In-Reply-To: <20210201124720.GA66060@C02TD0UTHF1T.local>

Hi,

On Mon, Feb 01, 2021 at 12:47:20PM +0000, Mark Rutland wrote:
> On Mon, Feb 01, 2021 at 12:44:56AM +0000, Giancarlo Ferrari wrote:
> > machine_kexec() need to set rw permission in text and rodata sections
> > to assign some variables (e.g. kexec_start_address). To do that at
> > the end (after flushing pdm in memory, etc.) it needs to invalidate
> > TLB [section] entries.
> 
> It'd be worth noting explicitly that set_kernel_text_rw() alters
> current->active_mm...
> 
> > If during the TLB invalidation an interrupt occours, which might cause
> > a context switch, there is the risk to inject invalid TLBs, with ro
> > permissions.
> 
> ... which is why if there's a context switch things can go wrong, since
> active_mm isn't stable, and so it's possible that set_kernel_text_rw()
> updates multiple tables, none of which might be the active table at the
> point we try to make an access.
> 

Maybe the behaviour causing issue is not completely clear to me, and I do
apologize for that (moreover I haven't eougth debug capabilities).
However, current-active_mm is switched among context switches. Correct ?
So, in principle, the invalidation, if stopped, is carried on where it
left.

I thought the issue was that the PageTable entry for the section 0x8010_0000
is global, thus not indexed by ASID (Address Space ID). By the fact that each
process has its own version of that entry, is the cause of the issue, as the
schedule process might bringing a spurious entry (with ro permission) in the
MMU cache.

If the entry is not global holds the ASID, and the issue cannot happen.

Please note that this behaviour was tested on a armv7 arch board.

> It would be nice to spell that out rather than saying "invalid TLBs".
> 
> We could disable preemption to prevent that, which is possibly better
> than disabling interrupts.
> 
> Overall, it would be much better to avoid having to mess with the kernel
> page tables. So rather than going:
> 
> 1. mark kernel RW
> 2. alter variables in reloc code
> 3. copy reloc code into buffer
> 4. branch to buffer
> 
> ... we should be able to go:
> 
> 1. copy reloc code into buffer
> 2. alter variables in copy of reloc code
> 3. branch to buffer
> 
> ... which would avoid this class of problem too.
> 
> Thanks,
> Mark.

Thanks,


GF

  parent reply	other threads:[~2021-02-01 14:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01  0:44 [PATCH] ARM: kexec: Fix panic after TLB are invalidated Giancarlo Ferrari
2021-02-01 11:34 ` Russell King - ARM Linux admin
2021-02-01 12:47 ` Mark Rutland
2021-02-01 13:03   ` Russell King - ARM Linux admin
2021-02-01 13:57     ` Mark Rutland
2021-02-01 16:08       ` Russell King - ARM Linux admin
2021-02-01 16:32         ` Mark Rutland
2021-02-01 16:37           ` Russell King - ARM Linux admin
2021-02-01 20:07         ` Giancarlo Ferrari
2021-02-01 20:16           ` Russell King - ARM Linux admin
2021-02-01 22:18             ` Giancarlo Ferrari
2021-02-04 23:48               ` Giancarlo Ferrari
2021-02-05  0:18                 ` Russell King - ARM Linux admin
2021-02-05  0:40                   ` Giancarlo Ferrari
2021-02-05  0:45                     ` Giancarlo Ferrari
2021-02-05  9:44                     ` Russell King - ARM Linux admin
2021-02-05 14:36                       ` Giancarlo Ferrari
2021-02-01 14:39   ` Giancarlo Ferrari [this message]
2021-02-01 15:30     ` Mark Rutland
2021-02-01 19:09       ` Giancarlo Ferrari
  -- strict thread matches above, loose matches on Subject: below --
2021-01-12 16:49 Giancarlo Ferrari
2021-02-01 10:10 ` Giancarlo Ferrari

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=20210201143943.GA15399@p4 \
    --to=giancarlo.ferrari89@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=geert@linux-m68k.org \
    --cc=giancarlo.ferrari@nokia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=penberg@kernel.org \
    --cc=rppt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).