On Fri, Sep 22, 2023 at 09:47:55PM +0100, Richard W.M. Jones wrote:
> On Fri, Sep 22, 2023 at 12:33:36PM -0500, Eric Blake wrote:
> > There are a number of ways in which gathering information can fail.
> > But when possible, it makes sense to let the server know that we are
> > done talking, as it
On Fri, Sep 22, 2023 at 12:33:36PM -0500, Eric Blake wrote:
> There are a number of ways in which gathering information can fail.
> But when possible, it makes sense to let the server know that we are
> done talking, as it minimizes the likelihood that nbdinfo's error
> message will be obscured by
There are a number of ways in which gathering information can fail.
But when possible, it makes sense to let the server know that we are
done talking, as it minimizes the likelihood that nbdinfo's error
message will be obscured by an accompanying error message by the
server complaining about an
On Thu, Sep 21, 2023 at 03:57:59PM -0500, Eric Blake wrote:
> Cat's out of the bag: Rich's fuzzer run found not one, but two
> independent assertion failures that a malicious server could trigger
> in my recent 64-bit extension code additions. What's more, in the
> process of fixing them, we've
On Fri, Sep 22, 2023 at 05:27:25PM +0200, Lee Garrett wrote:
> On 22.09.23 16:47, Lee Garrett wrote:
> >On 22.09.23 14:54, Richard W.M. Jones wrote:
> >>On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote:
> >>>On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote:
> On
On 22.09.23 16:47, Lee Garrett wrote:
On 22.09.23 14:54, Richard W.M. Jones wrote:
On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote:
On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote:
On 21.09.23 19:43, Richard W.M. Jones wrote:
So this is probably another
On 22.09.23 14:54, Richard W.M. Jones wrote:
On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote:
On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote:
On 21.09.23 19:43, Richard W.M. Jones wrote:
So this is probably another instance or variation of the timezone
On Fri, Sep 22, 2023 at 09:03:53AM -0500, Eric Blake wrote:
> > > $ ./run nbdinfo nbd://localhost
> > > protocol: newstyle-fixed without TLS, using extended packets
> > > ...
> > > block_size_maximum: 33554432
For the human-readable output, should we also be using human_size() on
the
On Fri, Sep 22, 2023 at 02:19:32PM +0200, Laszlo Ersek wrote:
> On 9/21/23 22:58, Eric Blake wrote:
> > As previous patches showed, the NBD spec does not yet forbid a server
> > sending us a size that does not fit in int64_t. We should gracefully
> > handle this during nbdinfo, rather than giving
On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote:
> > On 21.09.23 19:43, Richard W.M. Jones wrote:
> > >So this is probably another instance or variation of the timezone
> > >formatting problem (of schtasks). Which
On 9/21/23 22:58, Eric Blake wrote:
> As previous patches showed, the NBD spec does not yet forbid a server
> sending us a size that does not fit in int64_t. We should gracefully
> handle this during nbdinfo, rather than giving up early.
>
> With the same one-line hack to qemu to set the most
On 9/21/23 22:58, Eric Blake wrote:
> If a server replies to a block status command with an invalid count in
> NBD_REPLY_TYPE_BLOCK_STATUS_EXT, we correctly detect the server's
> error, but fail to mark that we've consumed enough data off the wire
> to resync back to the server's next reply.
On 9/21/23 22:58, Eric Blake wrote:
> As mentioned in the previous commit ("api: Sanitize sizes larger than
> INT64_MAX"), the NBD spec does not (yet) prohibit a server from
> advertising a size larger than INT64_MAX. While we can't report such
> size to the user, v1.16 was at least internally
On 9/21/23 22:58, Eric Blake wrote:
> Our stable API has always claimed that nbd_get_size() reports a
> non-negative value on success, and -1 on failure. While we know of no
> existing production server (such as nbdkit, qemu-nbd, nbd-server) that
> would advertise a size larger than off_t, the
On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote:
> On 21.09.23 19:43, Richard W.M. Jones wrote:
> >So this is probably another instance or variation of the timezone
> >formatting problem (of schtasks). Which version of virt-v2v is this?
> >I want to check that you have a version with
On Thu, Sep 21, 2023 at 10:22:08PM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 21, 2023 at 03:58:01PM -0500, Eric Blake wrote:
> > When fuzzing, it is more desirable to always provoke the server into
> > sending a response, rather than sometimes accidentally skipping a wire
> > call because a
16 matches
Mail list logo
