public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@linuxtv.org>
To: Hans Petter Selasky <hselasky@c2i.net>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] FE_GET_PROPERTY should be _IOW, because the associated structure is transferred from userspace to kernelspace. Keep the old ioctl around for compatibility so that existing code is not broken.
Date: Mon, 23 May 2011 17:32:23 +0200	[thread overview]
Message-ID: <4DDA7E07.7070907@linuxtv.org> (raw)
In-Reply-To: <201105231651.55945.hselasky@c2i.net>

On 05/23/2011 04:51 PM, Hans Petter Selasky wrote:
> On Monday 23 May 2011 16:37:18 Andreas Oberritter wrote:
>> On 05/23/2011 03:58 PM, Hans Petter Selasky wrote:
>>> From be7d0f72ebf4d945cfb2a5c9cc871707f72e1e3c Mon Sep 17 00:00:00 2001
>>> From: Hans Petter Selasky <hselasky@c2i.net>
>>> Date: Mon, 23 May 2011 15:56:31 +0200
>>> Subject: [PATCH] FE_GET_PROPERTY should be _IOW, because the associated
>>> structure is transferred from userspace to kernelspace. Keep the old
>>> ioctl around for compatibility so that existing code is not broken.
>>
> 
> Hi,
> 
>> Good catch, but I think _IOWR would be right, because the result gets
>> copied from kernelspace to userspace.
> 
> Those flags are only for the IOCTL associated structure itself. The V4L DVB 
> kernel only reads the dtv_properties structure in either case and does not 
> write any data back to it. That's why only _IOW is required.

I see.

> I checked somewhat and the R/W bits in the IOCTL command does not appear do be 
> matched to the R/W permissions you have on the file handle? Or am I mistaken?

You're right. There's no direct relationship between them, at least not
within dvb-core.

> In other words the IOCTL R/W (_IOC_READ, _IOC_WRITE) bits should not reflect 
> what the IOCTL actually does, like modifying indirect data?

I'm not sure. Your patch is certainly doing the right thing for the
current implementation of dvb_usercopy, which however wasn't designed
with variable length arrays in mind.

Taking dvb_usercopy aside, my interpretation of the ioctl bits was:
- _IOC_READ is required if copy_to_user/put_user needs to be used during
the ioctl.
- _IOC_WRITE is required if copy_from_user/get_user needs to be used
during the ioctl.

Whether that's limited to the structure directly encoded in the ioctl or
not is unclear to me. Maybe someone at LKML can shed some light on that.

Regards,
Andreas

  reply	other threads:[~2011-05-23 15:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-23 13:58 [PATCH] FE_GET_PROPERTY should be _IOW, because the associated structure is transferred from userspace to kernelspace. Keep the old ioctl around for compatibility so that existing code is not broken Hans Petter Selasky
2011-05-23 14:37 ` Andreas Oberritter
2011-05-23 14:51   ` Hans Petter Selasky
2011-05-23 15:32     ` Andreas Oberritter [this message]
2011-06-01 21:15       ` Mauro Carvalho Chehab
2011-06-03 12:44         ` Andreas Oberritter
2011-06-03 13:55           ` Mauro Carvalho Chehab

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=4DDA7E07.7070907@linuxtv.org \
    --to=obi@linuxtv.org \
    --cc=hselasky@c2i.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    /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