qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] d0a961: block/file-posix: Pass FD to locking


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] d0a961: block/file-posix: Pass FD to locking helpers
Date: Mon, 11 Jun 2018 08:20:35 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: d0a96155de099d388f5e1f46277a54bdcfbb0bb2
      
https://github.com/qemu/qemu/commit/d0a96155de099d388f5e1f46277a54bdcfbb0bb2
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block/file-posix.c

  Log Message:
  -----------
  block/file-posix: Pass FD to locking helpers

raw_apply_lock_bytes() and raw_check_lock_bytes() currently take a
BDRVRawState *, but they only use the lock_fd field.  During image
creation, we do not have a BDRVRawState, but we do have an FD; so if we
want to reuse the functions there, we should modify them to receive only
the FD.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: b8cf1913a989b9ea6f248aaa233330047a62962e
      
https://github.com/qemu/qemu/commit/b8cf1913a989b9ea6f248aaa233330047a62962e
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block/file-posix.c

  Log Message:
  -----------
  block/file-posix: File locking during creation

When creating a file, we should take the WRITE and RESIZE permissions.
We do not need either for the creation itself, but we do need them for
clearing and resizing it.  So we can take the proper permissions by
replacing O_TRUNC with an explicit truncation to 0, and by taking the
appropriate file locks between those two steps.

Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Fam Zheng <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: f45b638f9f967cdbea4e24704bd16a858ddcde03
      
https://github.com/qemu/qemu/commit/f45b638f9f967cdbea4e24704bd16a858ddcde03
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/153
    M tests/qemu-iotests/153.out

  Log Message:
  -----------
  iotests: Add creation test to 153

This patch adds a test case to 153 which tries to overwrite an image
(using qemu-img create) while it is in use.  Without the original user
explicitly sharing the necessary permissions (writing and truncation),
this should not be allowed.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 1f996683ad908fd41c572221a63d9fc31ce04d07
      
https://github.com/qemu/qemu/commit/1f996683ad908fd41c572221a63d9fc31ce04d07
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-img.c

  Log Message:
  -----------
  qemu-img: Amendment support implies create_opts

Instead of checking whether a driver has a non-NULL create_opts we
should check whether it supports image amendment in the first place.  If
it does, it must have create_opts.

On the other hand, if it does not have create_opts (so it does not
support amendment either), the error message "does not support any
options" is a bit useless.  Stating clearly that the driver has no
amendment support whatsoever is probably better.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: d1402b502691142b9cebadd5cb993dc8858e9071
      
https://github.com/qemu/qemu/commit/d1402b502691142b9cebadd5cb993dc8858e9071
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block.c
    M block/qcow2.c
    M include/block/block.h
    M include/block/block_int.h
    M qemu-img.c
    M tests/qemu-iotests/060.out
    M tests/qemu-iotests/061.out
    M tests/qemu-iotests/080.out
    M tests/qemu-iotests/112.out

  Log Message:
  -----------
  block: Add Error parameter to bdrv_amend_options

Looking at the qcow2 code that is riddled with error_report() calls,
this is really how it should have been from the start.

Along the way, turn the target_version/current_version comparisons at
the beginning of qcow2_downgrade() into assertions (the caller has to
make sure these conditions are met), and rephrase the error message on
using compat=1.1 to get refcount widths other than 16 bits.

Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: 7f3fb00136aaec74df8132492d1f48b8e9840258
      
https://github.com/qemu/qemu/commit/7f3fb00136aaec74df8132492d1f48b8e9840258
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-img.c
    M util/qemu-option.c

  Log Message:
  -----------
  qemu-option: Pull out "Supported options" print

It really is up to the caller to decide what this list of options means.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 51641351420e4f9dc6613d0dd03a5f0f214ed5b6
      
https://github.com/qemu/qemu/commit/51641351420e4f9dc6613d0dd03a5f0f214ed5b6
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-img.c
    M tests/qemu-iotests/082.out

  Log Message:
  -----------
  qemu-img: Add print_amend_option_help()

The more generic print_block_option_help() function is not really
suitable for qemu-img amend, for a couple of reasons:
(1) We do not need to append the protocol-level options, as amendment
    happens only on one node and does not descend downwards to its
    children.
(2) print_block_option_help() says those options are "supported".  For
    option amendment, we do not really know that.  So this new function
    explicitly says that those options are the creation options, and not
    all of them may be supported.
(3) If the driver does not support option amendment, we should not print
    anything (except for an error message that amendment is not
    supported).

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: d402b6a21a825a5c07aac9251990860723d49f5d
      
https://github.com/qemu/qemu/commit/d402b6a21a825a5c07aac9251990860723d49f5d
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-img.c

  Log Message:
  -----------
  qemu-img: Recognize no creation support in -o help

The only users of print_block_option_help() are qemu-img create and
qemu-img convert for the output image, so this function is always used
for image creation (it used to be used for amendment also, but that is
no longer the case).

So if image creation is not supported by either the format or the
protocol, there is no need to print any option description, because the
user cannot create an image like this anyway.

This also fixes an assertion failure:

    $ qemu-img create -f bochs -o help
    Supported options:
    qemu-img: util/qemu-option.c:219:
    qemu_opts_print_help: Assertion `list' failed.
    [1]    24831 abort (core dumped)  qemu-img create -f bochs -o help

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: e53995eb19b546b18d1a34cd6eaa07faedbade79
      
https://github.com/qemu/qemu/commit/e53995eb19b546b18d1a34cd6eaa07faedbade79
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/082
    M tests/qemu-iotests/082.out

  Log Message:
  -----------
  iotests: Test help option for unsupporting formats

This adds test cases to 082 for qemu-img create/convert/amend "-o help"
on formats that do not support creation or amendment, respectively.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: dee6ddd8a6b7978d0bc8ef8e1f006282ce30e4fa
      
https://github.com/qemu/qemu/commit/dee6ddd8a6b7978d0bc8ef8e1f006282ce30e4fa
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/113
    M tests/qemu-iotests/113.out

  Log Message:
  -----------
  iotests: Rework 113

This test case has been broken since 398e6ad014df261d (roughly half a
year).  qemu-img amend requires its output image to be R/W, so it opens
it as such; the node is then turned into an read-only node automatically
which is now accompanied by a warning, however.  This warning has not
been part of the reference output.

For one thing, this warning shows that we cannot keep the test case as
it is.  We would need a format that has no create_opts but that does
have write support -- we do not have such a format, though.

Another thing is that qemu now actually checks whether an image format
supports amendment instead of whether it has create_opts (since the
former always implies the latter).  So we can now use any format that
does not support amendment (even if it supports creation) and thus test
the same code path.

The reason nobody has noticed the breakage until now of course is the
fact that nobody runs the iotests for nbd+bochs.  There actually was
never any reason to set the protocol to "nbd" but because that was
technically correct; functionally it made no difference.  So that is the
first thing we are going to change: Make the protocol "file" instead so
that people might actually notice breakage here.

Secondly, now that bochs no longer works for the amend test case, we
have to change the format there anyway.  Set let us just bend the truth
a bit, declare this test a raw test.  In fact, that does not even
concern the bochs test cases, other than the output now reading 'bochs'
instead of 'IMGFMT'.

So with this test now being a raw test, we can rework the amend test
case to use raw instead.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 3cce51c919c7b4028cf6676dfcb80a45741b5117
      
https://github.com/qemu/qemu/commit/3cce51c919c7b4028cf6676dfcb80a45741b5117
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block/qcow2-refcount.c

  Log Message:
  -----------
  qcow2: Repair OFLAG_COPIED when fixing leaks

Repairing OFLAG_COPIED is usually safe because it is done after the
refcounts have been repaired.  Therefore, it we did not find anyone else
referencing a data or L2 cluster, it makes no sense to not set
OFLAG_COPIED -- and the other direction (clearing OFLAG_COPIED) is
always safe, anyway, it may just induce leaks.

Furthermore, if OFLAG_COPIED is actually consistent with a wrong (leaky)
refcount, we will decrement the refcount with -r leaks, but OFLAG_COPIED
will then be wrong.  qemu-img check should not produce images that are
more corrupted afterwards then they were before.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1527085
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: b41ad73a3bb972eb43cf52d28669f67ea3fe1762
      
https://github.com/qemu/qemu/commit/b41ad73a3bb972eb43cf52d28669f67ea3fe1762
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    A tests/qemu-iotests/217
    A tests/qemu-iotests/217.out
    M tests/qemu-iotests/group

  Log Message:
  -----------
  iotests: Repairing error during snapshot deletion

This adds a test for an I/O error during snapshot deletion, and maybe
more importantly, for how to repair the resulting image.  If the
snapshot has been deleted before the error occurs, the only negative
result will be leaked clusters -- and those should be repairable with
qemu-img check -r leaks.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: b444d0e9d1ae323fed1ef7c35a359ce064f36b32
      
https://github.com/qemu/qemu/commit/b444d0e9d1ae323fed1ef7c35a359ce064f36b32
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M include/qemu-io.h
    M qemu-io-cmds.c
    M qemu-io.c

  Log Message:
  -----------
  qemu-io: Drop command functions' return values

For qemu-io, a function returns an integer with two possible values: 0
for "qemu-io may continue execution", or 1 for "qemu-io should exit".
However, there is only a single command that returns 1, and that is
"quit".

So let's turn this case into a global variable instead so we can make
better use of the return value in a later patch.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: b32d7a39af488d280ce5f02a2ed94871d696f87a
      
https://github.com/qemu/qemu/commit/b32d7a39af488d280ce5f02a2ed94871d696f87a
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M include/qemu-io.h
    M qemu-io-cmds.c
    M qemu-io.c

  Log Message:
  -----------
  qemu-io: Let command functions return error code

This is basically what everything else in the qemu code base does, so we
can do it here, too.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 6b3aa8485ca8e61b168f51d465188855cf549bd2
      
https://github.com/qemu/qemu/commit/6b3aa8485ca8e61b168f51d465188855cf549bd2
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-io.c

  Log Message:
  -----------
  qemu-io: Exit with error when a command failed

Currently, qemu-io basically always returns success when it gets to
interactive mode (so once the whole command line has been parsed; even
before the commands on the command line are interpreted).  That is not
very useful.

This patch makes qemu-io return failure when any of the executed
commands failed.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1519617
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 745f2bf4a5b973d1a69b21db97f9e4219da60624
      
https://github.com/qemu/qemu/commit/745f2bf4a5b973d1a69b21db97f9e4219da60624
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/iotests.py

  Log Message:
  -----------
  iotests.py: Add qemu_io_silent

With qemu-io now returning a useful exit code, some tests may find it
sufficient to just query that instead of logging (and filtering) the
whole output.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: e4ca4e981a0a389d6af5dc5d8b5fbdd1a05276a0
      
https://github.com/qemu/qemu/commit/e4ca4e981a0a389d6af5dc5d8b5fbdd1a05276a0
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/216
    M tests/qemu-iotests/216.out

  Log Message:
  -----------
  iotests: Let 216 make use of qemu-io's exit code

As a showcase of how you can use qemu-io's exit code to determine
success or failure (same for qemu-img), this test is changed to use
qemu_io_silent() instead of qemu_io(), and to assert the exit code
instead of logging the filtered result.

One real advantage of this is that in case of an error, you get a
backtrace that helps you locate the issue in the test file quickly.

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: d16699b64671466b42079c45b89127aeea1ca565
      
https://github.com/qemu/qemu/commit/d16699b64671466b42079c45b89127aeea1ca565
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-img.c

  Log Message:
  -----------
  qemu-img: Resolve relative backing paths in rebase

Currently, rebase interprets a relative path for the new backing image
as follows:
(1) Open the new backing image with the given relative path (thus relative to
    qemu-img's working directory).
(2) Write it directly into the overlay's backing path field (thus
    relative to the overlay).

If the overlay is not in qemu-img's working directory, both will be
different interpretations, which may either lead to an error somewhere
(either rebase fails because it cannot open the new backing image, or
your overlay becomes unusable because its backing path does not point to
a file), or, even worse, it may result in your rebase being performed
for a different backing file than what your overlay will point to after
the rebase.

Fix this by interpreting the target backing path as relative to the
overlay, like qemu-img does everywhere else.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1569835
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: 28036a7f7044fddb79819e3c8fcb4ae5605c60e0
      
https://github.com/qemu/qemu/commit/28036a7f7044fddb79819e3c8fcb4ae5605c60e0
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/024
    M tests/qemu-iotests/024.out

  Log Message:
  -----------
  iotests: Add test for rebasing with relative paths

Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 351c8efff9ad809c822d55620df54d575d536f68
      
https://github.com/qemu/qemu/commit/351c8efff9ad809c822d55620df54d575d536f68
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-img.c

  Log Message:
  -----------
  qemu-img: Special post-backing convert handling

Currently, qemu-img convert writes zeroes when it reads zeroes.
Sometimes it does not because the target is initialized to zeroes
anyway, so we do not need to overwrite (and thus potentially allocate)
it.  This is never the case for targets with backing files, though.  But
even they may have an area that is initialized to zeroes, and that is
the area past the end of the backing file (if that is shorter than the
overlay).

So if the target format's unallocated blocks are zero and there is a gap
between the target's backing file's end and the target's end, we do not
have to explicitly write zeroes there.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1527898
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: 0682854f899d03c78befce9f5aae4a7e37655d25
      
https://github.com/qemu/qemu/commit/0682854f899d03c78befce9f5aae4a7e37655d25
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/122
    M tests/qemu-iotests/122.out

  Log Message:
  -----------
  iotests: Test post-backing convert target behavior

This adds a test case to 122 for what happens when you convert to a
target with a backing file that is shorter than the target, and the
image format does not support efficient zero writes (as is the case with
qcow2 v2).

Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: c1bac161bb7ad27243776e90971c51cc38c2e1b6
      
https://github.com/qemu/qemu/commit/c1bac161bb7ad27243776e90971c51cc38c2e1b6
  Author: Vladimir Sementsov-Ogievskiy <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/iotests.py

  Log Message:
  -----------
  iotests: improve pause_job

It's possible, that job was finished during waiting. In this case we
will see error message "Timeout waiting for job to pause" which is not
very informative. So, let's check during waiting iteration that the job
exists.

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 83f90b535a0d5e64056c087aa4022ea35c59bcd0
      
https://github.com/qemu/qemu/commit/83f90b535a0d5e64056c087aa4022ea35c59bcd0
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/219
    M tests/qemu-iotests/219.out

  Log Message:
  -----------
  iotests: Fix 219's timing

219 has two issues that may lead to sporadic failure, both of which are
the result of issuing query-jobs too early after a job has been
modified.  This can then lead to different results based on whether the
modification has taken effect already or not.

First, query-jobs is issued right after the job has been created.
Besides its current progress possibly being in any random state (which
has already been taken care of), its total progress too is basically
arbitrary, because the job may not yet have been able to determine it.
This patch addresses this by just filtering the total progress, like
what has been done for the current progress already.  However, for more
clarity, the filtering is changed to replace the values by a string
'FILTERED' instead of deleting them.

Secondly, query-jobs is issued right after a job has been resumed.  The
job may or may not yet have had the time to actually perform any I/O,
and thus its current progress may or may not have advanced.  To make
sure it has indeed advanced (which is what the reference output already
assumes), keep querying it until it has.

Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: 46e8d272baa0608adcfdbd8bc1d2312bea06da40
      
https://github.com/qemu/qemu/commit/46e8d272baa0608adcfdbd8bc1d2312bea06da40
  Author: Thomas Huth <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M qemu-doc.texi
    M qemu-img-cmds.hx
    M qemu-img.c
    M qemu-img.texi
    M tests/qemu-iotests/029
    M tests/qemu-iotests/080

  Log Message:
  -----------
  qemu-img: Remove deprecated -s snapshot_id_or_name option

It has been marked as deprecated since QEMU v2.0 already, so it
is time now to finally remove it.

Signed-off-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: 7eb24009dbf8102fc27d5459bec1cb8a932540c4
      
https://github.com/qemu/qemu/commit/7eb24009dbf8102fc27d5459bec1cb8a932540c4
  Author: Vladimir Sementsov-Ogievskiy <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block/qcow2-bitmap.c

  Log Message:
  -----------
  block/qcow2-bitmap: fix free_bitmap_clusters

This assert may fail, because bitmap_table is not initialized. Just
drop it, as it's obvious, that bitmap_table_load sets bitmap_table
parameter only when returning zero.

Reported-by: Pavel Butsykin <address@hidden>
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: bc33c047d1ec0b35c9cd8be62bcefae2da28654f
      
https://github.com/qemu/qemu/commit/bc33c047d1ec0b35c9cd8be62bcefae2da28654f
  Author: Alberto Garcia <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block/throttle.c

  Log Message:
  -----------
  throttle: Fix crash on reopen

The throttle block filter can be reopened, and with this it is
possible to change the throttle group that the filter belongs to.

The way the code does that is the following:

  - On throttle_reopen_prepare(): create a new ThrottleGroupMember
    and attach it to the new throttle group.

  - On throttle_reopen_commit(): detach the old ThrottleGroupMember,
    delete it and replace it with the new one.

The problem with this is that by replacing the ThrottleGroupMember the
previous value of io_limits_disabled is lost, causing an assertion
failure in throttle_co_drain_end().

This problem can be reproduced by reopening a throttle node:

   $QEMU -monitor stdio
   -object throttle-group,id=tg0,x-iops-total=1000 \
   -blockdev node-name=hd0,driver=qcow2,file.driver=file,file.filename=hd.qcow2 
\
   -blockdev 
node-name=root,driver=throttle,throttle-group=tg0,file=hd0,read-only=on

   (qemu) block_stream root
   block/throttle.c:214: throttle_co_drain_end: Assertion 
`tgm->io_limits_disabled' failed.

Since we only want to change the throttle group on reopen there's no
need to create a ThrottleGroupMember and discard the old one. It's
easier if we simply detach it from its current group and attach it to
the new one.

Signed-off-by: Alberto Garcia <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: cc022140972f8b6ac3973c12ccf9dd6b1d2fd200
      
https://github.com/qemu/qemu/commit/cc022140972f8b6ac3973c12ccf9dd6b1d2fd200
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block.c
    M include/block/block.h

  Log Message:
  -----------
  block: Make bdrv_is_writable() public

This is a useful function for the whole block layer, so make it public.
At the same time, users outside of block.c probably do not need to make
use of the reopen functionality, so rename the current function to
bdrv_is_writable_after_reopen() create a new bdrv_is_writable() function
that just passes NULL to it for the reopen queue.

Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: ddf3b47ef4b5ed0bf6558d4c2c8ae130b8d8a580
      
https://github.com/qemu/qemu/commit/ddf3b47ef4b5ed0bf6558d4c2c8ae130b8d8a580
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block/qcow2.c

  Log Message:
  -----------
  qcow2: Do not mark inactive images corrupt

When signaling a corruption on a read-only image, qcow2 already makes
fatal events non-fatal (i.e., they will not result in the image being
closed, and the image header's corrupt flag will not be set).  This is
necessary because we cannot set the corrupt flag on read-only images,
and it is possible because further corruption of read-only images is
impossible.

Inactive images are effectively read-only, too, so we should do the same
for them.  bdrv_is_writable() can tell us whether an image can actually
be written to, so use its result instead of !bs->read_only.

(Otherwise, the assert(!(bs->open_flags & BDRV_O_INACTIVE)) in
bdrv_co_pwritev() will fail, crashing qemu.)

Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Max Reitz <address@hidden>


  Commit: c50abd175a88cd41c2c08339de91f6f6e4a7b162
      
https://github.com/qemu/qemu/commit/c50abd175a88cd41c2c08339de91f6f6e4a7b162
  Author: Max Reitz <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M tests/qemu-iotests/060
    M tests/qemu-iotests/060.out

  Log Message:
  -----------
  iotests: Add case for a corrupted inactive image

Reviewed-by: John Snow <address@hidden>
Tested-by: Jeff Cody <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>


  Commit: 2afc4e3df80d947dd1bd42ce80278f591b35c74a
      
https://github.com/qemu/qemu/commit/2afc4e3df80d947dd1bd42ce80278f591b35c74a
  Author: Peter Maydell <address@hidden>
  Date:   2018-06-11 (Mon, 11 Jun 2018)

  Changed paths:
    M block.c
    M block/file-posix.c
    M block/qcow2-bitmap.c
    M block/qcow2-refcount.c
    M block/qcow2.c
    M block/throttle.c
    M include/block/block.h
    M include/block/block_int.h
    M include/qemu-io.h
    M qemu-doc.texi
    M qemu-img-cmds.hx
    M qemu-img.c
    M qemu-img.texi
    M qemu-io-cmds.c
    M qemu-io.c
    M tests/qemu-iotests/024
    M tests/qemu-iotests/024.out
    M tests/qemu-iotests/029
    M tests/qemu-iotests/060
    M tests/qemu-iotests/060.out
    M tests/qemu-iotests/061.out
    M tests/qemu-iotests/080
    M tests/qemu-iotests/080.out
    M tests/qemu-iotests/082
    M tests/qemu-iotests/082.out
    M tests/qemu-iotests/112.out
    M tests/qemu-iotests/113
    M tests/qemu-iotests/113.out
    M tests/qemu-iotests/122
    M tests/qemu-iotests/122.out
    M tests/qemu-iotests/153
    M tests/qemu-iotests/153.out
    M tests/qemu-iotests/216
    M tests/qemu-iotests/216.out
    A tests/qemu-iotests/217
    A tests/qemu-iotests/217.out
    M tests/qemu-iotests/219
    M tests/qemu-iotests/219.out
    M tests/qemu-iotests/group
    M tests/qemu-iotests/iotests.py
    M util/qemu-option.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2018-06-11' 
into staging

Block patches:
- Various bug fixes
- Removal of qemu-img convert's deprecated -s option
- qemu-io now exits with an error when a command failed

# gpg: Signature made Mon 11 Jun 2018 15:23:42 BST
# gpg:                using RSA key F407DB0061D5CF40
# gpg: Good signature from "Max Reitz <address@hidden>"
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1  1829 F407 DB00 61D5 CF40

* remotes/maxreitz/tags/pull-block-2018-06-11: (29 commits)
  iotests: Add case for a corrupted inactive image
  qcow2: Do not mark inactive images corrupt
  block: Make bdrv_is_writable() public
  throttle: Fix crash on reopen
  block/qcow2-bitmap: fix free_bitmap_clusters
  qemu-img: Remove deprecated -s snapshot_id_or_name option
  iotests: Fix 219's timing
  iotests: improve pause_job
  iotests: Test post-backing convert target behavior
  qemu-img: Special post-backing convert handling
  iotests: Add test for rebasing with relative paths
  qemu-img: Resolve relative backing paths in rebase
  iotests: Let 216 make use of qemu-io's exit code
  iotests.py: Add qemu_io_silent
  qemu-io: Exit with error when a command failed
  qemu-io: Let command functions return error code
  qemu-io: Drop command functions' return values
  iotests: Repairing error during snapshot deletion
  qcow2: Repair OFLAG_COPIED when fixing leaks
  iotests: Rework 113
  ...

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/9f55925b8f50...2afc4e3df80d
      **NOTE:** This service been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]