public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Dave Airlie <airlied@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	LKML <linux-kernel@vger.kernel.org>,
	DRI Development Mailing List  <dri-devel@lists.sourceforge.net>,
	Arnd Bergmann <arnd@arndb.de>, David Miller <davem@davemloft.net>
Subject: Re: is avoiding compat ioctls possible?
Date: Wed, 28 Oct 2009 04:34:55 +0100	[thread overview]
Message-ID: <20091028033455.GF7744@basil.fritz.box> (raw)
In-Reply-To: <21d7e9970910272028n6eaa21fap51f15511d51145a2@mail.gmail.com>

On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
> You mean its impossible to design a 32/64-bit safe ioctl no matter what?

Not impossible, but there's always a rate of mistakes.

> and we should live with having compat ioctls? This isn't something that was very
> clearly stated or documented, the advice we had previously was that
> compat ioctls
> were only required for old ioctls or ioctls with design problems. compat_*64
> didn't exist when this code we designed, and we worked around that, but it was
> in no way mistaken, manually aligning 64-bit values is a perfectly
> good solution,
> not sure why you imply it isn't.

It's true, just saying that even people who try to avoid creating
them often (but not always) need them anyways in the end.

> 
> >
> >> and reviewed to do 32/64-bit properly. The s390 was something I didn't
> >> know about but KMS on s390 is probably never going to be something
> >> that sees the light of day.
> >
> > Well in theory there might be more architectures in the future
> > which rely on compat_ptr
> >
> 
> Well this was what I was trying to gather, so maybe I just need to write
> something up to state that compat_ioctl is always required for new ioctls
> that pass pointers or 64-bit values hiding pointers, so more people
> don't make this mistake going forward. I can say when we inquired about this
> 2 or so years ago when designing kms I didn't get this answer, which is a pity.

Right now you could probably ignore it (if you document it), since
there are no non s390 architectures with this problem, just
prepare mentally that you might need to revisit this at some point.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

  reply	other threads:[~2009-10-28  3:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-28  1:22 is avoiding compat ioctls possible? Dave Airlie
2009-10-28  2:25 ` David Miller
2009-10-28  3:01   ` Dave Airlie
2009-10-28  2:53 ` Andi Kleen
2009-10-28  3:05   ` Dave Airlie
2009-10-28  3:19     ` Andi Kleen
2009-10-28  3:28       ` Dave Airlie
2009-10-28  3:34         ` Andi Kleen [this message]
2009-10-28  3:43           ` David Miller
2009-10-28  3:41         ` David Miller
2009-10-28 21:05       ` Maciej W. Rozycki
2009-10-29  8:27         ` Arnd Bergmann
2009-10-28  3:38     ` David Miller
2009-10-28  3:43       ` Dave Airlie
2009-10-28  3:45         ` David Miller
2009-10-28  3:51           ` Andi Kleen
2009-10-28  3:54           ` Dave Airlie
2009-10-28  5:28             ` David Miller
2009-10-28  5:42               ` Dave Airlie
2009-10-28  6:04                 ` David Miller
2009-10-28  7:53                   ` David Miller
2009-10-28  7:59                     ` Andi Kleen
2009-10-28  8:11                       ` David Miller
2009-10-28  8:19                         ` Andi Kleen
2009-10-28  8:28                           ` David Miller
2009-10-28 12:13                     ` Arnd Bergmann
2009-10-28 12:16                       ` David Miller
2009-10-28 15:40                         ` Arnd Bergmann
2009-10-29  5:41                           ` David Miller
2009-10-29  8:16                             ` Arnd Bergmann
2009-10-29  8:34                             ` Heiko Carstens
2009-10-29  8:39                               ` David Miller
2009-10-28 12:17                       ` David Miller
2009-10-30  1:13                     ` Dave Airlie
2009-10-30 10:13                       ` Arnd Bergmann
2009-11-18  0:26                         ` Dave Airlie
2009-11-18  9:09                           ` Andi Kleen
2009-11-18 14:42                             ` Arnd Bergmann
2009-10-28  3:37   ` David Miller
2009-10-28  4:36     ` Andi Kleen
2009-10-28  5:29       ` David Miller
2009-10-28 10:27       ` Arnd Bergmann

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=20091028033455.GF7744@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=airlied@gmail.com \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=dri-devel@lists.sourceforge.net \
    --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