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: Harmonize 'struct io_bitmap' and 'struct x86_io_bitmap' nomenclature
Date: Tue, 12 Nov 2019 08:59:42 +0100 [thread overview]
Message-ID: <20191112075942.GF100264@gmail.com> (raw)
In-Reply-To: <20191112074052.GD100264@gmail.com>
* Ingo Molnar <mingo@kernel.org> wrote:
> How about the patch below?
>
> It reorganizes all those fields into a new container structure, 'struct
> x86_io_bitmap', adds it as tss.io_bitmap, and uses the prefix to shorten
> and organize the names of the fields:
>
> tss.last_bitmap => tss.io_bitmap.last_bitmap
> tss.last_sequence => tss.io_bitmap.last_sequence
> tss.io_bitmap_prev_max => tss.io_bitmap.prev_max
> tss.io_bitmap_bytes => tss.io_bitmap.map_bytes
> tss.io_bitmap_all => tss.io_bitmap.map_all
>
> This makes it far more readable, and the local variable references as
> short and tidy:
>
> iobm->last_bitmap
> iobm->last_sequence
> iobm->prev_max
> iobm->map_bytes
> iobm->map_all
>
> Only build tested.
On top of this we can now do the slight reorganization of field names
below.
io_bitmap.io_bitmap_max => bytes_max
x86_io_bitmap.prev_max => bytes_max
The point is to harmonize the fields in 'struct io_bitmap' with 'struct
x86_io_bitmap':
io_bitmap.map_bytes io_bitmap.bytes_max
iobm.map_bytes iobm.bytes_max
which makes following segments of code really tidy:
memcpy(tss->io_bitmap.map_bytes, iobm->map_bytes,
max(tss->io_bitmap.bytes_max, iobm->bytes_max));
The other point is to remove the 'prev' notion from the TSS data field -
there's very little "previous" about this - we have this bitmap loaded
right now.
Also note the cleanup of the bits/bytes union:
iobm->bits => iobm->map_bits
iobm->bitmap_bytes => iobm->map_bytes
Only build tested, but 100% perfect, guaranteed.
Thanks,
Ingo
---
arch/x86/include/asm/iobitmap.h | 6 +++---
arch/x86/include/asm/processor.h | 2 +-
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/ioport.c | 10 +++++-----
arch/x86/kernel/process.c | 6 +++---
arch/x86/kernel/ptrace.c | 4 ++--
6 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/iobitmap.h b/arch/x86/include/asm/iobitmap.h
index a075f0c55fb3..faba42c7d3de 100644
--- a/arch/x86/include/asm/iobitmap.h
+++ b/arch/x86/include/asm/iobitmap.h
@@ -8,10 +8,10 @@
struct io_bitmap {
u64 sequence;
refcount_t refcnt;
- unsigned int io_bitmap_max;
+ unsigned int bytes_max;
union {
- unsigned long bits[IO_BITMAP_LONGS];
- unsigned char bitmap_bytes[IO_BITMAP_BYTES];
+ unsigned long map_bits[IO_BITMAP_LONGS];
+ unsigned char map_bytes[IO_BITMAP_BYTES];
};
};
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 4358ae63c252..d1f2c1eb14e9 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -381,7 +381,7 @@ struct x86_io_bitmap
* outside of the TSS limit. So for sane tasks there is no need to
* actually touch the io_bitmap at all.
*/
- unsigned int prev_max;
+ unsigned int bytes_max;
/*
* The extra 1 is there because the CPU will access an
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index eea0e3170de4..a35a557429e7 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1862,7 +1862,7 @@ void cpu_init(void)
tss_setup_ist(tss);
tss->x86_tss.io_bitmap_base = IO_BITMAP_OFFSET_INVALID;
tss->io_bitmap.last_bitmap = NULL;
- tss->io_bitmap.prev_max = 0;
+ 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/ioport.c b/arch/x86/kernel/ioport.c
index ee37a1c25ecc..203f82383bf6 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -86,7 +86,7 @@ long ksys_ioperm(unsigned long from, unsigned long num, int turn_on)
if (!iobm)
return -ENOMEM;
- memset(iobm->bits, 0xff, sizeof(iobm->bits));
+ memset(iobm->map_bits, 0xff, sizeof(iobm->map_bits));
refcount_set(&iobm->refcnt, 1);
}
@@ -112,9 +112,9 @@ long ksys_ioperm(unsigned long from, unsigned long num, int turn_on)
* exit to user mode. So this needs no protection.
*/
if (turn_on)
- bitmap_clear(iobm->bits, from, num);
+ bitmap_clear(iobm->map_bits, from, num);
else
- bitmap_set(iobm->bits, from, num);
+ bitmap_set(iobm->map_bits, from, num);
/*
* Search for a (possibly new) maximum. This is simple and stupid,
@@ -122,7 +122,7 @@ long ksys_ioperm(unsigned long from, unsigned long num, int turn_on)
*/
max_long = UINT_MAX;
for (i = 0; i < IO_BITMAP_LONGS; i++) {
- if (iobm->bits[i] != ~0UL)
+ if (iobm->map_bits[i] != ~0UL)
max_long = i;
}
@@ -132,7 +132,7 @@ long ksys_ioperm(unsigned long from, unsigned long num, int turn_on)
return 0;
}
- iobm->io_bitmap_max = (max_long + 1) * sizeof(unsigned long);
+ iobm->bytes_max = (max_long + 1) * sizeof(unsigned long);
/* Increment the sequence number to force a TSS update */
iobm->sequence = atomic64_add_return(1, &io_bitmap_sequence);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 8179f3ee6a55..c4e76a540b51 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -350,14 +350,14 @@ static void tss_copy_io_bitmap(struct tss_struct *tss, struct io_bitmap *iobm)
* permitted, then the copy needs to cover those as well so they
* get turned off.
*/
- memcpy(tss->io_bitmap.map_bytes, iobm->bitmap_bytes,
- max(tss->io_bitmap.prev_max, iobm->io_bitmap_max));
+ memcpy(tss->io_bitmap.map_bytes, iobm->map_bytes,
+ max(tss->io_bitmap.bytes_max, iobm->bytes_max));
/*
* Store the new max and the sequence number of this bitmap
* and a pointer to the bitmap itself.
*/
- tss->io_bitmap.prev_max = iobm->io_bitmap_max;
+ tss->io_bitmap.bytes_max = iobm->bytes_max;
tss->io_bitmap.last_sequence = iobm->sequence;
tss->io_bitmap.last_bitmap = iobm;
}
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 6baa5a1a9f1c..f27c322f1c93 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -700,7 +700,7 @@ static int ioperm_active(struct task_struct *target,
{
struct io_bitmap *iobm = target->thread.io_bitmap;
- return iobm ? DIV_ROUND_UP(iobm->io_bitmap_max, regset->size) : 0;
+ return iobm ? DIV_ROUND_UP(iobm->bytes_max, regset->size) : 0;
}
static int ioperm_get(struct task_struct *target,
@@ -714,7 +714,7 @@ static int ioperm_get(struct task_struct *target,
return -ENXIO;
return user_regset_copyout(&pos, &count, &kbuf, &ubuf,
- iobm->bitmap_bytes, 0, IO_BITMAP_BYTES);
+ iobm->map_bytes, 0, IO_BITMAP_BYTES);
}
/*
next prev parent reply other threads:[~2019-11-12 7:59 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 ` Ingo Molnar [this message]
2019-11-12 8:11 ` [PATCH] x86/iopl: Clear up the role of the two bitmap copying fields Ingo Molnar
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=20191112075942.GF100264@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.