From: Nathan Chancellor <nathan@kernel.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, willy@infradead.org,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
aarcange@redhat.com, kirill.shutemov@linux.intel.com,
jroedel@suse.de
Subject: Re: [PATCH 11/13] x86_64: Remove pointless set_64bit() usage
Date: Thu, 3 Nov 2022 12:35:57 -0700 [thread overview]
Message-ID: <Y2QYHZsZNs33NXZB@dev-arch.thelio-3990X> (raw)
In-Reply-To: <CAFULd4bkn3i0ds1ywhxAZBQH+1O-zbPWscUqjoEcv4xvnxOnSw@mail.gmail.com>
On Thu, Nov 03, 2022 at 08:23:41PM +0100, Uros Bizjak wrote:
> On Thu, Nov 3, 2022 at 8:09 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Hi Peter,
> >
> > On Sat, Oct 22, 2022 at 01:14:14PM +0200, Peter Zijlstra wrote:
> > > The use of set_64bit() in X86_64 only code is pretty pointless, seeing
> > > how it's a direct assignment. Remove all this nonsense.
> > >
> > > Additionally, since x86_64 unconditionally has HAVE_CMPXCHG_DOUBLE,
> > > there is no point in even having that fallback.
> > >
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > ---
> > > arch/um/include/asm/pgtable-3level.h | 8 --------
> > > arch/x86/include/asm/cmpxchg_64.h | 5 -----
> > > drivers/iommu/intel/irq_remapping.c | 10 ++--------
> > > 3 files changed, 2 insertions(+), 21 deletions(-)
> > >
> > > --- a/arch/um/include/asm/pgtable-3level.h
> > > +++ b/arch/um/include/asm/pgtable-3level.h
> > > @@ -58,11 +58,7 @@
> > > #define pud_populate(mm, pud, pmd) \
> > > set_pud(pud, __pud(_PAGE_TABLE + __pa(pmd)))
> > >
> > > -#ifdef CONFIG_64BIT
> > > -#define set_pud(pudptr, pudval) set_64bit((u64 *) (pudptr), pud_val(pudval))
> > > -#else
> > > #define set_pud(pudptr, pudval) (*(pudptr) = (pudval))
> > > -#endif
> > >
> > > static inline int pgd_newpage(pgd_t pgd)
> > > {
> > > @@ -71,11 +67,7 @@ static inline int pgd_newpage(pgd_t pgd)
> > >
> > > static inline void pgd_mkuptodate(pgd_t pgd) { pgd_val(pgd) &= ~_PAGE_NEWPAGE; }
> > >
> > > -#ifdef CONFIG_64BIT
> > > -#define set_pmd(pmdptr, pmdval) set_64bit((u64 *) (pmdptr), pmd_val(pmdval))
> > > -#else
> > > #define set_pmd(pmdptr, pmdval) (*(pmdptr) = (pmdval))
> > > -#endif
> > >
> > > static inline void pud_clear (pud_t *pud)
> > > {
> > > --- a/arch/x86/include/asm/cmpxchg_64.h
> > > +++ b/arch/x86/include/asm/cmpxchg_64.h
> > > @@ -2,11 +2,6 @@
> > > #ifndef _ASM_X86_CMPXCHG_64_H
> > > #define _ASM_X86_CMPXCHG_64_H
> > >
> > > -static inline void set_64bit(volatile u64 *ptr, u64 val)
> > > -{
> > > - *ptr = val;
> > > -}
> > > -
> > > #define arch_cmpxchg64(ptr, o, n) \
> > > ({ \
> > > BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
> > > --- a/drivers/iommu/intel/irq_remapping.c
> > > +++ b/drivers/iommu/intel/irq_remapping.c
> > > @@ -173,7 +173,6 @@ static int modify_irte(struct irq_2_iomm
> > > index = irq_iommu->irte_index + irq_iommu->sub_handle;
> > > irte = &iommu->ir_table->base[index];
> > >
> > > -#if defined(CONFIG_HAVE_CMPXCHG_DOUBLE)
> > > if ((irte->pst == 1) || (irte_modified->pst == 1)) {
> > > bool ret;
> > >
> > > @@ -187,11 +186,6 @@ static int modify_irte(struct irq_2_iomm
> > > * same as the old value.
> > > */
> > > WARN_ON(!ret);
> > > - } else
> > > -#endif
> > > - {
> > > - set_64bit(&irte->low, irte_modified->low);
> > > - set_64bit(&irte->high, irte_modified->high);
> > > }
> > > __iommu_flush_cache(iommu, irte, sizeof(*irte));
>
> It looks to me that the above part should not be removed, but
> set_64bit should be substituted with WRITE_ONCE. Only #if/#endif lines
> should be removed.
Thanks, I also realized that only a couple minutes after I sent my
initial message. I just got done testing the following diff, which
resolves my issue. Peter, would you like a formal patch or did you want
to squash it in to the original change?
diff --git a/drivers/iommu/intel/irq_remapping.c b/drivers/iommu/intel/irq_remapping.c
index 4216cafd67e7..5d176168bb76 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -186,6 +186,9 @@ static int modify_irte(struct irq_2_iommu *irq_iommu,
* same as the old value.
*/
WARN_ON(!ret);
+ } else {
+ WRITE_ONCE(irte->low, irte_modified->low);
+ WRITE_ONCE(irte->high, irte_modified->high);
}
__iommu_flush_cache(iommu, irte, sizeof(*irte));
> > >
> > > @@ -249,8 +243,8 @@ static int clear_entries(struct irq_2_io
> > > end = start + (1 << irq_iommu->irte_mask);
> > >
> > > for (entry = start; entry < end; entry++) {
> > > - set_64bit(&entry->low, 0);
> > > - set_64bit(&entry->high, 0);
> > > + WRITE_ONCE(entry->low, 0);
> > > + WRITE_ONCE(entry->high, 0);
> > > }
> > > bitmap_release_region(iommu->ir_table->bitmap, index,
> > > irq_iommu->irte_mask);
> > >
> > >
> >
> > This commit is now in -next as commit 0475a2d10fc7 ("x86_64: Remove
> > pointless set_64bit() usage") and I just bisect a boot failure on my
> > Intel test desktop to it.
> >
> > # bad: [81214a573d19ae2fa5b528286ba23cd1cb17feec] Add linux-next specific files for 20221103
> > # good: [8e5423e991e8cd0988d0c4a3f4ac4ca1af7d148a] Merge tag 'parisc-for-6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
> > git bisect start '81214a573d19ae2fa5b528286ba23cd1cb17feec' '8e5423e991e8cd0988d0c4a3f4ac4ca1af7d148a'
> > # good: [8c13089d26d070fef87a64b48191cb7ae6dfbdb2] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> > git bisect good 8c13089d26d070fef87a64b48191cb7ae6dfbdb2
> > # bad: [1bba8e9d15551d2f1c304d8f9d5c647a5b54bfc0] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > git bisect bad 1bba8e9d15551d2f1c304d8f9d5c647a5b54bfc0
> > # good: [748c419c7ade509684ce5bcf74f50e13e0447afd] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
> > git bisect good 748c419c7ade509684ce5bcf74f50e13e0447afd
> > # good: [0acc81a3bf9f875c5ef03037ff5431d37f536f05] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> > git bisect good 0acc81a3bf9f875c5ef03037ff5431d37f536f05
> > # bad: [c0fb84e0698d2ce57f9391c7f4112f6e17676f99] Merge branch into tip/master: 'x86/cleanups'
> > git bisect bad c0fb84e0698d2ce57f9391c7f4112f6e17676f99
> > # good: [7212c34aac1ec6abadf8b439824c8307ef0dd338] Merge branch 'x86/core' into x86/paravirt, to resolve conflicts
> > git bisect good 7212c34aac1ec6abadf8b439824c8307ef0dd338
> > # good: [e1f2ac1d285d963a783a027a1b109420b07f30c1] Merge branch into tip/master: 'x86/cpu'
> > git bisect good e1f2ac1d285d963a783a027a1b109420b07f30c1
> > # good: [306b75edbf25b86fe8189a4f96c217e49483f8ae] Merge branch into tip/master: 'x86/cleanups'
> > git bisect good 306b75edbf25b86fe8189a4f96c217e49483f8ae
> > # good: [8f28b415703e1935457a4bf0be7f03dc5471d09f] mm: Rename GUP_GET_PTE_LOW_HIGH
> > git bisect good 8f28b415703e1935457a4bf0be7f03dc5471d09f
> > # bad: [0475a2d10fc7ced3268cd0f0551390b5858f90cd] x86_64: Remove pointless set_64bit() usage
> > git bisect bad 0475a2d10fc7ced3268cd0f0551390b5858f90cd
> > # good: [a677802d5b0258f93f54620e1cd181b56547c36c] x86/mm/pae: Don't (ab)use atomic64
> > git bisect good a677802d5b0258f93f54620e1cd181b56547c36c
> > # good: [533627610ae7709572a4fac1393fb61153e2a5b3] x86/mm/pae: Be consistent with pXXp_get_and_clear()
> > git bisect good 533627610ae7709572a4fac1393fb61153e2a5b3
> > # first bad commit: [0475a2d10fc7ced3268cd0f0551390b5858f90cd] x86_64: Remove pointless set_64bit() usage
> > # good: [533627610ae7709572a4fac1393fb61153e2a5b3] x86/mm/pae: Be consistent with pXXp_get_and_clear()
> > git bisect good 533627610ae7709572a4fac1393fb61153e2a5b3
> > # first bad commit: [0475a2d10fc7ced3268cd0f0551390b5858f90cd] x86_64: Remove pointless set_64bit() usage
> >
> > Unfortunately, I see no output on the screen it is attached to so I
> > assume it is happening pretty early during the boot sequence, which will
> > probably make getting logs somewhat hard. I can provide information
> > about the system if that would help reveal anything. If there is
> > anything I can test, I am more than happy to do so.
> >
> > Cheers,
> > Nathan
next prev parent reply other threads:[~2022-11-03 19:36 UTC|newest]
Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-22 11:14 [PATCH 00/13] Clean up pmd_get_atomic() and i386-PAE Peter Zijlstra
2022-10-22 11:14 ` [PATCH 01/13] mm: Update ptep_get_lockless()s comment Peter Zijlstra
2022-10-24 5:42 ` John Hubbard
2022-10-24 8:00 ` Peter Zijlstra
2022-10-24 19:58 ` Jann Horn
2022-10-24 20:19 ` Linus Torvalds
2022-10-24 20:23 ` Jann Horn
2022-10-24 20:36 ` Linus Torvalds
2022-10-25 3:21 ` Matthew Wilcox
2022-10-25 7:54 ` Alistair Popple
2022-10-25 13:33 ` Peter Zijlstra
2022-10-25 13:44 ` Jann Horn
2022-10-26 0:45 ` Alistair Popple
2022-10-25 14:02 ` Peter Zijlstra
2022-10-25 14:18 ` Jann Horn
2022-10-25 15:06 ` Peter Zijlstra
2022-10-26 16:45 ` Jann Horn
2022-10-27 7:08 ` Peter Zijlstra
2022-10-27 18:13 ` Linus Torvalds
2022-10-27 19:35 ` Peter Zijlstra
2022-10-27 19:43 ` Linus Torvalds
2022-10-27 20:15 ` Nadav Amit
2022-10-27 20:31 ` Linus Torvalds
2022-10-27 21:44 ` Nadav Amit
2022-10-28 23:57 ` Nadav Amit
2022-10-29 0:42 ` Linus Torvalds
2022-10-29 18:05 ` Nadav Amit
2022-10-29 18:36 ` Linus Torvalds
2022-10-29 18:58 ` Linus Torvalds
2022-10-29 19:14 ` Linus Torvalds
2022-10-29 19:28 ` Nadav Amit
2022-10-30 0:18 ` Nadav Amit
2022-10-30 2:17 ` Nadav Amit
2022-10-30 18:19 ` Linus Torvalds
2022-10-30 18:51 ` Linus Torvalds
2022-10-30 22:47 ` Linus Torvalds
2022-10-31 1:47 ` Linus Torvalds
2022-10-31 4:09 ` Nadav Amit
2022-10-31 4:55 ` Nadav Amit
2022-10-31 5:00 ` Linus Torvalds
2022-10-31 15:43 ` Nadav Amit
2022-10-31 17:32 ` Linus Torvalds
2022-10-31 9:36 ` Peter Zijlstra
2022-10-31 17:28 ` Linus Torvalds
2022-10-31 18:43 ` mm: delay rmap removal until after TLB flush Linus Torvalds
2022-11-02 9:14 ` Christian Borntraeger
2022-11-02 9:23 ` Christian Borntraeger
2022-11-02 17:55 ` Linus Torvalds
2022-11-02 18:28 ` Linus Torvalds
2022-11-02 22:29 ` Gerald Schaefer
2022-11-02 12:45 ` Peter Zijlstra
2022-11-02 22:31 ` Gerald Schaefer
2022-11-02 23:13 ` Linus Torvalds
2022-11-03 9:52 ` David Hildenbrand
2022-11-03 16:54 ` Linus Torvalds
2022-11-03 17:09 ` Linus Torvalds
2022-11-03 17:36 ` David Hildenbrand
2022-11-04 6:33 ` Alexander Gordeev
2022-11-04 17:35 ` Linus Torvalds
2022-11-06 21:06 ` Hugh Dickins
2022-11-06 22:34 ` Linus Torvalds
2022-11-06 23:14 ` Andrew Morton
2022-11-07 0:06 ` Stephen Rothwell
2022-11-07 16:19 ` Linus Torvalds
2022-11-07 23:02 ` Andrew Morton
2022-11-07 23:44 ` Stephen Rothwell
2022-11-07 9:12 ` Peter Zijlstra
2022-11-07 20:07 ` Johannes Weiner
2022-11-07 20:29 ` Linus Torvalds
2022-11-07 23:47 ` Linus Torvalds
2022-11-08 4:28 ` Linus Torvalds
2022-11-08 19:56 ` Linus Torvalds
2022-11-08 20:03 ` Konstantin Ryabitsev
2022-11-08 20:18 ` Linus Torvalds
2022-11-08 19:41 ` [PATCH 1/4] mm: introduce 'encoded' page pointers with embedded extra bits Linus Torvalds
2022-11-08 20:37 ` Nadav Amit
2022-11-08 20:46 ` Linus Torvalds
2022-11-09 6:36 ` Alexander Gordeev
2022-11-09 18:00 ` Linus Torvalds
2022-11-09 20:02 ` Linus Torvalds
2022-11-08 19:41 ` [PATCH 2/4] mm: teach release_pages() to take an array of encoded page pointers too Linus Torvalds
2022-11-08 19:41 ` [PATCH 3/4] mm: mmu_gather: prepare to gather encoded page pointers with flags Linus Torvalds
2022-11-08 19:41 ` [PATCH 4/4] mm: delay page_remove_rmap() until after the TLB has been flushed Linus Torvalds
2022-11-08 21:05 ` Nadav Amit
2022-11-09 15:53 ` Johannes Weiner
2022-11-09 19:31 ` Hugh Dickins
2022-10-31 9:39 ` [PATCH 01/13] mm: Update ptep_get_lockless()s comment Peter Zijlstra
2022-10-31 17:22 ` Linus Torvalds
2022-10-31 9:46 ` Peter Zijlstra
2022-10-31 9:28 ` Peter Zijlstra
2022-10-31 17:19 ` Linus Torvalds
2022-10-30 19:34 ` Nadav Amit
2022-10-29 19:39 ` John Hubbard
2022-10-29 20:15 ` Linus Torvalds
2022-10-29 20:30 ` Linus Torvalds
2022-10-29 20:42 ` John Hubbard
2022-10-29 20:56 ` Nadav Amit
2022-10-29 21:03 ` Nadav Amit
2022-10-29 21:12 ` Linus Torvalds
2022-10-29 20:59 ` Theodore Ts'o
2022-10-26 19:43 ` Nadav Amit
2022-10-27 7:27 ` Peter Zijlstra
2022-10-27 17:30 ` Nadav Amit
2022-10-22 11:14 ` [PATCH 02/13] x86/mm/pae: Make pmd_t similar to pte_t Peter Zijlstra
2022-10-22 11:14 ` [PATCH 03/13] sh/mm: " Peter Zijlstra
2022-12-21 13:54 ` Guenter Roeck
2022-10-22 11:14 ` [PATCH 04/13] mm: Fix pmd_read_atomic() Peter Zijlstra
2022-10-22 17:30 ` Linus Torvalds
2022-10-24 8:09 ` Peter Zijlstra
2022-11-01 12:41 ` Peter Zijlstra
2022-11-01 17:42 ` Linus Torvalds
2022-10-22 11:14 ` [PATCH 05/13] mm: Rename GUP_GET_PTE_LOW_HIGH Peter Zijlstra
2022-10-22 11:14 ` [PATCH 06/13] mm: Rename pmd_read_atomic() Peter Zijlstra
2022-10-22 11:14 ` [PATCH 07/13] mm/gup: Fix the lockless PMD access Peter Zijlstra
2022-10-23 0:42 ` Hugh Dickins
2022-10-24 7:42 ` Peter Zijlstra
2022-10-25 3:58 ` Hugh Dickins
2022-10-22 11:14 ` [PATCH 08/13] x86/mm/pae: Dont (ab)use atomic64 Peter Zijlstra
2022-10-22 11:14 ` [PATCH 09/13] x86/mm/pae: Use WRITE_ONCE() Peter Zijlstra
2022-10-22 17:42 ` Linus Torvalds
2022-10-24 10:21 ` Peter Zijlstra
2022-10-22 11:14 ` [PATCH 10/13] x86/mm/pae: Be consistent with pXXp_get_and_clear() Peter Zijlstra
2022-10-22 17:53 ` Linus Torvalds
2022-10-24 11:13 ` Peter Zijlstra
2022-10-22 11:14 ` [PATCH 11/13] x86_64: Remove pointless set_64bit() usage Peter Zijlstra
2022-10-22 17:55 ` Linus Torvalds
2022-11-03 19:09 ` Nathan Chancellor
2022-11-03 19:23 ` Uros Bizjak
2022-11-03 19:35 ` Nathan Chancellor [this message]
2022-11-03 20:39 ` Linus Torvalds
2022-11-03 21:06 ` Peter Zijlstra
2022-11-04 16:01 ` Peter Zijlstra
2022-11-04 17:15 ` Linus Torvalds
2022-11-05 13:29 ` Jason A. Donenfeld
2022-11-05 15:14 ` Peter Zijlstra
2022-11-05 20:54 ` Jason A. Donenfeld
2022-11-07 9:14 ` David Laight
2022-12-19 15:44 ` Peter Zijlstra
2022-10-22 11:14 ` [PATCH 12/13] x86/mm/pae: Get rid of set_64bit() Peter Zijlstra
2022-10-22 11:14 ` [PATCH 13/13] mm: Remove pointless barrier() after pmdp_get_lockless() Peter Zijlstra
2022-10-22 19:59 ` Yu Zhao
2022-10-22 17:57 ` [PATCH 00/13] Clean up pmd_get_atomic() and i386-PAE Linus Torvalds
2022-10-29 12:21 ` Peter Zijlstra
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=Y2QYHZsZNs33NXZB@dev-arch.thelio-3990X \
--to=nathan@kernel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jroedel@suse.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=ubizjak@gmail.com \
--cc=willy@infradead.org \
--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