public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-arch@vger.kernel.org, linux-scsi@vger.kernel.org,
	Akira Takeuchi <takeuchi.akr@jp.panasonic.com>
Subject: Re: SCSI vs MN10300: Can get_user() be given an array?
Date: Fri, 28 Jun 2013 11:16:59 -0700	[thread overview]
Message-ID: <1372443419.1884.12.camel@dabdike> (raw)
In-Reply-To: <5885.1372437573@warthog.procyon.org.uk>

On Fri, 2013-06-28 at 17:39 +0100, David Howells wrote:
> The MN10300 arch is throwing up an error in the SCSI driver and I'm not sure
> whether it needs fixing in the arch - in get_user() - or in the SCSI code.
> 
> The problem is this line in sg_scsi_ioctl():
> 
> 	if (get_user(opcode, sic->data))
> 
> sic points to the following struct:
> 
> 	typedef struct scsi_ioctl_command {
> 		unsigned int inlen;
> 		unsigned int outlen;
> 		unsigned char data[0];
> 	} Scsi_Ioctl_Command;
> 
> However, __get_user_check() on MN10300 does this:
> 
> 	const __typeof__(ptr) __guc_ptr = (ptr);
> 
> which fails with:
> 
> 	block/scsi_ioctl.c:450: error: invalid initializer
> 
> The question is what is SCSI actually asking get_user() to do?  As far as I
> can tell, gcc thinks that it's being askied to declare some sort of array
> here.

I'm surprised you need to ask this.  by convention, an array of char is
usable as a pointer to char *.  The compiler therefore thinks this is a
legitimate conversion which doesn't need a cast:

	unsigned char *d = sic->data;

Therefore, sic->data should be usable as a char * pointer everywhere.

> Should the SCSI driver be changed to:
> 
> 	if (get_user(opcode, (unsigned char *)sic->data))

can we visit reality for a minute?  That proposal would require us to do
an explicit (unsigned char *) conversion everywhere we use an array as a
pointer value ... good grief, no!

> or should the MN10300 arch be changed to morph the array into a pointer,
> perhaps with:
> 
> 	const __typeof__(ptr[0])* __guc_ptr = (ptr);

Neither.  It should do what every other architecture does, which is:

	const __typeof__(*(ptr)) *__guc_ptr = (ptr);

James

      reply	other threads:[~2013-06-28 18:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-28 16:39 SCSI vs MN10300: Can get_user() be given an array? David Howells
2013-06-28 18:16 ` James Bottomley [this message]

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=1372443419.1884.12.camel@dabdike \
    --to=james.bottomley@hansenpartnership.com \
    --cc=dhowells@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=takeuchi.akr@jp.panasonic.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