From: Mike Gelfand <1893003@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1893003] Re: qemu linux-user doesn't translate host/target data for iovec I/O
Date: Thu, 27 Aug 2020 08:40:59 -0000 [thread overview]
Message-ID: <159851765924.5796.7987398138944264389.malone@gac.canonical.com> (raw)
In-Reply-To: 159842808665.2865.2216413646645324343.malonedeb@chaenomeles.canonical.com
The attached patch fixes the issue for me, but is incomplete (and not
thoroughly tested) as I've only implemented inotify data translation for
readv syscall.
** Patch added: "qemu-5.0.0-inotify-readv.patch"
https://bugs.launchpad.net/qemu/+bug/1893003/+attachment/5405134/+files/qemu-5.0.0-inotify-readv.patch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1893003
Title:
qemu linux-user doesn't translate host/target data for iovec I/O
Status in QEMU:
New
Bug description:
When using iovec I/O functions (like `readv`), no data translation
happens. I'm hitting this issue with libevent upon constructing a
bufferevent over an inotify descriptor, and then building for either
ppc64 or s390x (both big-endian) on x86_64 (little-endian) and running
resulting code with qemu-ppc64 or qemu-s390x on Gentoo using latest
QEMU version available (5.0.0-r2).
The code in question is in
https://github.com/transmission/transmission/blob/master/libtransmission
/watchdir-inotify.c (`tr_watchdir_inotify_new`,
`tr_watchdir_inotify_on_event`).
While `read` syscall is handled properly, `readv` (which libevent is
using in my case) doesn't have any logic to call
`host_to_target_data_inotify` or any other translation function,
leaving inotify data unchanged (with values in little-endian), which
then leads to unit test failures. Quoting `do_syscall1` implementation
bits for the reference:
---8<---begin---
case TARGET_NR_read:
if (arg2 == 0 && arg3 == 0) {
return get_errno(safe_read(arg1, 0, 0));
} else {
if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
return -TARGET_EFAULT;
ret = get_errno(safe_read(arg1, p, arg3));
if (ret >= 0 &&
fd_trans_host_to_target_data(arg1)) {
ret = fd_trans_host_to_target_data(arg1)(p, ret);
}
unlock_user(p, arg2, ret);
}
return ret;
...
case TARGET_NR_readv:
{
struct iovec *vec = lock_iovec(VERIFY_WRITE, arg2, arg3, 0);
if (vec != NULL) {
ret = get_errno(safe_readv(arg1, vec, arg3));
unlock_iovec(vec, arg2, arg3, 1);
} else {
ret = -host_to_target_errno(errno);
}
}
return ret;
---8<---end---
To reiterate, the issue is not only with `readv` but with other iovec
functions as well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1893003/+subscriptions
next prev parent reply other threads:[~2020-08-27 8:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-26 7:48 [Bug 1893003] [NEW] qemu-user doesn't translate host/target data for iovec I/O Mike Gelfand
2020-08-26 8:43 ` [Bug 1893003] Re: qemu linux-user " Mike Gelfand
2020-08-27 8:40 ` Mike Gelfand [this message]
2021-05-11 7:59 ` Thomas Huth
2021-06-17 7:12 ` Thomas Huth
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=159851765924.5796.7987398138944264389.malone@gac.canonical.com \
--to=1893003@bugs.launchpad.net \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).