qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 8fc898: block/backup: avoid integer overflow


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] 8fc898: block/backup: avoid integer overflow of `max-workers`
Date: Thu, 07 Oct 2021 12:05:16 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 8fc898ce0b3e7fea8c7c2a8d8977f2a9b77ecebf
      
https://github.com/qemu/qemu/commit/8fc898ce0b3e7fea8c7c2a8d8977f2a9b77ecebf
  Author: Stefano Garzarella <sgarzare@redhat.com>
  Date:   2021-10-05 (Tue, 05 Oct 2021)

  Changed paths:
    M block/backup.c

  Log Message:
  -----------
  block/backup: avoid integer overflow of `max-workers`

QAPI generates `struct BackupPerf` where `max-workers` value is stored
in an `int64_t` variable.
But block_copy_async(), and the underlying code, uses an `int` parameter.

At the end that variable is used to initialize `max_busy_tasks` in
block/aio_task.c causing the following assertion failure if a value
greater than INT_MAX(2147483647) is used:

  ../block/aio_task.c:63: aio_task_pool_wait_one: Assertion `pool->busy_tasks > 
0' failed.

Let's check that `max-workers` doesn't exceed INT_MAX and print an
error in that case.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2009310
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211005161157.282396-2-sgarzare@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: a9515df4d66da34cbc2938e4c1f46015fc74ff93
      
https://github.com/qemu/qemu/commit/a9515df4d66da34cbc2938e4c1f46015fc74ff93
  Author: Stefano Garzarella <sgarzare@redhat.com>
  Date:   2021-10-05 (Tue, 05 Oct 2021)

  Changed paths:
    M block/aio_task.c

  Log Message:
  -----------
  block/aio_task: assert `max_busy_tasks` is greater than 0

All code in block/aio_task.c expects `max_busy_tasks` to always
be greater than 0.

Assert this condition during the AioTaskPool creation where
`max_busy_tasks` is set.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211005161157.282396-3-sgarzare@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: d431131439f228626aedc6d211c73b2a3616d5e1
      
https://github.com/qemu/qemu/commit/d431131439f228626aedc6d211c73b2a3616d5e1
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M job.c

  Log Message:
  -----------
  job: Context changes in job_completed_txn_abort()

Finalizing the job may cause its AioContext to change.  This is noted by
job_exit(), which points at job_txn_apply() to take this fact into
account.

However, job_completed() does not necessarily invoke job_txn_apply()
(through job_completed_txn_success()), but potentially also
job_completed_txn_abort().  The latter stores the context in a local
variable, and so always acquires the same context at its end that it has
released in the beginning -- which may be a different context from the
one that job_exit() releases at its end.  If it is different, qemu
aborts ("qemu_mutex_unlock_impl: Operation not permitted").

Drop the local @outer_ctx variable from job_completed_txn_abort(), and
instead re-acquire the actual job's context at the end of the function,
so job_exit() will release the same.

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-2-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: a3810da5cff152a2a1b2d25a8b8080f640e491b6
      
https://github.com/qemu/qemu/commit/a3810da5cff152a2a1b2d25a8b8080f640e491b6
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/mirror.c

  Log Message:
  -----------
  mirror: Keep s->synced on error

An error does not take us out of the READY phase, which is what
s->synced signifies.  It does of course mean that source and target are
no longer in sync, but that is what s->actively_sync is for -- s->synced
never meant that source and target are in sync, only that they were at
some point (and at that point we transitioned into the READY phase).

The tangible problem is that we transition to READY once we are in sync
and s->synced is false.  By resetting s->synced here, we will transition
from READY to READY once the error is resolved (if the job keeps
running), and that transition is not allowed.

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20211006151940.214590-3-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 447162242803bdc38bb198312e1d0a0675948424
      
https://github.com/qemu/qemu/commit/447162242803bdc38bb198312e1d0a0675948424
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/mirror.c

  Log Message:
  -----------
  mirror: Drop s->synced

As of HEAD^, there is no meaning to s->synced other than whether the job
is READY or not.  job_is_ready() gives us that information, too.

Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20211006151940.214590-4-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 1d4a43e9464f8945bd8aa2ed9d95f184b011befe
      
https://github.com/qemu/qemu/commit/1d4a43e9464f8945bd8aa2ed9d95f184b011befe
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M job.c

  Log Message:
  -----------
  job: Force-cancel jobs in a failed transaction

When a transaction is aborted, no result matters, and so all jobs within
should be force-cancelled.

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-5-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 4cfb3f05627ad82af473e7f7ae113c3884cd04e3
      
https://github.com/qemu/qemu/commit/4cfb3f05627ad82af473e7f7ae113c3884cd04e3
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/replication.c
    M blockdev.c
    M include/qemu/job.h
    M job.c
    M tests/qemu-iotests/109.out
    M tests/qemu-iotests/tests/qsd-jobs.out
    M tests/unit/test-blockjob.c

  Log Message:
  -----------
  job: @force parameter for job_cancel_sync()

Callers should be able to specify whether they want job_cancel_sync() to
force-cancel the job or not.

In fact, almost all invocations do not care about consistency of the
result and just want the job to terminate as soon as possible, so they
should pass force=true.  The replication block driver is the exception,
specifically the active commit job it runs.

As for job_cancel_sync_all(), all callers want it to force-cancel all
jobs, because that is the point of it: To cancel all remaining jobs as
quickly as possible (generally on process termination).  So make it
invoke job_cancel_sync() with force=true.

This changes some iotest outputs, because quitting qemu while a mirror
job is active will now lead to it being cancelled instead of completed,
which is what we want.  (Cancelling a READY mirror job with force=false
may take an indefinite amount of time, which we do not want when
quitting.  If users want consistent results, they must have all jobs be
done before they quit qemu.)

Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-6-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 73895f3838cd7fdaf185cf1dbc47be58844a966f
      
https://github.com/qemu/qemu/commit/73895f3838cd7fdaf185cf1dbc47be58844a966f
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/backup.c
    M block/mirror.c
    M include/qemu/job.h
    M job.c

  Log Message:
  -----------
  jobs: Give Job.force_cancel more meaning

We largely have two cancel modes for jobs:

First, there is actual cancelling.  The job is terminated as soon as
possible, without trying to reach a consistent result.

Second, we have mirror in the READY state.  Technically, the job is not
really cancelled, but it just is a different completion mode.  The job
can still run for an indefinite amount of time while it tries to reach a
consistent result.

We want to be able to clearly distinguish which cancel mode a job is in
(when it has been cancelled).  We can use Job.force_cancel for this, but
right now it only reflects cancel requests from the user with
force=true, but clearly, jobs that do not even distinguish between
force=false and force=true are effectively always force-cancelled.

So this patch has Job.force_cancel signify whether the job will
terminate as soon as possible (force_cancel=true) or whether it will
effectively remain running despite being "cancelled"
(force_cancel=false).

To this end, we let jobs that provide JobDriver.cancel() tell the
generic job code whether they will terminate as soon as possible or not,
and for jobs that do not provide that method we assume they will.

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20211006151940.214590-7-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 401dd096ef9d19956977b371362107448575ef40
      
https://github.com/qemu/qemu/commit/401dd096ef9d19956977b371362107448575ef40
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M job.c

  Log Message:
  -----------
  job: Do not soft-cancel after a job is done

The only job that supports a soft cancel mode is the mirror job, and in
such a case it resets its .cancelled field before it leaves its .run()
function, so it does not really count as cancelled.

However, it is possible to cancel the job after .run() returns and
before job_exit() (which is run in the main loop) is executed.  Then,
.cancelled would still be true and the job would count as cancelled.
This does not seem to be in the interest of the mirror job, so adjust
job_cancel_async() to not set .cancelled in such a case, and
job_cancel() to not invoke job_completed_txn_abort().

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-8-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 08b83bff2a77e082d0b29680a40f0aaf9996bd16
      
https://github.com/qemu/qemu/commit/08b83bff2a77e082d0b29680a40f0aaf9996bd16
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/mirror.c
    M include/qemu/job.h
    M job.c

  Log Message:
  -----------
  job: Add job_cancel_requested()

Most callers of job_is_cancelled() actually want to know whether the job
is on its way to immediate termination.  For example, we refuse to pause
jobs that are cancelled; but this only makes sense for jobs that are
really actually cancelled.

A mirror job that is cancelled during READY with force=false should
absolutely be allowed to pause.  This "cancellation" (which is actually
a kind of completion) may take an indefinite amount of time, and so
should behave like any job during normal operation.  For example, with
on-target-error=stop, the job should stop on write errors.  (In
contrast, force-cancelled jobs should not get write errors, as they
should just terminate and not do further I/O.)

Therefore, redefine job_is_cancelled() to only return true for jobs that
are force-cancelled (which as of HEAD^ means any job that interprets the
cancellation request as a request for immediate termination), and add
job_cancel_requested() as the general variant, which returns true for
any jobs which have been requested to be cancelled, whether it be
immediately or after an arbitrarily long completion phase.

Finally, here is a justification for how different job_is_cancelled()
invocations are treated by this patch:

- block/mirror.c (mirror_run()):
  - The first invocation is a while loop that should loop until the job
    has been cancelled or scheduled for completion.  What kind of cancel
    does not matter, only the fact that the job is supposed to end.

  - The second invocation wants to know whether the job has been
    soft-cancelled.  Calling job_cancel_requested() is a bit too broad,
    but if the job were force-cancelled, we should leave the main loop
    as soon as possible anyway, so this should not matter here.

  - The last two invocations already check force_cancel, so they should
    continue to use job_is_cancelled().

- block/backup.c, block/commit.c, block/stream.c, anything in tests/:
  These jobs know only force-cancel, so there is no difference between
  job_is_cancelled() and job_cancel_requested().  We can continue using
  job_is_cancelled().

- job.c:
  - job_pause_point(), job_yield(), job_sleep_ns(): Only force-cancelled
    jobs should be prevented from being paused.  Continue using 
job_is_cancelled().

  - job_update_rc(), job_finalize_single(), job_finish_sync(): These
    functions are all called after the job has left its main loop.  The
    mirror job (the only job that can be soft-cancelled) will clear
    .cancelled before leaving the main loop if it has been
    soft-cancelled.  Therefore, these functions will observe .cancelled
    to be true only if the job has been force-cancelled.  We can
    continue to use job_is_cancelled().
    (Furthermore, conceptually, a soft-cancelled mirror job should not
    report to have been cancelled.  It should report completion (see
    also the block-job-cancel QAPI documentation).  Therefore, it makes
    sense for these functions not to distinguish between a
    soft-cancelled mirror job and a job that has completed as normal.)

  - job_completed_txn_abort(): All jobs other than @job have been
    force-cancelled.  job_is_cancelled() must be true for them.
    Regarding @job itself: job_completed_txn_abort() is mostly called
    when the job's return value is not 0.  A soft-cancelled mirror has a
    return value of 0, and so will not end up here then.
    However, job_cancel() invokes job_completed_txn_abort() if the job
    has been deferred to the main loop, which is mostly the case for
    completed jobs (which skip the assertion), but not for sure.
    To be safe, use job_cancel_requested() in this assertion.

  - job_complete(): This is function eventually invoked by the user
    (through qmp_block_job_complete() or qmp_job_complete(), or
    job_complete_sync(), which comes from qemu-img).  The intention here
    is to prevent a user from invoking job-complete after the job has
    been cancelled.  This should also apply to soft cancelling: After a
    mirror job has been soft-cancelled, the user should not be able to
    decide otherwise and have it complete as normal (i.e. pivoting to
    the target).

  - job_cancel(): Both functions are equivalent (see comment there), but
    we want to use job_is_cancelled(), because this shows that we call
    job_completed_txn_abort() only for force-cancelled jobs.  (As
    explained for job_update_rc(), soft-cancelled jobs should be treated
    as if they have completed as normal.)

Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-9-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 20ad4d204accb27346b05b046ee8225c6725ef49
      
https://github.com/qemu/qemu/commit/20ad4d204accb27346b05b046ee8225c6725ef49
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/mirror.c

  Log Message:
  -----------
  mirror: Use job_is_cancelled()

mirror_drained_poll() returns true whenever the job is cancelled,
because "we [can] be sure that it won't issue more requests".  However,
this is only true for force-cancelled jobs, so use job_is_cancelled().

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-10-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 4feeec7e23b4151c962cb1b9f1a0e403803dfaee
      
https://github.com/qemu/qemu/commit/4feeec7e23b4151c962cb1b9f1a0e403803dfaee
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/mirror.c

  Log Message:
  -----------
  mirror: Check job_is_cancelled() earlier

We must check whether the job is force-cancelled early in our main loop,
most importantly before any `continue` statement.  For example, we used
to have `continue`s before our current checking location that are
triggered by `mirror_flush()` failing.  So, if `mirror_flush()` kept
failing, force-cancelling the job would not terminate it.

Jobs can be cancelled while they yield, and once they are
(force-cancelled), they should not generate new I/O requests.
Therefore, we should put the check after the last yield before
mirror_iteration() is invoked.

Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-11-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 9b230ef93e406dc46b82eebde996ef6a08b929d6
      
https://github.com/qemu/qemu/commit/9b230ef93e406dc46b82eebde996ef6a08b929d6
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/mirror.c

  Log Message:
  -----------
  mirror: Stop active mirroring after force-cancel

Once the mirror job is force-cancelled (job_is_cancelled() is true), we
should not generate new I/O requests.  This applies to active mirroring,
too, so stop it once the job is cancelled.

(We must still forward all I/O requests to the source, though, of
course, but those are not really I/O requests generated by the job, so
this is fine.)

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-12-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: a640fa0e381caf572266c6c07d026dd07cf66a49
      
https://github.com/qemu/qemu/commit/a640fa0e381caf572266c6c07d026dd07cf66a49
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/mirror.c
    M job.c

  Log Message:
  -----------
  mirror: Do not clear .cancelled

Clearing .cancelled before leaving the main loop when the job has been
soft-cancelled is no longer necessary since job_is_cancelled() only
returns true for jobs that have been force-cancelled.

Therefore, this only makes a differences in places that call
job_cancel_requested().  In block/mirror.c, this is done only before
.cancelled was cleared.

In job.c, there are two callers:
- job_completed_txn_abort() asserts that .cancelled is true, so keeping
  it true will not affect this place.

- job_complete() refuses to let a job complete that has .cancelled set.
  It is correct to refuse to let the user invoke job-complete on mirror
  jobs that have already been soft-cancelled.

With this change, there are no places that reset .cancelled to false and
so we can be sure that .force_cancel can only be true if .cancelled is
true as well.  Assert this in job_is_cancelled().

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-13-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 2451f72527d8760566a499b7513e17aaceb0f131
      
https://github.com/qemu/qemu/commit/2451f72527d8760566a499b7513e17aaceb0f131
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    A tests/qemu-iotests/tests/mirror-ready-cancel-error
    A tests/qemu-iotests/tests/mirror-ready-cancel-error.out

  Log Message:
  -----------
  iotests: Add mirror-ready-cancel-error test

Test what happens when there is an I/O error after a mirror job in the
READY phase has been cancelled.

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20211006151940.214590-14-hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


  Commit: 14f12119aa675e9e28207a48b0728a2daa5b88d6
      
https://github.com/qemu/qemu/commit/14f12119aa675e9e28207a48b0728a2daa5b88d6
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M block/aio_task.c
    M block/backup.c
    M block/mirror.c
    M block/replication.c
    M blockdev.c
    M include/qemu/job.h
    M job.c
    M tests/qemu-iotests/109.out
    A tests/qemu-iotests/tests/mirror-ready-cancel-error
    A tests/qemu-iotests/tests/mirror-ready-cancel-error.out
    M tests/qemu-iotests/tests/qsd-jobs.out
    M tests/unit/test-blockjob.c

  Log Message:
  -----------
  Merge remote-tracking branch 
'remotes/vsementsov/tags/pull-jobs-2021-10-07-v2' into staging

mirror: Handle errors after READY cancel
v2: add small fix by Stefano, Hanna's series fixed

# gpg: Signature made Thu 07 Oct 2021 08:25:07 AM PDT
# gpg:                using RSA key 8B9C26CDB2FD147C880E86A1561F24C1F19F79FB
# gpg: Good signature from "Vladimir Sementsov-Ogievskiy 
<vsementsov@virtuozzo.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8B9C 26CD B2FD 147C 880E  86A1 561F 24C1 F19F 79FB

* remotes/vsementsov/tags/pull-jobs-2021-10-07-v2:
  iotests: Add mirror-ready-cancel-error test
  mirror: Do not clear .cancelled
  mirror: Stop active mirroring after force-cancel
  mirror: Check job_is_cancelled() earlier
  mirror: Use job_is_cancelled()
  job: Add job_cancel_requested()
  job: Do not soft-cancel after a job is done
  jobs: Give Job.force_cancel more meaning
  job: @force parameter for job_cancel_sync()
  job: Force-cancel jobs in a failed transaction
  mirror: Drop s->synced
  mirror: Keep s->synced on error
  job: Context changes in job_completed_txn_abort()
  block/aio_task: assert `max_busy_tasks` is greater than 0
  block/backup: avoid integer overflow of `max-workers`

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/3c019339830a...14f12119aa67



reply via email to

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