From: josh@joshtriplett.org
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Kees Cook <keescook@chromium.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
Date: Mon, 3 Nov 2014 08:45:39 -0800 [thread overview]
Message-ID: <20141103164539.GA18104@cloud> (raw)
In-Reply-To: <20141103152748.327032f8@alan.etchedpixels.co.uk>
On Mon, Nov 03, 2014 at 03:27:48PM +0000, One Thousand Gnomes wrote:
> > > This isn't unreasonable but there are drivers with userspace helpers that
> > > use iopl/ioperm type functionality where you should be doing a SELECT of
> > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick
> > > scan it may these days be the only mainstream one that needs the select
> > > adding.
> >
> > Should kernel drivers really express dependencies that only their
> > (current instances of) corresponding userspace components need?
> > Something seems wrong about that.
>
> uvesafb will always need X86_IOPORT. It's kind of implicit in the design.
> I'm not suggesting that fbdev should select X86_IOPORT but in the uvesafb
> case at least it's completely useless to have one and not the other.
OK, fair enough. Do you want the patch series respun to add that select
in patch 10/10, or would you consider it sufficient to add that in a
followup patch, since the kernel will build and boot either way (so it
won't break bisection)?
Related to that: Is it intentional that FB_UVESA doesn't depend on X86,
even though FB_VESA does? Does v86d run on non-x86 hardware via
emulation? If so, should FB_UVESA have "select X86_IOPORT if X86"?
- Josh Triplett
WARNING: multiple messages have this Message-ID (diff)
From: josh@joshtriplett.org
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Kees Cook <keescook@chromium.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, x86@kernel.org
Subject: Re: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
Date: Mon, 3 Nov 2014 08:45:39 -0800 [thread overview]
Message-ID: <20141103164539.GA18104@cloud> (raw)
In-Reply-To: <20141103152748.327032f8@alan.etchedpixels.co.uk>
On Mon, Nov 03, 2014 at 03:27:48PM +0000, One Thousand Gnomes wrote:
> > > This isn't unreasonable but there are drivers with userspace helpers that
> > > use iopl/ioperm type functionality where you should be doing a SELECT of
> > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick
> > > scan it may these days be the only mainstream one that needs the select
> > > adding.
> >
> > Should kernel drivers really express dependencies that only their
> > (current instances of) corresponding userspace components need?
> > Something seems wrong about that.
>
> uvesafb will always need X86_IOPORT. It's kind of implicit in the design.
> I'm not suggesting that fbdev should select X86_IOPORT but in the uvesafb
> case at least it's completely useless to have one and not the other.
OK, fair enough. Do you want the patch series respun to add that select
in patch 10/10, or would you consider it sufficient to add that in a
followup patch, since the kernel will build and boot either way (so it
won't break bisection)?
Related to that: Is it intentional that FB_UVESA doesn't depend on X86,
even though FB_VESA does? Does v86d run on non-x86 hardware via
emulation? If so, should FB_UVESA have "select X86_IOPORT if X86"?
- Josh Triplett
next prev parent reply other threads:[~2014-11-03 16:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-02 17:31 [PATCH v4 00/10] x86: Support compiling out userspace IO (iopl and ioperm) Josh Triplett
2014-11-02 17:31 ` [PATCH v4 01/10] x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling Josh Triplett
2014-11-02 17:31 ` Josh Triplett
2014-11-02 17:32 ` [PATCH v4 02/10] x86: tss: Eliminate fragile calculation of TSS segment limit Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` [PATCH v4 03/10] x86: processor.h: Introduce macros to initialize IO fields of thread and TSS Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` [PATCH v4 04/10] x86: paravirt: Wrap initialization of set_iopl_mask in a macro Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-12-01 15:37 ` [Xen-devel] " Konrad Rzeszutek Wilk
2014-12-01 15:37 ` Konrad Rzeszutek Wilk
2014-12-01 15:37 ` Konrad Rzeszutek Wilk
2014-11-02 17:32 ` [PATCH v4 05/10] x86: cpu: Add helper function unifying 32-bit and 64-bit IO init in cpu_init Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` [PATCH v4 06/10] x86: process: Introduce helper to clear a thread's IO bitmap Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` [PATCH v4 07/10] x86: process: Introduce helper to switch iopl mask Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` [PATCH v4 08/10] x86: process: Introduce helper for IO-related bits of exit_thread Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` [PATCH v4 09/10] x86: process: Introduce helper to switch IO bitmap Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:32 ` Josh Triplett
2014-11-02 17:33 ` [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm) Josh Triplett
2014-11-02 17:33 ` Josh Triplett
2014-11-03 12:10 ` One Thousand Gnomes
2014-11-03 12:10 ` One Thousand Gnomes
2014-11-03 14:13 ` Josh Triplett
2014-11-03 14:13 ` Josh Triplett
2014-11-03 15:27 ` One Thousand Gnomes
2014-11-03 15:27 ` One Thousand Gnomes
2014-11-03 16:45 ` josh [this message]
2014-11-03 16:45 ` josh
2014-11-03 19:26 ` Andy Lutomirski
2014-11-03 19:26 ` Andy Lutomirski
2014-11-02 17:33 ` Josh Triplett
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=20141103164539.GA18104@cloud \
--to=josh@joshtriplett.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.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 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.