From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jens Axboe <axboe@fb.com>
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org
Subject: [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*)
Date: Mon, 4 Apr 2016 04:38:45 +0100 [thread overview]
Message-ID: <20160404033845.GE17997@ZenIV.linux.org.uk> (raw)
SG_DXFER_TO_FROM_DEV is weird everywhere, but skd manages to get it
even stranger than usual: copying to/from userland happens in
skd_sg_io_copy_buffer(), which is called twice - once before the actual
talking to device and once after. The first call either does nothing or
copies from userland, the second one either does nothing or copies to
userland. So far, so good, but the logics in that sucker deciding whether
to bugger off or not is wrong:
if (dxfer_dir != sksgio->sg.dxfer_direction) {
if (dxfer_dir != SG_DXFER_TO_DEV ||
sksgio->sg.dxfer_direction != SG_DXFER_TO_FROM_DEV)
return 0;
}
The first call is with dxfer_dir equal to SG_DXFER_TO_DEV, the second -
SG_DXFER_FROM_DEV. So we get
SG_DXFER_NONE: nothing nothing
SG_DXFER_FROM_DEV: nothing out
SG_DXFER_TO_DEV: in nothing
SG_DXFER_TO_FROM_DEV: in nothing
I've no idea if anything is still using SG_DXFER_TO_FROM_DEV, but this
behaviour AFAICS doesn't match that of write() on /dev/sg* (both
in and out are done) or normal SG_IO (either both in and out, in case if it
hits bio_map_user_iov(), or only out if it hits bio_copy_user_iov()). In
all cases the out part is done. Here it is skipped.
Not sure who (if anybody) maintains it these days, but that behaviour looks
wrong...
next reply other threads:[~2016-04-04 3:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 3:38 Al Viro [this message]
2016-04-04 6:52 ` [RFC] weird semantics of SG_DXFER_TO_FROM_DEV in BLK_DEV_SKD (drivers/block/skd*) Christoph Hellwig
2016-04-04 17:16 ` Al Viro
2016-04-04 18:47 ` Al Viro
2016-04-04 19:50 ` Al Viro
2016-04-04 23:45 ` Al Viro
2016-04-07 15:55 ` Christoph Hellwig
2016-04-08 19:19 ` Al Viro
2016-04-07 15:53 ` Christoph Hellwig
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=20160404033845.GE17997@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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