On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
>> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
>>> QEMU coding style at the moment asks for all non-system
>>> include files to be used with #include "foo.h".
>>> However this ru
On Tue 20 Mar 2018 06:54:15 PM CET, Eric Blake wrote:
>> When we try to allocate new clusters we first look for available ones
>> starting from s->free_cluster_index and once we find them we increase
>> their reference counts. Before we get to call update_refcount() to do
>> this last step s->free
On Tue, Mar 20, 2018 at 06:36:25PM +0100, Kevin Wolf wrote:
> Commit e39e959e fixed an invalid assertion in the .bdrv_length
> implementation, but left a similar assertion in place for
> .bdrv_truncate. Instead of crashing when the user requests a too large
> image size, fail gracefully.
>
> A fil
On Tue, Mar 20, 2018 at 06:36:24PM +0100, Kevin Wolf wrote:
> We want to test resizing even for luks. The only change that is needed
> is to explicitly zero out new space for luks because it's undefined.
>
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/025 | 9 -
> 1 file changed
On Tue, Mar 20, 2018 at 06:36:26PM +0100, Kevin Wolf wrote:
> This tests that the .bdrv_truncate implementation for luks doesn't crash
> for invalid image sizes.
>
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/210 | 37 +
> 1 file changed, 37 insertio
If the user does not have permissions to send ioctls to the device (due to
SELinux or cgroups, for example), the output can look like
qemu-kvm: -device scsi-block,drive=disk: cannot get SG_IO version number:
Operation not permitted. Is this a SCSI device?
but this is confusing because the ioct
On 2018-03-20 18:35, Eric Blake wrote:
> On 02/28/2018 12:05 PM, Max Reitz wrote:
>> This patch allows the user to specify whether to use active or only
>> background mode for mirror block jobs. Currently, this setting will
>> remain constant for the duration of the entire block job.
>>
>> Signed-
On 21/03/2018 11:58, Paolo Bonzini wrote:
> If the user does not have permissions to send ioctls to the device (due to
> SELinux or cgroups, for example), the output can look like
>
> qemu-kvm: -device scsi-block,drive=disk: cannot get SG_IO version number:
> Operation not permitted. Is this a
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 60 +++-
1 file changed, 43 insertions(+), 17 deletions(-)
diff --git a/nbd/server.c b/nbd/server.c
index cea158913b..b830997114 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@
The helper will be reused for bitmaps namespace.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/nbd/server.c b/nbd/server.c
index b830997114..8fe53ffd4b 100644
--- a/nbd/
On 21/03/2018 13:17, Laurent Vivier wrote:
> On 21/03/2018 11:58, Paolo Bonzini wrote:
>> If the user does not have permissions to send ioctls to the device (due to
>> SELinux or cgroups, for example), the output can look like
>>
>> qemu-kvm: -device scsi-block,drive=disk: cannot get SG_IO version
Hi all.
This is a proposal and realization of new NBD meta context:
qemu-dirty-bitmap. (I'll send corresponding proposal to NBD protocol
after some negotiation here)
Corresponding queries will look like:
qemu-dirty-bitmap:
Mapping from export-bitmap-name to BdrvDirtyBitmap is done through qmp
co
On 03/21/2018 05:58 AM, Paolo Bonzini wrote:
If the user does not have permissions to send ioctls to the device (due to
SELinux or cgroups, for example), the output can look like
qemu-kvm: -device scsi-block,drive=disk: cannot get SG_IO version number:
Operation not permitted. Is this a SCSI
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
qapi/block.json | 27 +++
blockdev-nbd.c | 23 +++
2 files changed, 50 insertions(+)
diff --git a/qapi/block.json b/qapi/block.json
index c694524002..4afbbcd7b7 100644
--- a/qapi/block.json
+++ b/qapi/bl
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/nbd.h | 2 +
nbd/server.c| 207 ++--
2 files changed, 203 insertions(+), 6 deletions(-)
diff --git a/include/block/nbd.h b/include/block/nbd.h
index fcdcd54502..f0b459283f 1006
If the user does not have permissions to send ioctls to the device (due to
SELinux or cgroups, for example), the output can look like
qemu-kvm: -device scsi-block,drive=disk: cannot get SG_IO version number:
Operation not permitted. Is this a SCSI device?
but this is confusing because the ioct
On 21/03/2018 13:54, Paolo Bonzini wrote:
> If the user does not have permissions to send ioctls to the device (due to
> SELinux or cgroups, for example), the output can look like
>
> qemu-kvm: -device scsi-block,drive=disk: cannot get SG_IO version number:
> Operation not permitted. Is this a
On Tue, Mar 20, 2018 at 06:36:29PM +0100, Kevin Wolf wrote:
> Images with a non-power-of-two block size are invalid and cannot be
> opened. Reject such block sizes when creating an image.
>
Good catch.
Reviewed-by: Jeff Cody
> Signed-off-by: Kevin Wolf
> ---
> block/vhdx.c | 4
> 1 fil
On Tue, Mar 20, 2018 at 06:36:30PM +0100, Kevin Wolf wrote:
> error_setg_errno() is meant for cases where we got an errno from the OS
> that can add useful extra information to an error message. It's
> pointless if we pass a constant errno, these cases should use plain
> error_setg().
>
> Signed-o
On 03/21/2018 04:28 AM, Alberto Garcia wrote:
On Tue 20 Mar 2018 06:54:15 PM CET, Eric Blake wrote:
When we try to allocate new clusters we first look for available ones
starting from s->free_cluster_index and once we find them we increase
their reference counts. Before we get to call update_re
On Wed, Mar 21, 2018 at 08:16:00AM +0100, Thomas Huth wrote:
> On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> >> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> >>> QEMU coding style at the moment asks for all non-system
>
On Tue, Mar 20, 2018 at 06:36:31PM +0100, Kevin Wolf wrote:
> It's unclear what the real maximum is, but we use an uint32_t to store
> the log size in vhdx_co_create(), so we should check that the given
> value fits in 32 bits.
>
It's a uint32 in the on-disk header per spec, so I agree the implie
Am 21.03.2018 um 14:08 schrieb Michael S. Tsirkin:
> It still leaves us with a host of problems e.g. the problem of stale
> headers in the source directory.
There have already been suggestions in the past to forbid in-tree
builds. Would it help if configure would refuse to run from the root
source
On Wed 21 Mar 2018 02:08:23 PM CET, Eric Blake wrote:
>> - This scenario is harder to reach: in order to fill a 1-cluster
>> refcount table the size of the image needs to be larger than
>> (cluster_size³ / refcount_bits) bytes, that's 16TB with the default
>> parameters. So although it can
On 2018-03-20 18:05, Vladimir Sementsov-Ogievskiy wrote:
> Hi all.
>
> This fixes bitmaps migration through shared storage. Look at 02 for
> details.
>
> The bug introduced in 2.10 with the whole qcow2 bitmaps feature, so
> qemu-stable in CC. However I doubt that someone really suffered from this
On Wed, Mar 21, 2018 at 02:15:20PM +0100, Stefan Weil wrote:
> Am 21.03.2018 um 14:08 schrieb Michael S. Tsirkin:
> > It still leaves us with a host of problems e.g. the problem of stale
> > headers in the source directory.
>
> There have already been suggestions in the past to forbid in-tree
> bu
On 03/20/2018 08:55 AM, Alberto Garcia wrote:
When we try to allocate new clusters we first look for available ones
starting from s->free_cluster_index and once we find them we increase
their reference counts. Before we get to call update_refcount() to do
this last step s->free_cluster_index is a
On 03/21/2018 08:30 AM, Eric Blake wrote:
On 03/20/2018 08:55 AM, Alberto Garcia wrote:
This can be reproduced easily:
qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M
qemu-io -c 'write 0 124k' hd.qcow2
This reproduction fails if you use non-default refcount_order...
+
On Wed, Mar 21, 2018 at 03:08:36PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 08:16:00AM +0100, Thomas Huth wrote:
> > On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> > > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > >> Le 20/03/2018 à 02:54, Michael S. Tsirki
When we try to allocate new clusters we first look for available ones
starting from s->free_cluster_index and once we find them we increase
their reference counts. Before we get to call update_refcount() to do
this last step s->free_cluster_index is already pointing to the next
cluster after the on
[adding qemu lists]
On 03/21/2018 07:51 AM, Richard W.M. Jones wrote:
On Wed, Mar 21, 2018 at 01:44:17PM +0100, Pino Toscano wrote:
Newer versions of qemu use file locking for the images by default, and
apparently that does not work with /dev/null. Since this test just
calls qemu-img to get th
On Wed, Mar 21, 2018 at 01:29:53PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 21, 2018 at 03:08:36PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Mar 21, 2018 at 08:16:00AM +0100, Thomas Huth wrote:
> > > On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 20, 2018 at 09:58:23AM
On Wednesday, 21 March 2018 14:45:38 CET Eric Blake wrote:
> [adding qemu lists]
>
> On 03/21/2018 07:51 AM, Richard W.M. Jones wrote:
> > On Wed, Mar 21, 2018 at 01:44:17PM +0100, Pino Toscano wrote:
> >> Newer versions of qemu use file locking for the images by default, and
> >> apparently that
Am 21.03.2018 um 14:38 hat Alberto Garcia geschrieben:
> This can be reproduced easily:
>
> qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M
> qemu-io -c 'write 0 124k' hd.qcow2
>
> After this the image has 132608 bytes (256 clusters), and the refcount
> block is full. If we wri
On Wed 21 Mar 2018 02:52:38 PM CET, Kevin Wolf wrote:
>> qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M
>> qemu-io -c 'write 0 124k' hd.qcow2
>> qemu-io -c 'write 124k 512' hd.qcow2
>
> So if I understand correctly, this is what we get:
>
> 0x2: free
> 0x20200: refcoun
Our current scheme is to use
#include ""
for internal headers, and
#include <>
for external ones.
Unfortunately this is not based on compiler support: from C point of
view, the "" form merely looks up headers in the current directory
and then falls back on <> directories.
Thus, for example, a s
[adding NBD list]
On 03/21/2018 07:19 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 60 +++-
1 file changed, 43 insertions(+), 17 deletions(-)
+struct {
+const char *ns;
+
On 21/03/2018 15:46, Michael S. Tsirkin wrote:
> +if (m@^\s*#include\s+"qemu/@o) {
> +s@^(\s*#include\s+)"qemu/([^"]+)"(.*)$@$1$3@o) {
> +} else {
> +s@^(\s*#include\s+)"([^"]+)"(.*)$@$1$3@o) {
> +}
Can you explain the changes in the source tree layout?
Also, s{}{} and m{} are a bit more
On 03/21/2018 07:19 AM, Vladimir Sementsov-Ogievskiy wrote:
The helper will be reused for bitmaps namespace.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
+/* Read len bytes a
Am 21.03.2018 um 15:10 hat Alberto Garcia geschrieben:
> On Wed 21 Mar 2018 02:52:38 PM CET, Kevin Wolf wrote:
>
> >> qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M
> >> qemu-io -c 'write 0 124k' hd.qcow2
> >> qemu-io -c 'write 124k 512' hd.qcow2
> >
> > So if I understand
On Wed, Mar 21, 2018 at 04:04:29PM +0100, Paolo Bonzini wrote:
> On 21/03/2018 15:46, Michael S. Tsirkin wrote:
> > +if (m@^\s*#include\s+"qemu/@o) {
> > +s@^(\s*#include\s+)"qemu/([^"]+)"(.*)$@$1$3@o) {
> > +} else {
> > +s@^(\s*#include\s+)"([^"]+)"(.*)$@$1$3@o) {
> > +}
>
> Can you expl
On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in
On 21/03/2018 16:11, Michael S. Tsirkin wrote:
>> Can you explain the changes in the source tree layout?
> include/qemu -> include/qemu/common
> include/* -> include/qemu/*
Ok, then perhaps "util" instead of common would match the source layout
more.
Paolo
> Thus one uses any qemu headers with
>
The sheepdog mailing list is setup to stop and queue messages from
non-subscribers, pending moderator approval. Unfortunately it seems
that the moderation queue is not actively dealt with. Even when messages
are approved, the sender is never added to the whitelist, so every
future mail the same sen
On Wed 21 Mar 2018 04:07:28 PM CET, Kevin Wolf wrote:
> I just remembered that when I looked at an image recently, I noticed
> that the refcount block wasn't in the first cluster and I disliked it,
> though mostly because it felt untidy rather than being a problem.
I don't think you can fix that i
Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in the curre
On Wed, Mar 21, 2018 at 03:31:24PM +, Daniel P. Berrangé wrote:
> The sheepdog mailing list is setup to stop and queue messages from
> non-subscribers, pending moderator approval. Unfortunately it seems
> that the moderation queue is not actively dealt with. Even when messages
> are approved, t
Am 21.03.2018 um 16:32 hat Alberto Garcia geschrieben:
> On Wed 21 Mar 2018 04:07:28 PM CET, Kevin Wolf wrote:
> > I just remembered that when I looked at an image recently, I noticed
> > that the refcount block wasn't in the first cluster and I disliked it,
> > though mostly because it felt untidy
On 03/21/2018 10:31 AM, Daniel P. Berrangé wrote:
The sheepdog mailing list is setup to stop and queue messages from
non-subscribers, pending moderator approval. Unfortunately it seems
that the moderation queue is not actively dealt with. Even when messages
are approved, the sender is never added
On Wed, Mar 21, 2018 at 03:19:22PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> > Our current scheme is to use
> > #include ""
> > for internal headers, and
> > #include <>
> > for external ones.
> >
> > Unfortunately this is not based
On Wed, Mar 21, 2018 at 10:42:57AM -0500, Eric Blake wrote:
> On 03/21/2018 10:31 AM, Daniel P. Berrangé wrote:
> > The sheepdog mailing list is setup to stop and queue messages from
> > non-subscribers, pending moderator approval. Unfortunately it seems
> > that the moderation queue is not activel
On Wed, Mar 21, 2018 at 05:39:48PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 03:19:22PM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> > > Our current scheme is to use
> > > #include ""
> > > for internal headers, and
> >
On Wed, Mar 21, 2018 at 04:34:39PM +0100, Kevin Wolf wrote:
> Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> > Our current scheme is to use
> > #include ""
> > for internal headers, and
> > #include <>
> > for external ones.
> >
> > Unfortunately this is not based on compiler suppo
Am 21.03.2018 um 16:58 hat Michael S. Tsirkin geschrieben:
> On Wed, Mar 21, 2018 at 04:34:39PM +0100, Kevin Wolf wrote:
> > Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> > > Our current scheme is to use
> > > #include ""
> > > for internal headers, and
> > > #include <>
> > > for
On 03/21/2018 07:19 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
Rather sparse on the details in the commit message; I had to read the
patch to even learn what the new namespace is.
---
include/block/nbd.h | 2 +
nbd/server.c| 207 +++
Am 20.03.2018 um 19:42 hat Eric Blake geschrieben:
> On 03/20/2018 12:36 PM, Kevin Wolf wrote:
> > Signed-off-by: Kevin Wolf
> > ---
> > tests/qemu-iotests/212 | 326
> > +
> > tests/qemu-iotests/212.out | 111 +++
> > tests/qemu-iot
On Wed, Mar 21, 2018 at 09:56:36AM -0500, Eric Blake wrote:
> no further qemu patches are submitted. Is it worth me proposing a doc
> change to demonstrate what the difference would look like, along with
> corresponding qemu changes to match, to decide if including it in 2.12 is
> worth it?
If yo
Am 20.03.2018 um 19:33 hat Eric Blake geschrieben:
> On 03/20/2018 12:36 PM, Kevin Wolf wrote:
> > This tests that the .bdrv_truncate implementation for luks doesn't crash
> > for invalid image sizes.
> >
> > Signed-off-by: Kevin Wolf
> > ---
> > tests/qemu-iotests/210 | 37
Am 20.03.2018 um 19:53 hat Eric Blake geschrieben:
> On 03/20/2018 12:36 PM, Kevin Wolf wrote:
> > Signed-off-by: Kevin Wolf
> > ---
> > tests/qemu-iotests/213 | 349
> > +
> > tests/qemu-iotests/213.out | 121
> > tests/qemu-io
On 03/21/2018 07:19 AM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
qapi/block.json | 27 +++
blockdev-nbd.c | 23 +++
2 files changed, 50 insertions(+)
diff --git a/qapi/block.json b/qapi/block.json
index
This series adds qemu-iotests for a few more block drivers (yet more to
come in another series) and fixes a few things that previous review and
these tests brought up.
The only major design change is that I converted the vdi block driver
from a boolean 'static' create option to the standard 'preal
What static=on really does is what we call metadata preallocation for
other block drivers. While we can still change the QMP interface, make
it more consistent by using 'preallocation' for VDI, too.
This doesn't implement any new functionality, so the only supported
preallocation modes are 'off' a
Use qemu_uuid_unparse() instead of uuid_unparse() to make vdi.c compile
again when CONFIG_VDI_DEBUG is set. In order to prevent future bitrot,
replace '#ifdef CONFIG_VDI_DEBUG' by 'if (VDI_DEBUG)' so that the
compiler always sees the code.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
---
b
This tests that the .bdrv_truncate implementation for luks doesn't crash
for invalid image sizes.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/210 | 37 +
tests/qemu-iotests/210.out | 16
2 files changed, 53 insertions(+)
diff --git a
Images with a non-power-of-two block size are invalid and cannot be
opened. Reject such block sizes when creating an image.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Jeff Cody
---
block/vhdx.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/vhdx.c b/block/vhd
error_setg_errno() is meant for cases where we got an errno from the OS
that can add useful extra information to an error message. It's
pointless if we pass a constant errno, these cases should use plain
error_setg().
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Jeff Cody
---
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/212 | 326 +
tests/qemu-iotests/212.out | 111 +++
tests/qemu-iotests/group | 1 +
3 files changed, 438 insertions(+)
create mode 100755 tests/qemu-iotests/212
create mode 100644 tes
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/211 | 246 +
tests/qemu-iotests/211.out | 97 ++
tests/qemu-iotests/group | 1 +
3 files changed, 344 insertions(+)
create mode 100755 tests/qemu-iotests/211
create mode 100644
Commit e39e959e fixed an invalid assertion in the .bdrv_length
implementation, but left a similar assertion in place for
.bdrv_truncate. Instead of crashing when the user requests a too large
image size, fail gracefully.
A file size of exactly INT64_MAX caused failure before, but is actually
legal
We want to test resizing even for luks. The only change that is needed
is to explicitly zero out new space for luks because it's undefined.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Daniel P. Berrangé
---
tests/qemu-iotests/025 | 9 -
1 file changed, 8 insertions(+
On 03/21/2018 12:37 PM, Kevin Wolf wrote:
What static=on really does is what we call metadata preallocation for
other block drivers. While we can still change the QMP interface, make
it more consistent by using 'preallocation' for VDI, too.
This doesn't implement any new functionality, so the on
It's unclear what the real maximum cluster size is for the Parallels
format, but let's at least make sure that we don't get integer
overflows in our .bdrv_co_create implementation.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
---
block/parallels.c | 5 +
1 file changed, 5 insertions(+)
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/213 | 349 +
tests/qemu-iotests/213.out | 121
tests/qemu-iotests/group | 1 +
3 files changed, 471 insertions(+)
create mode 100755 tests/qemu-iotests/213
create mode 100644 te
It's unclear what the real maximum is, but we use an uint32_t to store
the log size in vhdx_co_create(), so we should check that the given
value fits in 32 bits.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
Reviewed-by: Jeff Cody
---
block/vhdx.c | 4
1 file changed, 4 insertions(+)
Am 21.03.2018 um 14:38 hat Alberto Garcia geschrieben:
> When we try to allocate new clusters we first look for available ones
> starting from s->free_cluster_index and once we find them we increase
> their reference counts. Before we get to call update_refcount() to do
> this last step s->free_clu
On 03/21/2018 01:39 AM, Paolo Bonzini wrote:
> On 20/03/2018 23:11, John Snow wrote:
>> Seems sane, with some lingering questions about what the PIO Setup FIS
>> is supposed to do to begin with still remaining.
>
> I agree here too. Smashing the ATA and controller in the same device
> makes thi
Adjust each caller of raw_open_common to specify if they are expecting
host and character devices or not. Tighten expectations of file types upon
open in the common code and refuse types that are not expected.
This has two effects:
(1) Character and block devices are now considered deprecated for
On 03/21/2018 04:25 PM, Kevin Wolf wrote:
> Am 21.03.2018 um 21:01 hat John Snow geschrieben:
>> Adjust each caller of raw_open_common to specify if they are expecting
>> host and character devices or not. Tighten expectations of file types upon
>> open in the common code and refuse types that ar
Am 21.03.2018 um 21:01 hat John Snow geschrieben:
> Adjust each caller of raw_open_common to specify if they are expecting
> host and character devices or not. Tighten expectations of file types upon
> open in the common code and refuse types that are not expected.
>
> This has two effects:
>
> (
On 03/21/2018 03:01 PM, John Snow wrote:
Adjust each caller of raw_open_common to specify if they are expecting
host and character devices or not. Tighten expectations of file types upon
open in the common code and refuse types that are not expected.
This has two effects:
(1) Character and bloc
Am 21.03.2018 um 21:26 hat Eric Blake geschrieben:
> On 03/21/2018 03:01 PM, John Snow wrote:
> > Adjust each caller of raw_open_common to specify if they are expecting
> > host and character devices or not. Tighten expectations of file types upon
> > open in the common code and refuse types that a
Am 21.03.2018 um 14:48 hat Pino Toscano geschrieben:
> On Wednesday, 21 March 2018 14:45:38 CET Eric Blake wrote:
> > [adding qemu lists]
> >
> > On 03/21/2018 07:51 AM, Richard W.M. Jones wrote:
> > > On Wed, Mar 21, 2018 at 01:44:17PM +0100, Pino Toscano wrote:
> > >> Newer versions of qemu use
On 03/21/2018 03:44 PM, Kevin Wolf wrote:
You're right that file locking on a character device like /dev/null is
not going to work as expected, but is it a case where fcntl() actually
fails, or is it worse where the fcntl() claiming the locks "succeeds"
but doesn't do what we want? That is, wha
./check -v -raw
Failures: 109 132 136 148 152 183
3fd2457d18edf5736f713dfe1ada9c87a9badab1 is the first bad commit
commit 3fd2457d18edf5736f713dfe1ada9c87a9badab1
Author: Peter Xu
Date: Fri Mar 9 17:00:03 2018 +0800
monitor: enable IO thread for (qmp & !mux) typed
Start to use dedicat
On Wed, Mar 21, 2018 at 03:58:05PM -0500, Eric Blake wrote:
> On 03/21/2018 03:44 PM, Kevin Wolf wrote:
> >>>
> >>>You're right that file locking on a character device like /dev/null is
> >>>not going to work as expected, but is it a case where fcntl() actually
> >>>fails, or is it worse where the
On Wed, 03/21 11:58, Paolo Bonzini wrote:
> diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
> index 7414fe2d67..b3de5df324 100644
> --- a/hw/scsi/scsi-generic.c
> +++ b/hw/scsi/scsi-generic.c
> @@ -500,9 +500,10 @@ static void scsi_generic_realize(SCSIDevice *s, Error
> **errp)
>
On Wed, Mar 21, 2018 at 05:58:48PM -0400, John Snow wrote:
> ./check -v -raw
> Failures: 109 132 136 148 152 183
>
> 3fd2457d18edf5736f713dfe1ada9c87a9badab1 is the first bad commit
> commit 3fd2457d18edf5736f713dfe1ada9c87a9badab1
> Author: Peter Xu
> Date: Fri Mar 9 17:00:03 2018 +0800
>
>
87 matches
Mail list logo
