From: Andrew Morton <akpm@linux-foundation.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
linux-kernel@vger.kernel.org,
"Greg Kroah-Hartman" <gregkh@suse.de>,
Arthur Taylor <art@ified.ca>, Jiri Slaby <jslaby@suse.cz>,
Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH] Fix KDFONTOP 32bit compatibility layer
Date: Tue, 31 Jan 2012 11:15:53 -0800 [thread overview]
Message-ID: <20120131111553.e69ab58b.akpm@linux-foundation.org> (raw)
In-Reply-To: <201201311635.36367.arnd@arndb.de>
On Tue, 31 Jan 2012 16:35:36 +0000
Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 28 January 2012, Samuel Thibault wrote:
> > KDFONTOP(GET) currently fails with EIO when being run in a 32bit
> > userland with a 64bit kernel if the font width is not 8. This is because
> > the compatibility layer introduced by e9216651 forces the addition of
> > the KD_FONT_FLAG_OLD flag, which makes con_font_get return EIO in such
> > case. This flag should not be set for KDFONTOP, since it's actually
> > the whole point of this flag (see comment in con_font_set for instance).
> >
> > Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
> Hmm, this flag was not introduced in the patch you cite, it used to
> live in fs/compat_ioctl.c before that, since before the start of the
> git history. It seems to date back on the original sparc64 implementation
> of do_kdfontop_ioctl that was written by Eddie Dost in 1998.
>
> > diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
> > index 5e096f4..65447c5 100644
> > --- a/drivers/tty/vt/vt_ioctl.c
> > +++ b/drivers/tty/vt/vt_ioctl.c
> > @@ -1463,7 +1463,6 @@ compat_kdfontop_ioctl(struct compat_console_font_op __user *fontop,
> > if (!perm && op->op != KD_FONT_OP_GET)
> > return -EPERM;
> > op->data = compat_ptr(((struct compat_console_font_op *)op)->data);
> > - op->flags |= KD_FONT_FLAG_OLD;
> > i = con_font_op(vc, op);
> > if (i)
> > return i;
>
> From all I can tell, the patch looks correct, but please update the
> description so you don't blame my innocent patch ;-)
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Yes, we should note the fact that at least one kernel bug isn't your
fault ;)
I changed the changelog to
: KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
: with a 64bit kernel if the font width is not 8.
:
: This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
: con_font_get return EIO in such case.
:
: This flag should *not* be set for KDFONTOP, since it's actually the whole
: point of this flag (see comment in con_font_set for instance).
:
: Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
: Reviewed-by: Arnd Bergmann <arnd@arndb.de>
: Cc: Greg Kroah-Hartman <gregkh@suse.de>
: Cc: Arthur Taylor <art@ified.ca>
: Cc: Jiri Slaby <jslaby@suse.cz>
: Cc: Jiri Olsa <jolsa@redhat.com>
: Cc: <stable@vger.kernel.org>
prev parent reply other threads:[~2012-01-31 19:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-28 23:28 [PATCH] Fix KDFONTOP 32bit compatibility layer Samuel Thibault
2012-01-31 16:35 ` Arnd Bergmann
2012-01-31 19:15 ` Andrew Morton [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=20120131111553.e69ab58b.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=art@ified.ca \
--cc=gregkh@suse.de \
--cc=jolsa@redhat.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel.thibault@ens-lyon.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.