From: linux@MichaelGeng.de (Michael Geng)
To: Gerd Knorr <kraxel@bytesex.org>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: video_usercopy() enforces change of VideoText IOCTLs since 2.6.8
Date: Sat, 9 Oct 2004 13:28:39 +0200 [thread overview]
Message-ID: <20041009112839.GA2908@t-online.de> (raw)
In-Reply-To: <20041009092801.GC3482@bytesex>
On Sat, Oct 09, 2004 at 11:28:01AM +0200, Gerd Knorr wrote:
> > > /* Copy arguments into temp kernel buffer */
> > > switch (_IOC_DIR(cmd)) {
> > > case _IOC_NONE:
> > > - parg = NULL;
> > > + parg = (void*)arg;
> > > break;
> >
> > (the typecast is unneeded)
> >
> > Seems that with this change we are now sometimes passing a user pointer
> > into (*func)(). And we're sometimes passing a kernel pointer, yes?
>
> Assuming that ioctls passing _pointers_ are declared correctly with _IO*
> that shouldn't be the case: _IOC_DIR(cmd) == _IOC_NONE means _IO()
> means no pointer passed in.
>
> > Are all the implementations of (*func)() handling that correctly?
>
> Hmm, it broke for videotext, checking ...
>
> Ok, you can drop it. The videotext ioctls (include/videotext.h) don't
> use the _IO*() macros but pass around pointers anyway, thats bad.
>
> Michael, you'll have to fix the saa5246a driver. video_usercopy() will
> not work for you because the videotext ioctls doesn't use the _IO()
> macros. You have to do the userspace copying in the driver yourself.
I would prefer fixing the IOCTLs in include/linux/videotext.h. These definitions
are older than the _IO macros in linux/ioctl.h AFAIK. So it is clear that they
can't conform to that definition. I would prefer redefining them with respect
to the arguments passed to the IOCTLs.
This would be a little step towards unifying the kernel. Implementing a private
usercopy in saa5246a.c and saa5249.c would be the opposite.
The concept with the _IO() macros is good and helps preventing errors in the
use of IOCTLs. So also the videotext drivers should use it.
Nevertheless there is one big disadvantage: The userspace programs
have to be recompiled because they of course have to use the same IOCTL
definitions.
Nevertheless, affected are only saa5246a.c and saa5249.c. I think that there
are not many people left in the world using these drivers. So I think we can
afford to make a break here.
Do you agree? If so then I will work out a patch.
Michael
next prev parent reply other threads:[~2004-10-09 11:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 16:54 video_usercopy() enforces change of VideoText IOCTLs since 2.6.8 Michael Geng
2004-10-08 10:52 ` Gerd Knorr
2004-10-08 21:00 ` Andrew Morton
2004-10-09 9:28 ` Gerd Knorr
2004-10-09 11:28 ` Michael Geng [this message]
2004-10-09 12:18 ` Gerd Knorr
2004-10-10 8:55 ` Michael Geng
2004-10-11 15:14 ` Gerd Knorr
2004-10-11 16:21 ` Michael Geng
2004-10-13 11:00 ` Alan Cox
2004-10-13 14:42 ` Michael Geng
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=20041009112839.GA2908@t-online.de \
--to=linux@michaelgeng.de \
--cc=akpm@osdl.org \
--cc=kraxel@bytesex.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 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.