All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Johannes Berg <johannes.berg@intel.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] scsi: pmcraid: use __iomem pointers for ioctl argument
Date: Thu, 20 Apr 2017 20:24:46 +0100	[thread overview]
Message-ID: <20170420192446.GS29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20170420175549.3435196-1-arnd@arndb.de>

On Thu, Apr 20, 2017 at 07:54:45PM +0200, Arnd Bergmann wrote:
> kernelci.org reports a new compile warning for old code in the pmcraid
> driver:
> 
> arch/mips/include/asm/uaccess.h:138:21: warning: passing argument 1 of '__access_ok' makes pointer from integer without a cast [-Wint-conversion]
> 
> The warning got introduced by a cleanup to the access_ok() helper
> that requires the argument to be a pointer, where the old version
> silently accepts 'unsigned long' arguments as it still does on most
> other architectures.
> 
> The new behavior in MIPS however seems absolutely sensible, and so far I
> could only find one other file with the same issue, so the best solution
> seems to be to clean up the pmcraid driver.
> 
> This makes the driver consistently use 'void __iomem *' pointers for
> passing around the address of the user space ioctl arguments, which gets
> rid of the kernelci warning as well as several sparse warnings.

Is there any point in keeping that access_ok() in the first place, rather
than just switching to copy_from_user()/copy_to_user() in there?  AFAICS,
it's only for the sake of the loop in pmcraid_copy_sglist():
        for (i = 0; i < (len / bsize_elem); i++, buffer += bsize_elem) {
                struct page *page = sg_page(&scatterlist[i]);

                kaddr = kmap(page);
                if (direction == DMA_TO_DEVICE)
                        rc = __copy_from_user(kaddr,
                                              (void *)buffer,
                                              bsize_elem);
                else   
                        rc = __copy_to_user((void *)buffer, kaddr, bsize_elem);

                kunmap(page);

                if (rc) {
                        pmcraid_err("failed to copy user data into sg list\n");
                        return -EFAULT;
                }

                scatterlist[i].length = bsize_elem;
        }   
and seeing that each of those calls copies is at least a full page...  If
there is an architecture where a single access_ok() costs a noticable fraction
of the time it takes to copy a full page, we have a much worse problem than
overhead in obscure ioctl...

  parent reply	other threads:[~2017-04-20 19:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20 17:54 [PATCH 1/4] scsi: pmcraid: use __iomem pointers for ioctl argument Arnd Bergmann
2017-04-20 17:54 ` [PATCH 2/4] scsi: pmcraid: fix lock imbalance in pmcraid_reset_reload() Arnd Bergmann
2017-04-23  8:36   ` Christoph Hellwig
2017-04-24 22:02     ` Martin K. Petersen
2017-04-20 17:54 ` [PATCH 3/4] scsi: pmcraid: fix endianess sparse annotations Arnd Bergmann
2017-04-23  8:38   ` Christoph Hellwig
2017-04-20 17:54 ` [PATCH 4/4] scsi: pmcraid: fix minor sparse warnings Arnd Bergmann
2017-04-23  8:39   ` Christoph Hellwig
2017-04-20 19:24 ` Al Viro [this message]
2017-04-21 22:01   ` [PATCH 1/4] scsi: pmcraid: use __iomem pointers for ioctl argument Arnd Bergmann
2017-04-21 22:02 ` [PATCH] scsi: pmcraid: use normal copy_from_user Arnd Bergmann
2017-04-23  8:28   ` Christoph Hellwig
2017-04-24 22:13   ` Martin K. Petersen

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=20170420192446.GS29622@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=arnd@arndb.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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 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.