Re: riscv: alternatives: move length validation inside the subsection

[Changbin Du]

On Thu, Jun 02, 2022 at 07:43:01AM -0700, Nathan Chancellor wrote:
> On Thu, Jun 02, 2022 at 07:27:34PM +0800, Changbin Du wrote:
> > Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
> > length validation inside the subsection") to riscv.  Due to the one-pass
> > design of LLVM's integrated assembler, it can not compute the length of
> > instructions if the .org directive is outside of the subsection that these
> > instructions are in.
> > 
> > Here is the build error reported by llvm:
> > 
> > In file included from ./arch/riscv/include/asm/pgtable.h:108:
> > ./arch/riscv/include/asm/tlbflush.h:23:2: error: expected assembly-time absolute expression
> >         ALT_FLUSH_TLB_PAGE(__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory"));
> >         ^
> > ./arch/riscv/include/asm/errata_list.h:41:5: note: expanded from macro 'ALT_FLUSH_TLB_PAGE'
> > asm(ALTERNATIVE("sfence.vma %0", "sfence.vma", SIFIVE_VENDOR_ID,        \
> >     ^
> > ./arch/riscv/include/asm/alternative-macros.h:187:2: note: expanded from macro 'ALTERNATIVE'
> >         _ALTERNATIVE_CFG(old_content, new_content, vendor_id, errata_id, CONFIG_k)
> >         ^
> > ./arch/riscv/include/asm/alternative-macros.h:113:2: note: expanded from macro '_ALTERNATIVE_CFG'
> >         __ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, IS_ENABLED(CONFIG_k))
> >         ^
> > ./arch/riscv/include/asm/alternative-macros.h:110:2: note: expanded from macro '__ALTERNATIVE_CFG'
> >         ALT_NEW_CONTENT(vendor_id, errata_id, enable, new_c)
> >         ^
> > ./arch/riscv/include/asm/alternative-macros.h:98:3: note: expanded from macro 'ALT_NEW_CONTENT'
> >         ".org   . - (887b - 886b) + (889b - 888b)\n"                    \
> >          ^
> > <inline asm>:25:6: note: instantiated into assembly here
> > .org    . - (887b - 886b) + (889b - 888b)
> >         ^
> > 
> > Signed-off-by: Changbin Du <changbin.du@xxxxxxxxx>
> 
> Thanks for the patch! I already sent an equivalent change two weeks ago
> as https://lore.kernel.org/20220516214520.3252074-1-nathan@xxxxxxxxxx/,
> which I think is slightly better because it handles the __ASSEMBLY__
> version of the macro as well.
> 
Agreed. Thank you, and please ignore this one.

> Cheers,
> Nathan
>