public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Uros Bizjak <ubizjak@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH 14/20] x86/barrier: Use alternative_io() in 32-bit barrier functions
Date: Mon, 17 Mar 2025 20:04:32 +0000	[thread overview]
Message-ID: <20250317200432.1a076d6a@pumpkin> (raw)
In-Reply-To: <zfabhk7c3fucov7lpfsqf5bj7iie5324ccgn4ingzzakoyhl4u@fzg364keuphn>

On Fri, 14 Mar 2025 17:05:34 -0700
Josh Poimboeuf <jpoimboe@kernel.org> wrote:

> On Fri, Mar 14, 2025 at 01:49:48PM -1000, Linus Torvalds wrote:
> > So all of these patches look like good cleanups to me, but I do wonder
> > if we should
> > 
> >  (a) not use some naming *quite* as generic as 'ARG()'
> > 
> >  (b) make the asms use ARG_OUT/ARG_IN/ARG_CLOBBER() to clarify
> > 
> > because that ARG(), ARG(), ARGC() pattern looks odd to me.
> > 
> > Maybe it's just me.
> > 
> > Regardless, I do think the series looks like a nice improvement even
> > in the current form, even if that particular repeated pattern feels
> > strange.  
> 
> So originally I had ASM_OUTPUT/ASM_INPUT/ASM_CLOBBER, but I ended up
> going with ARG() due to its nice vertical alignment and conciseness:

But ARG() does look horrid.

Is the ARG() necessary just to handle the comma separated lists?
If so is it only actually needed if there is more than one item?

Another option is to just require () and add the ARG in the expansion.
So with:
#define __asm_call(qual, alt, out, in, clobber) \
	asm("zzz", ARG out, ARG in, ARG clobber)

__asm_call(qual, ALT(), \
		([var] "+m" (__my_cpu_var(_var)), "+a" (old__.low),	\
		    "+d" (old__.high)),					\
		("b" (new__.low), "c" (new__.high), "S" (&(_var))),	\
		("memory"));

would get expanded the same as the line below.

	David
	
> 
> 
> 	__asm_call(qual,						\
> 		ALTERNATIVE("call this_cpu_cmpxchg8b_emu",		\
> 			    "cmpxchg8b " __percpu_arg([var]),		\
> 			    X86_FEATURE_CX8),				\
> 		ARG([var] "+m" (__my_cpu_var(_var)), "+a" (old__.low),	\
> 		    "+d" (old__.high)),					\
> 		ARG("b" (new__.low), "c" (new__.high), "S" (&(_var))),	\
> 		ARG("memory"));						\
> 
> 
> Though ASM_OUTPUT/ASM_INPUT/ASM_CLOBBER isn't so bad either:
> 
> 	__asm_call(qual,						\
> 		ALTERNATIVE("call this_cpu_cmpxchg8b_emu",		\
> 			    "cmpxchg8b " __percpu_arg([var]),		\
> 			    X86_FEATURE_CX8),				\
> 		ASM_OUTPUT([var] "+m" (__my_cpu_var(_var)),		\
> 			   "+a" (old__.low), "+d" (old__.high)),	\
> 		ASM_INPUT("b" (new__.low), "c" (new__.high),		\
> 			  "S" (&(_var))),				\
> 		ASM_CLOBBER("memory"));					\
> 
> 
> That has the nice benefit of being more self-documenting, albeit more
> verbose and less vertically aligned.
> 
> So I could go either way, really.
> 


  parent reply	other threads:[~2025-03-17 20:04 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14 21:41 [PATCH 00/20] x86: Cleanup alternative_io() and friends, prep for asm_call() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 01/20] x86/cpu: Use named asm operands in prefetch[w]() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 02/20] x86/apic: Use named asm operands in native_apic_mem_write() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 03/20] x86/mm: Use named asm operands in task_size_max() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 04/20] x86/cpu: Use named asm operands in clflushopt() Josh Poimboeuf
2025-03-14 23:46   ` Linus Torvalds
2025-03-15  0:07     ` Josh Poimboeuf
2025-03-15  8:42       ` Ingo Molnar
2025-03-15  9:25         ` Ingo Molnar
2025-03-14 21:41 ` [PATCH 05/20] x86/asm: Always use flag output operands Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 06/20] x86/asm: Remove CC_SET() Josh Poimboeuf
2025-03-15  9:25   ` Uros Bizjak
2025-03-14 21:41 ` [PATCH 07/20] x86/alternative: Remove operand numbering restrictions Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 08/20] x86/asm: Replace ASM_{OUTPUT,INPUT}() with ARG() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 09/20] x86/alternative: Simplify alternative_io() interface Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 10/20] x86/alternative: Add alternative_2_io() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 11/20] x86/alternative: Make alternative() a wrapper around alternative_io() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 12/20] x86/cpu: Use alternative_io() in prefetch[w]() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 13/20] x86/alternative: Remove alternative_input() Josh Poimboeuf
2025-03-14 21:41 ` [PATCH 14/20] x86/barrier: Use alternative_io() in 32-bit barrier functions Josh Poimboeuf
2025-03-14 23:49   ` Linus Torvalds
2025-03-14 23:54     ` Linus Torvalds
2025-03-15  0:09       ` Josh Poimboeuf
2025-03-15  0:16         ` Linus Torvalds
2025-03-15  8:47           ` Ingo Molnar
2025-03-15  0:05     ` Josh Poimboeuf
2025-03-15  9:14       ` Ingo Molnar
2025-03-17 20:04       ` David Laight [this message]
2025-03-18  0:11         ` Josh Poimboeuf
2025-03-18 22:06           ` David Laight
2025-03-18 22:29             ` Josh Poimboeuf
2025-03-15  8:52     ` Ingo Molnar
2025-03-14 21:41 ` [PATCH 15/20] x86/cpu/amd: Use named asm operands in asm_clear_divider() Josh Poimboeuf
2025-03-15  9:01   ` Uros Bizjak
2025-03-15 10:00     ` Uros Bizjak
2025-03-14 21:41 ` [PATCH 16/20] x86/cpu: Use alternative_io() in amd_clear_divider() Josh Poimboeuf
2025-03-15  9:03   ` Uros Bizjak
2025-03-14 21:41 ` [PATCH 17/20] x86/smap: Use named asm operands in smap_{save,restore}() Josh Poimboeuf
2025-03-14 22:51   ` Andrew Cooper
2025-03-14 23:56     ` Andrew Cooper
2025-03-14 21:41 ` [PATCH 18/20] x86/smap: Use alternative_io() " Josh Poimboeuf
2025-03-15  9:09   ` Uros Bizjak
2025-03-14 21:41 ` [PATCH 19/20] x86/uaccess: Use alternative_io() in __untagged_addr() Josh Poimboeuf
2025-03-15  9:12   ` Uros Bizjak
2025-03-14 21:41 ` [PATCH 20/20] x86/msr: Use alternative_2_io() in rdtsc_ordered() Josh Poimboeuf
2025-03-14 22:25 ` [PATCH 00/20] x86: Cleanup alternative_io() and friends, prep for asm_call() Josh Poimboeuf
2025-03-15  9:52   ` Uros Bizjak

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=20250317200432.1a076d6a@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=ubizjak@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox