[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20091027.222814.137568780.davem@davemloft.net>
Date: Tue, 27 Oct 2009 22:28:14 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: airlied@...ux.ie
Cc: dri-devel@...ts.sourceforge.net, andi@...stfloor.org,
linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: is avoiding compat ioctls possible?
From: Dave Airlie <airlied@...ux.ie>
Date: Wed, 28 Oct 2009 03:54:34 +0000 (GMT)
>>
>> > we already opencoded this (probably before it was macroisied or we just
>> > pasted it), so the radeon one is buggy, I should just go and compat_* all
>> > of these then and we should be all happy?
>>
>> It should be, it's only working because:
>>
>> 1) A malicious userland hasn't put garbage in the upper bits for
>> you yet.
>>
>> 2) Nobody has tested s390 yet :-)
>>
>
> So will an inline like this work?
>
> static inline void *__user convert_user_ptr(uint64_t ioctl_ptr)
> {
Please don't do this.
This is exactly what I feared people would do when is_compat_task()
was added. is_compat_task() is for situations where there is
otherwise no other way to handle the compat situation properly.
It's not that much work for you to hook up the compat ioctls properly,
and if you are clever you can do it in such a way that you'll get
warnings if someone accidently adds a new ioctl but forgets the
compat bits :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists