Re: [Qemu-block] KVM Forum block no[td]es

On 11/12/18 1:25 AM, Max Reitz wrote: > This is what I’ve taken from two or three BoF-like get-togethers on > blocky things. Amendments are more than welcome, of course. > > > > Permission system > = > > GRAPH_MOD > - > > We need some way for the commit job to prevent

Re: [Qemu-block] [PATCH] migration/block-dirty-bitmap: fix Coverity CID1390625

On 11/15/18 6:48 AM, Peter Maydell wrote: > On 17 October 2018 at 10:51, Stefan Hajnoczi wrote: >> On Tue, Oct 16, 2018 at 04:20:18PM +0300, Vladimir Sementsov-Ogievskiy wrote: >>> Theoretically possible that we finish the skipping loop with bs = NULL >>> and the following code will crash

Re: [Qemu-block] Change in qemu 2.12 causes qemu-img convert to NBD to write more data

On Sun, Nov 11, 2018 at 6:11 PM Nir Soffer wrote: > On Wed, Nov 7, 2018 at 7:55 PM Nir Soffer wrote: > >> On Wed, Nov 7, 2018 at 7:27 PM Kevin Wolf wrote: >> >>> Am 07.11.2018 um 15:56 hat Nir Soffer geschrieben: >>> > Wed, Nov 7, 2018 at 4:36 PM Richard W.M. Jones >>> wrote: >>> > >>> > >

Re: [Qemu-block] [Qemu-devel] [PULL 29/36] qemu-iotests: Test auto-read-only with -drive and -blockdev

On 11/5/18 10:37 AM, Kevin Wolf wrote: Signed-off-by: Kevin Wolf Reviewed-by: Eric Blake --- tests/qemu-iotests/232 | 147 + tests/qemu-iotests/232.out | 59 +++ tests/qemu-iotests/group | 1 + 3 files changed, 207 insertions(+)

Re: [Qemu-block] [Qemu-devel] [PATCH for-3.1?] file-posix: Better checks of 64-bit copy_range

On 11/14/18 3:05 PM, Eric Blake wrote: file-posix.c was taking a 64-bit bytes in raw_co_copy_range_to(), passing it through a 32-bit parameter of paio_submit_co_full(), then widening it back to size_t when assigning into acb->aio_nbytes. Looking at io.c, I can't quickly tell if

Re: [Qemu-block] [PATCH for 3.1 v3 0/3] minor qcow2 compression improvements

On 11/14/18 8:35 AM, Kevin Wolf wrote: Am 14.11.2018 um 00:03 hat Eric Blake geschrieben: As the added iotests shows, we have a (corner case) data corruption that is user triggerable, therefore, this is still appropriate for inclusion in 3.1. Thanks, applied to the block branch. Patch 2 and

[Qemu-block] [PATCH for 3.1 v9] qcow2: Document some maximum size constraints

Although off_t permits up to 63 bits (8EB) of file offsets, in practice, we're going to hit other limits first. Document some of those limits in the qcow2 spec (some are inherent, others are implementation choices of qemu), and how choice of cluster size can influence some of the limits. While

Re: [Qemu-block] [Qemu-devel] [PATCH v2 09/13] RFC: crypto: Rely on block layer for fragmentation

On Wed, Nov 14, 2018 at 08:03:30PM -0600, Eric Blake wrote: > No need to reimplement fragmentation to BLOCK_CRYPTO_MAX_IO_SIZE > ourselves when we can ask the block layer to do it for us. > > Signed-off-by: Eric Blake > > --- > Question - is this patch for 'crypto' acceptable, or should we

Re: [Qemu-block] [PATCH] nvme: fix oob access issue(CVE-2018-16847)

On 15/11/2018 04:14, Li Qiang wrote: > > > Paolo Bonzini mailto:pbonz...@redhat.com>> 于2018 > 年11月14日周三 下午11:44写道： > > On 14/11/2018 02:38, Li Qiang wrote: > > > > > > Paolo Bonzini mailto:pbonz...@redhat.com> > >>

Re: [Qemu-block] [PATCH] migration/block-dirty-bitmap: fix Coverity CID1390625

On 11/15/18 6:48 AM, Peter Maydell wrote: > On 17 October 2018 at 10:51, Stefan Hajnoczi wrote: >> On Tue, Oct 16, 2018 at 04:20:18PM +0300, Vladimir Sementsov-Ogievskiy wrote: >>> Theoretically possible that we finish the skipping loop with bs = NULL >>> and the following code will crash

Re: [Qemu-block] [PATCH v2 13/13] block: Enforce non-zero bl.max_transfer

On 11/15/18 10:24 AM, Kevin Wolf wrote: Am 15.11.2018 um 03:03 hat Eric Blake geschrieben: The raw format driver and the filter drivers default to picking up the same limits as what they wrap, and I've audited that they are otherwise simple enough in their passthrough to be 64-bit clean; it's

Re: [Qemu-block] [PATCH v2 05/13] block: Switch to 64-bit bl.max_transfer

On 11/15/18 9:45 AM, Kevin Wolf wrote: Am 15.11.2018 um 03:03 hat Eric Blake geschrieben: This change has no semantic impact: all drivers either leave the value at 0 (no inherent 32-bit limit is still translated into fragmentation below 2G; see the previous patch for that audit), or set it to a

Re: [Qemu-block] [PATCH v2 13/13] block: Enforce non-zero bl.max_transfer

Am 15.11.2018 um 03:03 hat Eric Blake geschrieben: > The raw format driver and the filter drivers default to picking > up the same limits as what they wrap, and I've audited that they > are otherwise simple enough in their passthrough to be 64-bit > clean; it's not worth changing their

Re: [Qemu-block] [PATCH v3 1/3] qcow2: Document some maximum size constraints

On 11/15/18 9:17 AM, Alberto Garcia wrote: On Wed 14 Nov 2018 12:03:17 AM CET, Eric Blake wrote: @@ -427,7 +451,9 @@ Standard Cluster Descriptor: Compressed Clusters Descriptor (x = 62 - (cluster_bits - 8)): Bit 0 - x-1: Host cluster offset. This is usually _not_ aligned to a -

Re: [Qemu-block] [PATCH 08/12] file-posix: Move read/write operation logic out of aio_worker()

Am 31.10.2018 um 22:56 hat Kevin Wolf geschrieben: > aio_worker() for reads and writes isn't boring enough yet. It still does > some postprocessing for handling short reads and turning the result into > the right return value. > > However, there is no reason why handle_aiocb_rw() couldn't do the

Re: [Qemu-block] [PATCH v2 09/13] RFC: crypto: Rely on block layer for fragmentation

Am 15.11.2018 um 03:03 hat Eric Blake geschrieben: > No need to reimplement fragmentation to BLOCK_CRYPTO_MAX_IO_SIZE > ourselves when we can ask the block layer to do it for us. > > Signed-off-by: Eric Blake > > --- > Question - is this patch for 'crypto' acceptable, or should we stick > with

Re: [Qemu-block] [PATCH v2 05/13] block: Switch to 64-bit bl.max_transfer

Am 15.11.2018 um 03:03 hat Eric Blake geschrieben: > This change has no semantic impact: all drivers either leave the > value at 0 (no inherent 32-bit limit is still translated into > fragmentation below 2G; see the previous patch for that audit), or > set it to a value less than 2G. However,

Re: [Qemu-block] [PATCH 00/12] file-posix: Simplify delegation to worker thread

Am 12.11.2018 um 17:50 hat Kevin Wolf geschrieben: > Am 31.10.2018 um 22:56 hat Kevin Wolf geschrieben: > > This series cleans up and simplifies the code that calls worker thread > > functions for the various operations in the file-posix driver. This > > results in less indirection and better

Re: [Qemu-block] [PATCH v3 1/3] qcow2: Document some maximum size constraints

On Wed 14 Nov 2018 12:03:17 AM CET, Eric Blake wrote: > @@ -427,7 +451,9 @@ Standard Cluster Descriptor: > Compressed Clusters Descriptor (x = 62 - (cluster_bits - 8)): > > Bit 0 - x-1: Host cluster offset. This is usually _not_ aligned to a > -cluster or sector

Re: [Qemu-block] KVM Forum block no[td]es

On Wed 14 Nov 2018 06:24:10 PM CET, Max Reitz wrote: >>> Permission system >>> = >>> >>> GRAPH_MOD >>> - >>> >>> We need some way for the commit job to prevent graph changes on its >>> chain while it is running. Our current blocker doesn’t do the job, >>> however. What to

Re: [Qemu-block] [Qemu-devel] [PATCH v2 for-4.0 00/13] block: byte-based blocking read/write

On 11/15/18 3:02 AM, no-re...@patchew.org wrote: Hi, This series failed docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. Message-id: 20181115020334.1189829-1-ebl...@redhat.com Type:

Re: [Qemu-block] [PATCH] migration/block-dirty-bitmap: fix Coverity CID1390625

On 17 October 2018 at 10:51, Stefan Hajnoczi wrote: > On Tue, Oct 16, 2018 at 04:20:18PM +0300, Vladimir Sementsov-Ogievskiy wrote: >> Theoretically possible that we finish the skipping loop with bs = NULL >> and the following code will crash trying to dereference it. Fix that. >> >>

Re: [Qemu-block] [PATCH v3 1/6] qemu-nbd: add support for authorization of TLS clients

On Mon, Nov 05, 2018 at 04:41:09PM -0600, Eric Blake wrote: > On 10/9/18 8:23 AM, Daniel P. Berrangé wrote: > > From: "Daniel P. Berrange" > > > > Currently any client which can complete the TLS handshake is able to use > > the NBD server. The server admin can turn on the 'verify-peer' option >

Re: [Qemu-block] [PATCH v3 1/6] qemu-nbd: add support for authorization of TLS clients

On Mon, Nov 05, 2018 at 04:41:09PM -0600, Eric Blake wrote: > On 10/9/18 8:23 AM, Daniel P. Berrangé wrote: > > From: "Daniel P. Berrange" > > > > Currently any client which can complete the TLS handshake is able to use > > the NBD server. The server admin can turn on the 'verify-peer' option >

Re: [Qemu-block] [Qemu-devel] [PATCH v2 for-4.0 00/13] block: byte-based blocking read/write

Hi, This series failed docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. Message-id: 20181115020334.1189829-1-ebl...@redhat.com Type: series Subject: [Qemu-devel] [PATCH v2 for-4.0 00/13]

Re: [Qemu-block] [Qemu-devel] [PATCH v2 for-4.0 00/13] block: byte-based blocking read/write

Hi, This series failed docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. Message-id: 20181115020334.1189829-1-ebl...@redhat.com Type: series Subject: [Qemu-devel] [PATCH v2 for-4.0