Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1370818

Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*)

From Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups linux.kernel
Subject Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*)
Date 2016-04-04 20:50 +0200
Message-ID <rkhJv-7va-7@gated-at.bofh.it> (permalink)
References <rk3wR-5mQ-1@gated-at.bofh.it> <rk6Eq-7Fc-17@gated-at.bofh.it> <rkgks-6rb-35@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Apr 04, 2016 at 06:16:12PM +0100, Al Viro wrote:

> will see NULL map_data; the ->from_user case is sg_start_req() stuff.  IOW,
> SG_IO behaviour for /dev/sg* is different from the generic one...

While we are at it: in bio_map_user_iov() we have
        iov_for_each(iov, i, *iter) { 
                unsigned long uaddr = (unsigned long) iov.iov_base;
                unsigned long len = iov.iov_len;
                unsigned long end = (uaddr + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
                unsigned long start = uaddr >> PAGE_SHIFT;

                /*
                 * Overflow, abort
                 */
                if (end < start)
                        return ERR_PTR(-EINVAL);

                nr_pages += end - start;
                /*
                 * buffer must be aligned to at least hardsector size for now
                 */
                if (uaddr & queue_dma_alignment(q))
                        return ERR_PTR(-EINVAL);
        }

Do we only care about the iov_base alignment?  IOW, shouldn't we check for
iov_len being a multiple of queue_dma_alignment(q) as well?

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-04 05:40 +0200
  Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Christoph Hellwig <hch@infradead.org> - 2016-04-04 09:00 +0200
    Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-04 19:20 +0200
      Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-04 20:50 +0200
        Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-04 22:00 +0200
          Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-05 01:50 +0200
            Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Christoph Hellwig <hch@infradead.org> - 2016-04-07 18:00 +0200
              Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Al Viro <viro@ZenIV.linux.org.uk> - 2016-04-08 21:30 +0200
      Re: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD  (drivers/block/skd*) Christoph Hellwig <hch@infradead.org> - 2016-04-07 18:00 +0200

csiph-web