public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: never write to the userspace more data than the caller wants
Date: Thu, 17 Oct 2013 10:58:24 -0400	[thread overview]
Message-ID: <20131017105824.74960f34@IRBT4585> (raw)
In-Reply-To: <20131017122647.GC6862@nuc-i3427.alporthouse.com>

On Thu, 17 Oct 2013 13:26:47 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote:
> > The amount of data wanted by the userspace caller is encoded in the
> > ioctl number.  Generic drm ioctls were ignoring it.
> > 
> > As a result, Intel Xorg driver didn't work for i386 userspace on
> > x86_64 kernel on some systems.  sizeof(struct
> > drm_mode_get_connector) is 76 bytes on i686 and 80 bytes on x86_64
> > due to the tail alignment (the data positions match).  The
> > userspace was using the 4 bytes after the structure to hold the
> > result of the ioctl.  Since drm_ioctl() was copying 80 bytes
> > instead of 76, it was clobbering that data.
> > 
> > A workaround has been committed to xf86-video-intel.
> > 
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
> > Cc: stable@vger.kernel.org
> 
> Similar patch:
> http://lists.freedesktop.org/archives/dri-devel/2013-October/047412.html
> -Chris

Wow, it's great that you also thought about it!

Your patch does almost the same thing.  There is one difference.  If
the userspace requests more data than the kernel needs, your patch would
trust the userspace and set usize to whatever the user wants.  It would
set asize to the same value, allocating more memory than the driver
wants, up to 16383 bytes.  I don't think it's a good idea for
performance reasons.  My patch would decrease usize rather than increase
asize.

The code for driver-specific ioctls could be fixed too, it's just not
so urgent as fixing a real bug.

That said, I have no format objection against your patch.  It would be
great to have that bug fixed.

-- 
Regards,
Pavel Roskin

      reply	other threads:[~2013-10-17 14:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-17  0:12 [PATCH] drm: never write to the userspace more data than the caller wants Pavel Roskin
2013-10-17 12:26 ` Chris Wilson
2013-10-17 14:58   ` Pavel Roskin [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=20131017105824.74960f34@IRBT4585 \
    --to=proski@gnu.org \
    --cc=airlied@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.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