Date: Sun, 19 Aug 2012 09:43:32 +0800 From: Meowthink <meowthink@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-x11@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: [CFT]Patch for dri / drm interoperability i386 world / amd64 kernel Message-ID: <CABnABobMbR=Zp5Ppd6heVO9mV7iqmBxuZ4RMr9zXP441-mRSXQ@mail.gmail.com> In-Reply-To: <20120818190225.GF33100@deviant.kiev.zoral.com.ua> References: <CABnABoZKENJqcoQbkw6A0hJY_YY6Y0-FUM6GghtE%2Ba4wH7GwVA@mail.gmail.com> <20120818190225.GF33100@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 19, 2012 at 3:02 AM, Konstantin Belousov
<kostikbel@gmail.com> wrote:
> On Sat, Aug 11, 2012 at 09:25:09AM +0800, Meowthink wrote:
>> Hello all,
>>
>> So long FreeBSD's DRI implementation lacks of i386/amd64
>> interoperability, as discussed [0] [1]. This breaks wine, linuxulator
>> etc. drawing using DRI-based OpenGL.
>> Paul Mackerras et al. actually did that part for Linux implementation,
>> so I simply translated their work to FreeBSD. Due to my poor
>> programming skills, there's some limitations:
>> 0. I tried to split compatible codes into separate files, like under
>> Linux. But as a result of the difference between FreeBSD and Linux,
>> the code is integrated in a "#include ...ioc32.c" form which is not
>> so elegant.
>> 1. For same reason, struct drm_driver_info has to be changed.
> I fixed 0 and 1 to my liking and committed the patch.
>
> Thank you.
>
>> 2. There should be some assertions if a 64-bit pointer failed to fit
>> in a 32-bit space. Linux implementation didn't do this either, but
>> they're guaranteed by user-space ioctl structures. This may result
>> unstable under heavy load.
> I am not sure what do you mean exactly. Can you elaborate, please ?
Excuse me for my poor expression. What I mean is, for example, line
177-180 in sys/dev/drm2/drm_ioc32.c reads:
handle = map.handle;
m32->mtrr = map.mtrr;
m32->handle = (unsigned long)handle;
drm_map.handle will be a 64-bit pointer under 64-bit mode, so I wonder
this needs verification? But Linux version of drm didn't verify:
if (__get_user(m32.offset, &map->offset)
|| __get_user(m32.size, &map->size)
|| __get_user(m32.type, &map->type)
|| __get_user(m32.flags, &map->flags)
|| __get_user(handle, &map->handle)
|| __get_user(m32.mtrr, &map->mtrr))
return -EFAULT;
m32.handle = (unsigned long)handle;
if (copy_to_user(argp, &m32, sizeof(m32)))
return -EFAULT;
In this case, drm_addmap(drm_bufs.c) guarantee the handle always a
32-bit integer, with 0s only in high 32 bits on amd64. But I'm not
very sure that all kinds of this pointer operations, esp. those
buffer-related address ops can guarantee a 32-bit pointer in all
cases.
Thanks for your review.
Meowthink
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABnABobMbR=Zp5Ppd6heVO9mV7iqmBxuZ4RMr9zXP441-mRSXQ>