All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	Andy Lutomirski <luto@kernel.org>,
	Brian Gerst <brgerst@gmail.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH] x86/percpu: Fix and improve x86_this_cpu_test_bit() and friends
Date: Thu, 4 Apr 2024 10:48:22 +0200	[thread overview]
Message-ID: <Zg5pVphMVAJ6W9Cc@gmail.com> (raw)
In-Reply-To: <20240403144648.3885-1-ubizjak@gmail.com>


* Uros Bizjak <ubizjak@gmail.com> wrote:

> Fix x86_this_cpu_variable_test_bit(), which is implemented with
> wrong asm template, where argument 2 (count argument) is considered
> as percpu variable. However, x86_this_cpu_test_bit() is currently
> used exclusively with constant bit number argument, so the called
> x86_this_cpu_variable_test_bit() function is never instantiated.
> The fix introduces named assembler operands to prevent this kind
> of errors.
> 
> Also rewrite the whole family of x86_this_cpu_test_bit() functions
> as macros, so standard __my_cpu_var() and raw_cpu_read() macros
> can be used on percpu variables. This approach considerably
> simplifies implementation of functions and also introduces standard
> checks on accessed percpu variables.
> 
> No functional changes intended.

Could you please split this into at least two patches?

Hint: 'also' in a changelog paragraph is an indicator of a new patch 
being justified, in like 80% of the cases. :-)

Thanks,

	Ingo

      reply	other threads:[~2024-04-04  8:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 14:46 [PATCH] x86/percpu: Fix and improve x86_this_cpu_test_bit() and friends Uros Bizjak
2024-04-04  8:48 ` Ingo Molnar [this message]

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=Zg5pVphMVAJ6W9Cc@gmail.com \
    --to=mingo@kernel.org \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 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.