[We are still investigating if a CVE needs to be assigned.]
We have a bug where the blocksize filter can lose the effects of an
aligned write that happens in parallel with an overlapping unaligned
write. In general, a client should be extremely cautious about
overlapping writes; it is not NBD's
On Thu, May 26, 2022 at 09:58:50AM +0100, Richard W.M. Jones wrote:
>
> Is there any way to do this without the literal sleeps? Gitlab CI in
> particular appears to be very contended (I guess it runs in parallel
> on huge systems with vast numbers of unrelated containers). I've seen
> threads
On Thu, May 26, 2022 at 09:16:18AM +0100, Richard W.M. Jones wrote:
...
> > But Python already has a handy way to convert any object that supports
> > the buffer interface into a bytearray. Using it, we can now support
> > many more parameters; passing in b"1"*9 now correctly creates a 9-byte
> >
On May 26 2022, "Richard W.M. Jones" wrote:
> Is there any way to do this without the literal sleeps? Gitlab CI in
> particular appears to be very contended (I guess it runs in parallel
> on huge systems with vast numbers of unrelated containers). I've seen
> threads being created that are so
On 05/26/22 11:23, Richard W.M. Jones wrote:
> On Thu, May 26, 2022 at 10:53:59AM +0200, Laszlo Ersek wrote:
>> On 05/25/22 18:02, Richard W.M. Jones wrote:
>>> In libguestfs we didn't bother to check the return values from any
>>> librpm calls. In some cases where possibly the RPM database is
On 05/26/22 04:18, Eric Blake wrote:
> Demonstrate the bug where an aligned write can be lost if it races
> between the read and write of a RMW unaligned write.
> ---
>
> Sending this out for review of the test; it fails (which it is
> supposed to as long as I don't fix the blocksize filter), but
On Thu, May 26, 2022 at 10:53:59AM +0200, Laszlo Ersek wrote:
> On 05/25/22 18:02, Richard W.M. Jones wrote:
> > In libguestfs we didn't bother to check the return values from any
> > librpm calls. In some cases where possibly the RPM database is
> > faulty, this caused us to return a zero-length
On Thu, May 26, 2022 at 09:58:50AM +0100, Richard W.M. Jones wrote:
>
> Is there any way to do this without the literal sleeps? Gitlab CI in
> particular appears to be very contended (I guess it runs in parallel
> on huge systems with vast numbers of unrelated containers). I've seen
> threads
We always wanted "-cpu best", which means basically the CPU which
always works best (NB: I used the both words "works" and "best").
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Is there any way to do this without the literal sleeps? Gitlab CI in
particular appears to be very contended (I guess it runs in parallel
on huge systems with vast numbers of unrelated containers). I've seen
threads being created that are so starved they never run at all even
in tests running
On 05/25/22 18:02, Richard W.M. Jones wrote:
> In libguestfs we didn't bother to check the return values from any
> librpm calls. In some cases where possibly the RPM database is
> faulty, this caused us to return a zero-length list of installed
> applications (but no error indication).
On Wed, May 25, 2022 at 05:13:53PM +0100, Peter Maydell wrote:
> On Wed, 25 May 2022 at 16:07, Laszlo Ersek wrote:
...
> > Therefore it seems that starting with qemu-4.2, but strictly preceding
> > qemu-7.0, "-cpu max" and "-cpu host" are not "identical" when KVM is
> > enabled; "-cpu max"
On Thu, 26 May 2022 at 09:17, Daniel P. Berrangé wrote:
> We've never said that 'max' is the same for TCG and KVM, nor do
> apps using it require/expect that to be the case.
>
> It is simply intended to expose the maximum featureset available to
> any given accelerator backend. On KVM "maximum
On 05/25/22 18:01, Richard W.M. Jones wrote:
> We previously didn't bother to check the return values from any librpm
> calls. In some cases where possibly the RPM database is faulty, this
> caused us to return a zero-length list of installed applications (but
> no error indication).
>
> One way
On 05/26/22 10:10, Andrew Jones wrote:
> On Wed, May 25, 2022 at 05:13:53PM +0100, Peter Maydell wrote:
>> On Wed, 25 May 2022 at 16:07, Laszlo Ersek wrote:
> ...
>>> Therefore it seems that starting with qemu-4.2, but strictly preceding
>>> qemu-7.0, "-cpu max" and "-cpu host" are not
On 05/25/22 18:13, Peter Maydell wrote:
> On Wed, 25 May 2022 at 16:07, Laszlo Ersek wrote:
>>
>> + Drew & Peter
>>
>> On 05/25/22 15:30, Daniel P. Berrangé wrote:
>> - The patch seems to do what it says in the commit message.
>>
>> - QEMU commit bab52d4bba3f ("target/arm: Add "-cpu max"
On Thu, May 26, 2022 at 10:10:02AM +0200, Andrew Jones wrote:
> On Wed, May 25, 2022 at 05:13:53PM +0100, Peter Maydell wrote:
> > On Wed, 25 May 2022 at 16:07, Laszlo Ersek wrote:
> ...
> > > Therefore it seems that starting with qemu-4.2, but strictly preceding
> > > qemu-7.0, "-cpu max"
On Wed, May 25, 2022 at 08:27:15PM -0500, Eric Blake wrote:
> Prior to this patch, the following fails, but at least seems to give a
> sensible error:
>
> $ nbdsh -c 'nbd.Buffer.from_bytearray(b"1"*8)'
> Traceback (most recent call last):
> File "/usr/lib64/python3.10/runpy.py", line 196, in
18 matches
Mail list logo
