Skip to content
  • Eric Blake's avatar
    a7c18670
    nbd/client: Accept 64-bit block status chunks · a7c18670
    Eric Blake authored
    
    
    Once extended mode is enabled, we need to accept 64-bit status replies
    (even for replies that don't exceed a 32-bit length).  It is easier to
    normalize narrow replies into wide format so that the rest of our code
    only has to handle one width.  Although a server is non-compliant if
    it sends a 64-bit reply in compact mode, or a 32-bit reply in extended
    mode, it is still easy enough to tolerate these mismatches.
    
    In normal execution, we are only requesting "base:allocation" which
    never exceeds 32 bits for flag values. But during testing with
    x-dirty-bitmap, we can force qemu to connect to some other context
    that might have 64-bit status bit; however, we ignore those upper bits
    (other than mapping qemu:allocation-depth into something that
    'qemu-img map --output=json' can expose), and since that only affects
    testing, we really don't bother with checking whether more than the
    two least-significant bits are set.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
    Message-ID: <20230925192229.3186470-22-eblake@redhat.com>
    a7c18670
    nbd/client: Accept 64-bit block status chunks
    Eric Blake authored
    
    
    Once extended mode is enabled, we need to accept 64-bit status replies
    (even for replies that don't exceed a 32-bit length).  It is easier to
    normalize narrow replies into wide format so that the rest of our code
    only has to handle one width.  Although a server is non-compliant if
    it sends a 64-bit reply in compact mode, or a 32-bit reply in extended
    mode, it is still easy enough to tolerate these mismatches.
    
    In normal execution, we are only requesting "base:allocation" which
    never exceeds 32 bits for flag values. But during testing with
    x-dirty-bitmap, we can force qemu to connect to some other context
    that might have 64-bit status bit; however, we ignore those upper bits
    (other than mapping qemu:allocation-depth into something that
    'qemu-img map --output=json' can expose), and since that only affects
    testing, we really don't bother with checking whether more than the
    two least-significant bits are set.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
    Message-ID: <20230925192229.3186470-22-eblake@redhat.com>
Loading