Date:   Tue, 7 Feb 2023 17:05:27 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc:     x86@kernel.org, Borislav Petkov <bp@alien8.de>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Andrew Cooper <Andrew.Cooper3@citrix.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/alternative: Support relocations in alternatives
Message-ID: <Y+J2x5sPU0uL8bE0@hirez.programming.kicks-ass.net>
References: <Y+EXQlGSI9WUU8nn@hirez.programming.kicks-ass.net>
 <20230207113813.rqwpuaung2hr433q@box.shutemov.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230207113813.rqwpuaung2hr433q@box.shutemov.name>
Precedence: bulk

On Tue, Feb 07, 2023 at 02:38:13PM +0300, Kirill A. Shutemov wrote:
> > +static void __init_or_module noinline
> > +apply_relocation(u8 *buf, size_t len, u8 *dest, u8 *src, size_t src_len)
> > +{
> > +	for (int next, i = 0; i < len; len = next) {
> 
> 'len = next'? I guess it suppose to be 'i = next', right? Otherwise it
> hangs for me.
> 

Yeah, last minute changes and not testing :/ Sorry about that. I'll try
and post an actually tested patch later today.

Also, Masami, how difficuly would it be to do insn_is_nop() that matches
most/all conventional NOP instructions?

That might make it more convenient to write a more generic
optimize_nops_range() -- it currently needs a single byte nop range and
one of the bugs in the patch as posted is caused by a multi-byte nop
(specifically a 0x66 prefixed 0x90).