On 02/20/2018 09:28 AM, Gerd Hoffmann wrote:
From: Bandan Das <b...@redhat.com>
Allow write operations on behalf of the initiator. The
precursor to write is the sending of the write metadata
that consists of the ObjectInfo dataset. This patch introduces
a flag that is set when the responder is ready to receive
write data based on a previous SendObjectInfo operation by
the initiator (The SendObjectInfo implementation is in a
later patch)
Signed-off-by: Bandan Das <b...@redhat.com>
Message-id: 20180215231129.14710-5-...@redhat.com
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
hw/usb/dev-mtp.c | 159 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 157 insertions(+), 2 deletions(-)
@@ -1472,12 +1492,133 @@ static void usb_mtp_cancel_packet(USBDevice *dev,
USBPacket *p)
fprintf(stderr, "%s\n", __func__);
}
+mode_t getumask(void)
+{
+ mode_t mask = umask(0);
+ umask(mask);
+ return mask;
+}
This is dangerous. 'man getumask' on my Fedora machine states:
CONFORMING TO
This is a vaporware GNU extension.
NOTES
This function is documented in the glibc manual, but, as at
glibc ver‐
sion 2.24, it is not implemented on Linux. (See umask(2) for a
thread-
safe method of discovering a process's umask.)
and 'man 2 umask' concurs:
It is impossible to use umask() to fetch a process's umask
without at
the same time changing it. A second call to umask() would
then be
needed to restore the umask. The nonatomicity of these two
steps pro‐
vides the potential for races in multithreaded programs.
It is ONLY safe to grab umask() prior to spawning threads, cache that
value, and refer to the cache at all later points.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
