mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: __user annotations
Date: Sat, 7 Jun 2003 14:32:19 +0200	[thread overview]
Message-ID: <20030607143219.U626@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0306061016250.20324-100000@home.transmeta.com>; from torvalds@transmeta.com on Fri, Jun 06, 2003 at 10:28:22AM -0700

Hi Linus,

On Fri, Jun 06, 2003 at 10:28:22AM -0700, Linus Torvalds wrote:
> HOWEVER, usually it's very obvious to fix the whole chain, unless some
> type is sometimes used for kernel addresses and sometimes for user 
> addresses (which networking does with iovec's, for example).
 
Then it's not very useful for me. I usally define the ABI between
user space and kernel space trough IOCTL like that:

/* These structures are usally bigger and nested deeper */
struct in_foo_ioctl_name {
   int bla;
}

struct out_foo_ioctl_name {
   char blubb;
}

union foo_ioctl_name {
   struct in_foo_ioctl_name in;
   struct out_foo_ioctl_name out;
}

#define SUBSYS_IOCTL 0xee

#define SUBSYS_FOO _IOWR(SUBSYS_IOCTL, 0x1, union foo_ioctl_name)

Now I do in principle

   union foo_ioctl_name k, *u = (union foo_ioctl_name *)arg;

   if (copy_from_user(&k.in, &u, sizeof(k.in)) return -EFAULT;
   if (handle_foo(&k)) return -EINVAL;
   if (copy_to_user(&u, &k.out, sizeof(k.out)) return -EFAULT;
   
which I consider very clean (our project provides both: The
only ABI provider and the only ABI user) and works from 2.0
trough 2.5 so far.

This will NOT work anymore with __user annotations, right?

That's a big pity. How do I workaround this? I would like to
help resolving this issues, if you are interested.

Regards

Ingo Oeser

  parent reply	other threads:[~2003-06-07 12:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-05 21:34 [CHECKER][PATCH] awe_wave.c user pointer dereference Hollis Blanchard
2003-06-05 22:07 ` Linus Torvalds
2003-06-06 16:46   ` __user annotations Hollis Blanchard
2003-06-06 17:28     ` Linus Torvalds
2003-06-07  0:32       ` Paul Mackerras
2003-06-07  0:42         ` Sam Ravnborg
2003-06-07  0:52           ` Paul Mackerras
2003-06-07  0:43         ` Linus Torvalds
2003-06-07  1:06           ` Arnaldo Carvalho de Melo
2003-06-07  1:09             ` Paul Mackerras
2003-06-07 16:49           ` Daniel Jacobowitz
2003-06-08  2:17             ` Paul Mackerras
2003-06-07 12:32       ` Ingo Oeser [this message]
2003-06-07 16:25         ` Linus Torvalds
2003-06-07 16:43           ` Sam Ravnborg
2003-06-07 16:48             ` Sam Ravnborg

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=20030607143219.U626@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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

all inboxes | Powered by JetHome®