On 06.08.21 21:39, Eric Blake wrote:
On Fri, Aug 06, 2021 at 11:38:52AM +0200, Max Reitz wrote:
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
On 06.08.21 21:16, Eric Blake wrote:
On Fri, Aug 06, 2021 at 11:38:48AM +0200, Max Reitz wrote:
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
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 of .cancelled is
true as well. Assert this in job_is_cancelled().
Signed-off-by: Max
/qemu/-/issues/462
Signed-off-by: Max Reitz
---
block/mirror.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/mirror.c b/block/mirror.c
index 024fa2dcea..bf1d50ff1c 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1000,6 +1000,11 @@ static int coroutine_fn
Test what happens when there is an I/O error after a mirror job in the
READY phase has been cancelled.
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
Tested-by: Vladimir Sementsov-Ogievskiy
---
.../tests/mirror-ready-cancel-error | 143
requests generated by the job, so
this is fine.)
Signed-off-by: Max Reitz
---
block/mirror.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/mirror.c b/block/mirror.c
index bf1d50ff1c..af89c1716a 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1418,6 +1418,7 @@ static int coroutine_fn
When a transaction is aborted, no result matters, and so all jobs within
should be force-cancelled.
Signed-off-by: Max Reitz
---
job.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/job.c b/job.c
index 3fe23bb77e..24e7c4fcb7 100644
--- a/job.c
+++ b/job.c
@@ -766,7
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: Max Reitz
---
include/qemu/job.h| 10 ++---
block/replication.c | 4 +-
blockdev.c
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: Max Reitz
---
block/mirror.c | 2 +-
1 file changed, 1 inser
oject/qemu/-/issues/462
Signed-off-by: Max Reitz
---
include/qemu/job.h | 8 +++-
block/mirror.c | 10 --
job.c | 9 +++--
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/include/qemu/job.h b/include/qemu/job.h
index 8aa90f7395..032edf3
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: Max Reitz
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
Signed-off-by: Max Reitz
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Ke
that transition is not allowed.
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Kevin Wolf
---
block/mirror.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/mirror.c b/block/mirror.c
index 98fc66eabf..d73b704473 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@
_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: Max Reitz
---
job.c | 23 ++-
1 file changed, 18
012/12:[] [--] 'iotests: Add mirror-ready-cancel-error test'
Max Reitz (12):
job: Context changes in job_completed_txn_abort()
mirror: Keep s->synced on error
mirror: Drop s->synced
job: Force-cancel jobs in a failed transaction
job: @force parameter for job_cancel_sync{,_a
onceivably occur, and so we should apply
the change from 9c3db310ff0 to gluster's block-status implementation.
Reported-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Max Reitz
---
block/gluster.c | 16
1 file changed, 16 insertions(+)
diff --git a/block/gluster.c b/block/glust
On 04.08.21 12:34, Kevin Wolf wrote:
[ Peter, the question for you is at the end. ]
Am 04.08.2021 um 10:07 hat Max Reitz geschrieben:
On 03.08.21 16:25, Kevin Wolf wrote:
Am 26.07.2021 um 16:46 hat Max Reitz geschrieben:
Most callers of job_is_cancelled() actually want to know whether
On 04.08.21 11:48, Kevin Wolf wrote:
Am 04.08.2021 um 10:25 hat Max Reitz geschrieben:
On 03.08.21 16:34, Kevin Wolf wrote:
Am 26.07.2021 um 16:46 hat Max Reitz geschrieben:
We must check whether the job is force-cancelled early in our main loop,
most importantly before any `continue
On 03.08.21 16:34, Kevin Wolf wrote:
Am 26.07.2021 um 16:46 hat Max Reitz geschrieben:
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
On 03.08.21 16:25, Kevin Wolf wrote:
Am 26.07.2021 um 16:46 hat Max Reitz geschrieben:
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
On 27.07.21 17:47, Vladimir Sementsov-Ogievskiy wrote:
27.07.2021 18:39, Max Reitz wrote:
On 27.07.21 15:04, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 17:46, Max Reitz wrote:
Most callers of job_is_cancelled() actually want to know whether
the job
is on its way to immediate termination
On 29.07.21 18:29, Vladimir Sementsov-Ogievskiy wrote:
29.07.2021 16:47, Max Reitz wrote:
On 29.07.21 13:35, Vladimir Sementsov-Ogievskiy wrote:
29.07.2021 13:38, Max Reitz wrote:
On 29.07.21 12:02, Vladimir Sementsov-Ogievskiy wrote:
28.07.2021 10:00, Max Reitz wrote:
On 27.07.21 18:47
On 29.07.21 13:35, Vladimir Sementsov-Ogievskiy wrote:
29.07.2021 13:38, Max Reitz wrote:
On 29.07.21 12:02, Vladimir Sementsov-Ogievskiy wrote:
28.07.2021 10:00, Max Reitz wrote:
On 27.07.21 18:47, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
That's an alternative to (part of) Max's
"[
On 29.07.21 12:02, Vladimir Sementsov-Ogievskiy wrote:
28.07.2021 10:00, Max Reitz wrote:
On 27.07.21 18:47, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
That's an alternative to (part of) Max's
"[PATCH for-6.1? v2 0/7] mirror: Handle errors after READY cancel"
and shows' my idea o
On 27.07.21 18:47, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
That's an alternative to (part of) Max's
"[PATCH for-6.1? v2 0/7] mirror: Handle errors after READY cancel"
and shows' my idea of handling soft-cancelling READY mirror case
directly in qmp_block_job_cancel. And cleanup all other job
olf
---
block/io.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Reviewed-by: Max Reitz
On 27.07.21 15:13, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 17:46, Max Reitz wrote:
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
On 27.07.21 15:04, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 17:46, Max Reitz wrote:
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
On 27.07.21 16:47, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 10:09, Max Reitz wrote:
job->ret = -ECANCELED;
}
if (job->ret) {
@@ -704,7 +709,7 @@ static int job_finalize_single(Job *job)
/* Emit events only if we actually started */
if (job_start
immediate termination), and add
job_cancel_request() 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.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
Signed-off-by:
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: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
include/qemu/job.h| 10 ++---
block
Test what happens when there is an I/O error after a mirror job in the
READY phase has been cancelled.
Signed-off-by: Max Reitz
---
.../tests/mirror-ready-cancel-error | 143 ++
.../tests/mirror-ready-cancel-error.out | 5 +
2 files changed, 148 insertions
-cancelling the job would not terminate it.
A job being force-cancelled should be treated the same as the job having
failed, so put the check in the same place where we check `s->ret < 0`.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
Signed-off-by: Max Reitz
---
block/mirror
that transition is not allowed.
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/mirror.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/mirror.c b/block/mirror.c
index 98fc66eabf..d73b704473 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -121,7 +121,6
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:
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
Signed-off-by: Max Reitz
---
block/mirror.c | 19 +--
1 file changed, 9 insertions(+),
ameter for job_cancel_sync{,_all}()'
004/7:[0006] [FC] 'jobs: Give Job.force_cancel more meaning'
005/7:[0011] [FC] 'job: Add job_cancel_requested()'
006/7:[] [-C] 'mirror: Check job_is_cancelled() earlier'
007/7:[] [--] 'iotests: Add mirror-ready-cancel-error test'
Max Reitz (7):
mirror:
On 22.07.21 18:25, Vladimir Sementsov-Ogievskiy wrote:
22.07.2021 15:26, Max Reitz wrote:
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 fo
On 22.07.21 19:58, Vladimir Sementsov-Ogievskiy wrote:
22.07.2021 15:26, Max Reitz wrote:
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
Test what happens when there is an I/O error after a mirror job in the
READY phase has been cancelled.
Signed-off-by: Max Reitz
---
.../tests/mirror-ready-cancel-error | 143 ++
.../tests/mirror-ready-cancel-error.out | 5 +
2 files changed, 148 insertions
-cancelling the job would not terminate it.
A job being force-cancelled should be treated the same as the job having
failed, so put the check in the same place where we check `s->ret < 0`.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
Signed-off-by: Max Reitz
---
block/mirror
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:
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: Max Reitz
---
include/qemu/job.h| 10 ++---
block/replication.c | 4 +-
blockdev.c
that transition is not allowed.
Signed-off-by: Max Reitz
---
block/mirror.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/mirror.c b/block/mirror.c
index 98fc66eabf..d73b704473 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -121,7 +121,6 @@ typedef enum MirrorMethod {
static B
immediate termination), and add
job_cancel_request() 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.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/462
Signed-off-by:
l be skipped. If
flushing fails continuously, the job cannot be force-cancelled.
(Patch 5)
Max Reitz (6):
mirror: Keep s->synced on error
job: @force parameter for job_cancel_sync{,_all}()
jobs: Give Job.force_cancel more meaning
job: Add job_cancel_requested()
mirror: Check j
by the other yields.
Signed-off-by: Emanuele Giuseppe Esposito
Message-Id: <20210614082931.24925-6-eespo...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Max Reitz
---
block/blkdebug.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a
Bonzini
Signed-off-by: Emanuele Giuseppe Esposito
Message-Id: <20210614082931.24925-7-eespo...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Max Reitz
---
block/blkdebug.c | 49 ++--
1 file changed, 39 insertions(+), 10 del
ed-off-by: Max Reitz
---
block/blkdebug.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index 6bdeb2c7b3..dd82131d1e 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -789,7 +789,6 @@ static void suspend_request(BlockDriverSta
that is left is for blkdebug_debug_event to handle the
yielding.
Co-developed-by: Paolo Bonzini
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20210614082931.24925-3-eespo...@redhat.com>
Signed-off-by: Max Reitz
---
block/blkdebug.
The following changes since commit 7457b407edd6e8555e4b46488aab2f13959fccf8:
Merge remote-tracking branch
'remotes/thuth-gitlab/tags/pull-request-2021-07-19' into staging (2021-07-19
11:34:08 +0100)
are available in the Git repository at:
https://github.com/XanClic/qemu.git
-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20210614082931.24925-4-eespo...@redhat.com>
Signed-off-by: Max Reitz
---
block/blkdebug.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index e8fdf7b056..6bdeb2c7b3
th a given tag.
Co-developed-by: Paolo Bonzini
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Message-Id: <20210614082931.24925-2-eespo...@redhat.com>
Signed-off-by: Max Reitz
---
block/blkdebug.c | 33 ++---
On 16.07.21 16:24, Vladimir Sementsov-Ogievskiy wrote:
16.07.2021 15:38, Max Reitz wrote:
Subject: s/compressiont_type/compression_type/
On 05.07.21 11:15, Vladimir Sementsov-Ogievskiy wrote:
Like it is done in iotests.py in qemu_img_create_prepare_args(), let's
not follow compression_type
deletion(-)
Reviewed-by: Max Reitz
-Ogievskiy
---
tests/qemu-iotests/214 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Max Reitz
deletion(-)
Reviewed-by: Max Reitz
But as I said, I’d prefer this to come right after patch 10.
Max
On 05.07.21 11:15, Vladimir Sementsov-Ogievskiy wrote:
We want iotests pass with both the default zlib compression and with
IMGOPTS='compression_type=zstd'.
Actually the only test that is interested in real compression type in
test output is 287 (test for qcow2 compression type), so implement
tests/qemu-iotests/061 | 36 ++--
tests/qemu-iotests/137 | 2 +-
tests/qemu-iotests/287 | 8
7 files changed, 49 insertions(+), 49 deletions(-)
Reviewed-by: Max Reitz
I think I’d have merged patch 13 into this one, but if you want to keep
it se
insertions(+)
Reviewed-by: Max Reitz
Subject: s/compressiont_type/compression_type/
On 05.07.21 11:15, Vladimir Sementsov-Ogievskiy wrote:
Like it is done in iotests.py in qemu_img_create_prepare_args(), let's
not follow compression_type=zstd of IMGOPTS if test creates image in
old format.
Signed-off-by: Vladimir
s->incompatible_features = 0;
Not wrong, though I’d prefer
s->incompatible_features &= ~QCOW2_INCOMPAT_COMPRESSION;
Anyway:
Reviewed-by: Max Reitz
+s->compression_type = QCOW2_COMPRESSION_TYPE_ZLIB;
+}
+
+assert(s->incompatible_features == 0);
+
s->qcow_version = target_version;
ret = qcow2_update_header(bs);
if (ret < 0) {
img_info_log(nbd_uri)
There’s another `qemu_img_log("info", nbd_uri)` call above this place.
We can’t use `img_info_log()` there, because in that case, the image is
not in qcow2 format (which is the test’s image format), but
`img_info_log()` enforces “-f {imgfmt}”. It would hav
On 05.07.21 11:15, Vladimir Sementsov-Ogievskiy wrote:
We want iotests pass with both the default zlib compression and with
IMGOPTS='compression_type=zstd'.
Actually the only test that is interested in real compression type in
test output is 287 (test for qcow2 compression type) and it's in
Sementsov-Ogievskiy
---
tests/qemu-iotests/065 | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Reviewed-by: Max Reitz
-Ogievskiy
---
tests/qemu-iotests/303 | 25 -
tests/qemu-iotests/303.out | 30 +-
2 files changed, 45 insertions(+), 10 deletions(-)
Reviewed-by: Max Reitz
On 05.07.21 11:15, Vladimir Sementsov-Ogievskiy wrote:
Adding support of IMGOPTS (like in bash tests) allows user to pass a
lot of different options. Still, some may require additional logic.
Now we want compression_type option, so add some smart logic around it:
ignore compression_type=zstd in
Sementsov-Ogievskiy
---
tests/qemu-iotests/210| 8
tests/qemu-iotests/iotests.py | 5 +++--
2 files changed, 7 insertions(+), 6 deletions(-)
Reviewed-by: Max Reitz
Reminds me how I sent a huge series for having Python tests support
$IMGOPTS two years ago
(https://lists.nongnu.org
tests will fail due to
delays in the QMP responses.
Signed-off-by: Emanuele Giuseppe Esposito
---
v7:
* Adjust documentation and error message when -gdb and -valgrind are set
at the same time [Eric]
* Add missing Acked-by [John]
All patches I didn’t comment on:
Reviewed-by: Max Reitz
Which
,
Sorry, my bad: s/redirect/redirects/
With that fixed:
Reviewed-by: Max Reitz
Max
+ instead of saving it into a log file in
+ ``$TEST_DIR/qemu-machine-``.
+
Test case groups
to it for example with
+ ``gdb -iex "target remote $addr"``, where ``$addr`` is the address
+ ``gdbserver`` listens on.
+ If the ``-gdb`` option is not used, ``$GDB_OPTIONS`` is ignored,
+ regardless on whether it is set or not.
s/on/of/
With that: Reviewed-by: Max Reitz
On 05.07.21 08:57, Emanuele Giuseppe Esposito wrote:
Remove read timer in test script when GDB_OPTIONS are set,
so that the bash tests won't timeout while running gdb.
The only limitation here is that running a script with gdbserver
will make the test output mismatch with the expected
results,
On 14.06.21 10:29, Emanuele Giuseppe Esposito wrote:
When qemu_coroutine_enter is executed in a loop
(even QEMU_FOREACH_SAFE), the new routine can modify the list,
for example removing an element, causing problem when control
is given back to the caller that continues iterating on the same list.
On 14.06.21 10:29, Emanuele Giuseppe Esposito wrote:
We want to move qemu_coroutine_yield() after the loop on rules,
because QLIST_FOREACH_SAFE is wrong if the rule list is modified
while the coroutine has yielded. Therefore move the suspended
request to the heap and clean it up from the remove
On 14.06.21 10:29, Emanuele Giuseppe Esposito wrote:
Add a counter for each action that a rule can trigger.
This is mainly used to keep track of how many coroutine_yield()
we need to perform after processing all rules in the list.
Co-developed-by: Paolo Bonzini
Signed-off-by: Emanuele Giuseppe
On 28.06.21 21:10, Eric Blake wrote:
+++ b/include/block/block_int.h
@@ -347,6 +347,11 @@ struct BlockDriver {
* clamped to bdrv_getlength() and aligned to request_alignment,
* as well as non-NULL pnum, map, and file; in turn, the driver
* must return an error or set pnum
On 06.07.21 19:04, Kevin Wolf wrote:
Am 23.06.2021 um 17:01 hat Max Reitz geschrieben:
As we have attempted before
(https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06451.html,
"file-posix: Cache lseek result for data regions";
https://lists.nongnu.org/archive/html/qemu-blo
Signed-off-by: Max Reitz
---
tests/qemu-iotests/tests/fuse-allow-other | 175 ++
tests/qemu-iotests/tests/fuse-allow-other.out | 88 +
2 files changed, 263 insertions(+)
create mode 100755 tests/qemu-iotests/tests/fuse-allow-other
create mode 100644 tests/qemu
Test that +w on read-only FUSE exports returns an EROFS error. u+x on
the other hand should work. (There is no special reason to choose u+x
here, it simply is like +w another flag that is not set by default.)
Signed-off-by: Max Reitz
---
tests/qemu-iotests/308 | 11 +++
tests/qemu
, instead of only actually
attempting to write to it. (That is an improvement.)
Signed-off-by: Max Reitz
---
block/export/fuse.c| 8 ++--
tests/qemu-iotests/308 | 3 ++-
tests/qemu-iotests/308.out | 2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/block/export
In order to support changing other attributes than the file size in
fuse_setattr(), we have to give each its own independent branch. This
also applies to the only attribute we do support right now.
Signed-off-by: Max Reitz
Reviewed-by: Kevin Wolf
---
block/export/fuse.c | 20
-other=auto have no
advantage. OTOH, allow-other=on will not work on systems where
user_allow_other is disabled, and with allow-other=auto, we get said
error message that we would need to filter out again. Just disabling
allow-other is simplest.
Signed-off-by: Max Reitz
---
qapi/block-export.json
:[] [--] 'export/fuse: Give SET_ATTR_SIZE its own branch'
004/6:[0039] [FC] 'export/fuse: Let permissions be adjustable'
005/6:[down] 'iotests/308: Test +w on read-only FUSE exports'
006/6:[down] 'iotests/fuse-allow-other: Test allow-other'
Max Reitz (6):
export/fuse: Pass default_permissions for mount
Allow changing the file mode, UID, and GID through SETATTR.
Without allow_other, UID and GID are not allowed to be changed, because
it would not make sense. Also, changing group or others' permissions
is not allowed either.
For read-only exports, +w cannot be set.
Signed-off-by: Max Reitz
On 25.06.21 10:52, Paolo Bonzini wrote:
On 25/06/21 10:37, Max Reitz wrote:
Thanks, looks good to me, though I’m afraid I’ll be on PTO the next
two weeks so I can’t take this series through my tree... (I don’t
really want to send a pull request today when I probably wouldn’t be
able to deal
On 24.06.21 20:04, Paolo Bonzini wrote:
New patches:
- 3/4 (for review comments),
- 9 (split for ease of review),
- 11 (new bugfix)
v1->v2: add missing patch
v2->v3: add max_hw_transfer to BlockLimits
v3->v4: fix compilation after patch 1, tweak commit messages according
to
== -1) {
return -errno;
}
I think the macro TFR() from qemu-common.h could be applied here,
probably like `TFR(ret = ioctl(...));`.
No matter:
Reviewed-by: Max Reitz
(+), 1 deletion(-)
Reviewed-by: Max Reitz
--
1 file changed, 16 insertions(+), 18 deletions(-)
Thanks, that’s much better.
Reviewed-by: Max Reitz
Paolo Bonzini
---
block/file-posix.c | 33 ++---
meson.build | 6 +-
qapi/block-core.json | 14 ++
3 files changed, 37 insertions(+), 16 deletions(-)
Reviewed-by: Max Reitz
ged, 38 insertions(+), 29 deletions(-)
Reviewed-by: Max Reitz
/file-posix.c | 2 +-
block/io.c | 2 ++
hw/scsi/scsi-generic.c | 2 +-
include/block/block_int.h | 7 +++
include/sysemu/block-backend.h | 1 +
6 files changed, 25 insertions(+), 2 deletions(-)
Reviewed-by: Max Reitz
ntract of the function does not
specify that INT_MAX means "no maximum", just align the outcome
of the function (whether INT_MAX or bs->bl.max_transfer) before
returning it.
Signed-off-by: Paolo Bonzini
---
block/block-backend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Max Reitz
-off-by: Paolo Bonzini
---
include/qemu/osdep.h | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
What a nice thing to have.
Reviewed-by: Max Reitz
Max Reitz (1):
block/snapshot: Clarify goto fallback behavior
block/snapshot.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
--
2.31.1
On 24.06.21 12:05, Vladimir Sementsov-Ogievskiy wrote:
23.06.2021 18:01, Max Reitz wrote:
As we have attempted before
(https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06451.html,
"file-posix: Cache lseek result for data regions";
https://lists.nongnu.org/archive/html/qemu-blo
All of this is not immediately clear from a quick glance at the code,
so add a comment to the assertion what it is for, and why it is valid.
It certainly confused Coverity.
Reported-by: Coverity (CID 1452774)
Signed-off-by: Max Reitz
Message-Id: <20210503095418.31521-1-mre...@redhat.com&
On 24.06.21 12:25, Vladimir Sementsov-Ogievskiy wrote:
24.06.2021 13:16, Max Reitz wrote:
On 24.06.21 11:15, Vladimir Sementsov-Ogievskiy wrote:
23.06.2021 18:01, Max Reitz wrote:
.bdrv_co_block_status() implementations are free to return a *pnum
that
exceeds @bytes, because
On 24.06.21 11:15, Vladimir Sementsov-Ogievskiy wrote:
23.06.2021 18:01, Max Reitz wrote:
.bdrv_co_block_status() implementations are free to return a *pnum that
exceeds @bytes, because bdrv_co_block_status() in block/io.c will clamp
*pnum as necessary.
On the other hand, if drivers
.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/307 | 15 +++
tests/qemu-iotests/307.out | 8
2 files changed, 23 insertions(+)
diff --git a/tests/qemu-iotests/307 b/tests/qemu-iotests/307
index c7685347bc..b429b5aa50 100755
--- a/tests/qemu-iotests/307
+++ b/tests
1 - 100 of 9029 matches
Mail list logo
