All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Lawrence <joe.lawrence@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Suraj Jitindar Singh <surajjs@amazon.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	catalin.marinas@arm.com, will@kernel.org, broonie@kernel.org,
	madvenka@linux.microsoft.com, duwe@lst.de,
	sjitindarsingh@gmail.com, benh@kernel.crashing.org
Subject: Re: [RFC PATCH 1/1] arm64: implement live patching
Date: Mon, 7 Jun 2021 09:08:52 -0400	[thread overview]
Message-ID: <YL4aZCMmouLCQlJr@redhat.com> (raw)
In-Reply-To: <20210607102058.GB97489@C02TD0UTHF1T.local>

On Mon, Jun 07, 2021 at 11:20:58AM +0100, Mark Rutland wrote:
> On Fri, Jun 04, 2021 at 04:59:30PM -0700, Suraj Jitindar Singh wrote:
> > It's my understanding that the two pieces of work required to enable live
> > patching on arm are in flight upstream;
> > - Reliable stack traces as implemented by Madhavan T. Venkataraman [1]
> > - Objtool as implemented by Julien Thierry [2]
> 
> We also need to rework the arm64 patching code to not rely on any code
> which may itself be patched. Currently there's a reasonable amount of
> patching code that can either be patched directly, or can be
> instrumented by code that can be patched.
> 
> I have some WIP patches for that at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/patching/rework
> 
> ... but there's still a lot to do, and it's not clear to me if there's
> other stuff we need to rework to make patch-safe.
> 
> Do we have any infrastructure for testing LIVEPATCH?
> 

Hi Mark,

If you're looking for a high level sanity check, there are livepatching
integration selftests in tools/testing/selftests/livepatch.  Let me know
if you have any questions about those.

Regards,

-- Joe


WARNING: multiple messages have this Message-ID (diff)
From: Joe Lawrence <joe.lawrence@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Suraj Jitindar Singh <surajjs@amazon.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	catalin.marinas@arm.com, will@kernel.org, broonie@kernel.org,
	madvenka@linux.microsoft.com, duwe@lst.de,
	sjitindarsingh@gmail.com, benh@kernel.crashing.org
Subject: Re: [RFC PATCH 1/1] arm64: implement live patching
Date: Mon, 7 Jun 2021 09:08:52 -0400	[thread overview]
Message-ID: <YL4aZCMmouLCQlJr@redhat.com> (raw)
In-Reply-To: <20210607102058.GB97489@C02TD0UTHF1T.local>

On Mon, Jun 07, 2021 at 11:20:58AM +0100, Mark Rutland wrote:
> On Fri, Jun 04, 2021 at 04:59:30PM -0700, Suraj Jitindar Singh wrote:
> > It's my understanding that the two pieces of work required to enable live
> > patching on arm are in flight upstream;
> > - Reliable stack traces as implemented by Madhavan T. Venkataraman [1]
> > - Objtool as implemented by Julien Thierry [2]
> 
> We also need to rework the arm64 patching code to not rely on any code
> which may itself be patched. Currently there's a reasonable amount of
> patching code that can either be patched directly, or can be
> instrumented by code that can be patched.
> 
> I have some WIP patches for that at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/patching/rework
> 
> ... but there's still a lot to do, and it's not clear to me if there's
> other stuff we need to rework to make patch-safe.
> 
> Do we have any infrastructure for testing LIVEPATCH?
> 

Hi Mark,

If you're looking for a high level sanity check, there are livepatching
integration selftests in tools/testing/selftests/livepatch.  Let me know
if you have any questions about those.

Regards,

-- Joe


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-07 13:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-04 23:59 [RFC PATCH 1/1] arm64: implement live patching Suraj Jitindar Singh
2021-06-04 23:59 ` Suraj Jitindar Singh
2021-06-07 10:20 ` Mark Rutland
2021-06-07 10:20   ` Mark Rutland
2021-06-07 13:08   ` Joe Lawrence [this message]
2021-06-07 13:08     ` Joe Lawrence
2021-06-09  0:32   ` Suraj Jitindar Singh
2021-06-09  0:32     ` Suraj Jitindar Singh
2021-06-09 23:57     ` Suraj Jitindar Singh
2021-06-09 23:57       ` Suraj Jitindar Singh
2021-06-07 17:01 ` Mark Brown
2021-06-07 17:01   ` Mark Brown
2021-06-09  0:12   ` Suraj Jitindar Singh
2021-06-09  0:12     ` Suraj Jitindar Singh
2021-06-17  9:29 ` nobuta.keiya
2021-06-17  9:29   ` nobuta.keiya
2021-06-17 18:32   ` Madhavan T. Venkataraman
2021-06-17 18:32     ` Madhavan T. Venkataraman

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=YL4aZCMmouLCQlJr@redhat.com \
    --to=joe.lawrence@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=duwe@lst.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=mark.rutland@arm.com \
    --cc=sjitindarsingh@gmail.com \
    --cc=surajjs@amazon.com \
    --cc=will@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.