From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Linus Torvalds <torvalds@linuxfoundation.org>,
Andy Lutomirski <luto@kernel.org>,
Stephen Hemminger <stephen@networkplumber.org>,
Willy Tarreau <w@1wt.eu>, Juergen Gross <jgross@suse.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH] x86/iopl: Clear up the role of the two bitmap copying fields
Date: Tue, 12 Nov 2019 09:11:53 +0100 [thread overview]
Message-ID: <20191112081153.GG100264@gmail.com> (raw)
In-Reply-To: <20191112074052.GD100264@gmail.com>
Here's another one, which makes the pointer-caching logic a bit clearer
IMO:
Firstly, it lines up the two related fields in the namespace:
x86_io_bitmap.last_bitmap => bitmap_copied_ptr
x86_io_bitmap.last_sequence => bitmap_copied_seq
It also constifies the pointer to better signal that it should never
actually be used for anything but comparison
I think the 'bitmap_copied_' ptr/seq pairing makes it more obvious, and
removing the 'last' language makes it a tiny bit clearer that this bitmap
is special because we copied its contents into the TSS.
This makes code like this a tiny bit easier to read IMHO:
+ if (tss->io_bitmap.bitmap_copied_ptr != iobm ||
+ tss->io_bitmap.bitmap_copied_seq != iobm->sequence)
I marked it RFC because you might not agree. :-)
Only build tested.
Thanks,
Ingo
---
arch/x86/include/asm/processor.h | 10 +++++-----
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/process.c | 8 ++++----
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index d1f2c1eb14e9..b45ff7c1419f 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -367,12 +367,12 @@ struct entry_stack_page {
struct x86_io_bitmap
{
/*
- * The bitmap pointer and the sequence number of the last active
- * bitmap. last_bitmap cannot be dereferenced. It's solely for
- * comparison.
+ * The bitmap pointer and the sequence number of the last copied
+ * bitmap. bitmap_copied_ptr must not be dereferenced, it's solely
+ * for comparison.
*/
- struct io_bitmap *last_bitmap;
- u64 last_sequence;
+ const struct io_bitmap *bitmap_copied_ptr;
+ u64 bitmap_copied_seq;
/*
* Store the dirty size of the last io bitmap offender. The next
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a35a557429e7..5a74c5b11b1c 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1861,7 +1861,7 @@ void cpu_init(void)
/* Initialize the TSS. */
tss_setup_ist(tss);
tss->x86_tss.io_bitmap_base = IO_BITMAP_OFFSET_INVALID;
- tss->io_bitmap.last_bitmap = NULL;
+ tss->io_bitmap.bitmap_copied_ptr = NULL;
tss->io_bitmap.bytes_max = 0;
memset(tss->io_bitmap.map_bytes, 0xff, sizeof(tss->io_bitmap.map_bytes));
set_tss_desc(cpu, &get_cpu_entry_area(cpu)->tss.x86_tss);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index c4e76a540b51..ecf97855ed68 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -358,8 +358,8 @@ static void tss_copy_io_bitmap(struct tss_struct *tss, struct io_bitmap *iobm)
* and a pointer to the bitmap itself.
*/
tss->io_bitmap.bytes_max = iobm->bytes_max;
- tss->io_bitmap.last_sequence = iobm->sequence;
- tss->io_bitmap.last_bitmap = iobm;
+ tss->io_bitmap.bitmap_copied_seq = iobm->sequence;
+ tss->io_bitmap.bitmap_copied_ptr = iobm;
}
/**
@@ -388,8 +388,8 @@ void tss_update_io_bitmap(void)
* sequence number differs. The update time is
* accounted to the incoming task.
*/
- if (tss->io_bitmap.last_bitmap != iobm ||
- tss->io_bitmap.last_sequence != iobm->sequence)
+ if (tss->io_bitmap.bitmap_copied_ptr != iobm ||
+ tss->io_bitmap.bitmap_copied_seq != iobm->sequence)
tss_copy_io_bitmap(tss, iobm);
/* Enable the bitmap */
next prev parent reply other threads:[~2019-11-12 8:12 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 22:03 [patch V2 00/16] x86/iopl: Prevent user space from using CLI/STI with iopl(3) Thomas Gleixner
2019-11-11 22:03 ` [patch V2 01/16] x86/ptrace: Prevent truncation of bitmap size Thomas Gleixner
2019-11-12 15:34 ` Andy Lutomirski
2019-11-11 22:03 ` [patch V2 02/16] x86/process: Unify copy_thread_tls() Thomas Gleixner
2019-11-11 22:03 ` [patch V2 03/16] x86/cpu: Unify cpu_init() Thomas Gleixner
2019-11-11 22:03 ` [patch V2 04/16] x86/tss: Fix and move VMX BUILD_BUG_ON() Thomas Gleixner
2019-11-11 22:44 ` Paolo Bonzini
2019-11-12 15:37 ` Andy Lutomirski
2019-11-11 22:03 ` [patch V2 05/16] x86/iopl: Cleanup include maze Thomas Gleixner
2019-11-12 15:37 ` Andy Lutomirski
2019-11-11 22:03 ` [patch V2 06/16] x86/io: Speedup schedule out of I/O bitmap user Thomas Gleixner
2019-11-12 16:00 ` Andy Lutomirski
2019-11-12 17:08 ` Thomas Gleixner
2019-11-11 22:03 ` [patch V2 07/16] x86/ioperm: Move iobitmap data into a struct Thomas Gleixner
2019-11-12 16:02 ` Andy Lutomirski
2019-11-12 17:08 ` Thomas Gleixner
2019-11-11 22:03 ` [patch V2 08/16] x86/ioperm: Add bitmap sequence number Thomas Gleixner
2019-11-12 9:22 ` Peter Zijlstra
2019-11-12 9:55 ` [patch V2 08/16] x86/ioperm: Add bitmap sequence numberc Thomas Gleixner
2019-11-12 16:08 ` [patch V2 08/16] x86/ioperm: Add bitmap sequence number Andy Lutomirski
2019-11-12 17:10 ` Thomas Gleixner
2019-11-11 22:03 ` [patch V2 09/16] x86/ioperm: Move TSS bitmap update to exit to user work Thomas Gleixner
2019-11-12 16:16 ` Andy Lutomirski
2019-11-12 17:20 ` Thomas Gleixner
2019-11-12 17:41 ` Andy Lutomirski
2019-11-12 17:46 ` Linus Torvalds
2019-11-13 8:30 ` Peter Zijlstra
2019-11-11 22:03 ` [patch V2 10/16] x86/ioperm: Remove bitmap if all permissions dropped Thomas Gleixner
2019-11-12 17:43 ` Andy Lutomirski
2019-11-11 22:03 ` [patch V2 11/16] x86/ioperm: Share I/O bitmap if identical Thomas Gleixner
2019-11-12 7:14 ` Ingo Molnar
2019-11-12 7:17 ` Thomas Gleixner
2019-11-12 7:52 ` Ingo Molnar
2019-11-12 9:15 ` Peter Zijlstra
2019-11-12 9:51 ` Thomas Gleixner
2019-11-14 11:02 ` David Laight
2019-11-14 12:39 ` Thomas Gleixner
2019-11-14 13:09 ` Peter Zijlstra
2019-11-14 13:22 ` David Laight
2019-11-12 18:12 ` Andy Lutomirski
2019-11-11 22:03 ` [patch V2 12/16] selftests/x86/ioperm: Extend testing so the shared bitmap is exercised Thomas Gleixner
2019-11-11 22:03 ` [patch V2 13/16] x86/iopl: Fixup misleading comment Thomas Gleixner
2019-11-12 18:14 ` Andy Lutomirski
2019-11-11 22:03 ` [patch V2 14/16] x86/iopl: Restrict iopl() permission scope Thomas Gleixner
2019-11-11 23:03 ` Thomas Gleixner
2019-11-12 6:32 ` Ingo Molnar
2019-11-12 8:42 ` Ingo Molnar
2019-11-12 10:07 ` Thomas Gleixner
2019-11-12 18:35 ` Andy Lutomirski
2019-11-11 22:03 ` [patch V2 15/16] x86/iopl: Remove legacy IOPL option Thomas Gleixner
2019-11-12 18:37 ` Andy Lutomirski
2019-11-12 19:40 ` Thomas Gleixner
2019-11-11 22:03 ` [patch V2 16/16] selftests/x86/iopl: Extend test to cover IOPL emulation Thomas Gleixner
2019-11-12 7:40 ` [PATCH] x86/iopl: Factor out IO-bitmap related TSS fields into 'struct x86_io_bitmap' Ingo Molnar
2019-11-12 7:59 ` [PATCH] x86/iopl: Harmonize 'struct io_bitmap' and 'struct x86_io_bitmap' nomenclature Ingo Molnar
2019-11-12 8:11 ` Ingo Molnar [this message]
2019-11-12 8:15 ` [PATCH] x86/iopl: Rename <asm/iobitmap.h> to <asm/io_bitmap.h> Ingo Molnar
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=20191112081153.GG100264@gmail.com \
--to=mingo@kernel.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=sean.j.christopherson@intel.com \
--cc=stephen@networkplumber.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linuxfoundation.org \
--cc=w@1wt.eu \
--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.