Skip to content
Snippets Groups Projects
  1. May 30, 2023
  2. May 19, 2023
    • Kevin Wolf's avatar
      block: Call .bdrv_co_create(_opts) unlocked · 4db7ba3b
      Kevin Wolf authored
      
      These are functions that modify the graph, so they must be able to take
      a writer lock. This is impossible if they already hold the reader lock.
      If they need a reader lock for some of their operations, they should
      take it internally.
      
      Many of them go through blk_*(), which will always take the lock itself.
      Direct calls of bdrv_*() need to take the reader lock. Note that while
      locking for bdrv_co_*() calls is checked by TSA, this is not the case
      for the mixed_coroutine_fns bdrv_*(). Holding the lock is still required
      when they are called from coroutine context like here!
      
      This effectively reverts 4ec8df01, but adds some internal locking
      instead.
      
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Message-Id: <20230510203601.418015-2-kwolf@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      4db7ba3b
  3. May 15, 2023
  4. May 10, 2023
  5. Apr 25, 2023
  6. Apr 11, 2023
  7. Mar 27, 2023
    • Kevin Wolf's avatar
      block/export: Fix graph locking in blk_get_geometry() call · d8fbf9aa
      Kevin Wolf authored
      
      blk_get_geometry() eventually calls bdrv_nb_sectors(), which is a
      co_wrapper_mixed_bdrv_rdlock. This means that when it is called from
      coroutine context, it already assume to have the graph locked.
      
      However, virtio_blk_sect_range_ok() in block/export/virtio-blk-handler.c
      (used by vhost-user-blk and VDUSE exports) runs in a coroutine, but
      doesn't take the graph lock - blk_*() functions are generally expected
      to do that internally. This causes an assertion failure when accessing
      an export for the first time if it runs in an iothread.
      
      This is an example of the crash:
      
        $ ./storage-daemon/qemu-storage-daemon --object iothread,id=th0 --blockdev file,filename=/home/kwolf/images/hd.img,node-name=disk --export vhost-user-blk,addr.type=unix,addr.path=/tmp/vhost.sock,node-name=disk,id=exp0,iothread=th0
        qemu-storage-daemon: ../block/graph-lock.c:268: void assert_bdrv_graph_readable(void): Assertion `qemu_in_main_thread() || reader_count()' failed.
      
        (gdb) bt
        #0  0x00007ffff6eafe5c in __pthread_kill_implementation () from /lib64/libc.so.6
        #1  0x00007ffff6e5fa76 in raise () from /lib64/libc.so.6
        #2  0x00007ffff6e497fc in abort () from /lib64/libc.so.6
        #3  0x00007ffff6e4971b in __assert_fail_base.cold () from /lib64/libc.so.6
        #4  0x00007ffff6e58656 in __assert_fail () from /lib64/libc.so.6
        #5  0x00005555556337a3 in assert_bdrv_graph_readable () at ../block/graph-lock.c:268
        #6  0x00005555555fd5a2 in bdrv_co_nb_sectors (bs=0x5555564c5ef0) at ../block.c:5847
        #7  0x00005555555ee949 in bdrv_nb_sectors (bs=0x5555564c5ef0) at block/block-gen.c:256
        #8  0x00005555555fd6b9 in bdrv_get_geometry (bs=0x5555564c5ef0, nb_sectors_ptr=0x7fffef7fedd0) at ../block.c:5884
        #9  0x000055555562ad6d in blk_get_geometry (blk=0x5555564cb200, nb_sectors_ptr=0x7fffef7fedd0) at ../block/block-backend.c:1624
        #10 0x00005555555ddb74 in virtio_blk_sect_range_ok (blk=0x5555564cb200, block_size=512, sector=0, size=512) at ../block/export/virtio-blk-handler.c:44
        #11 0x00005555555dd80d in virtio_blk_process_req (handler=0x5555564cbb98, in_iov=0x7fffe8003830, out_iov=0x7fffe8003860, in_num=1, out_num=0) at ../block/export/virtio-blk-handler.c:189
        #12 0x00005555555dd546 in vu_blk_virtio_process_req (opaque=0x7fffe8003800) at ../block/export/vhost-user-blk-server.c:66
        #13 0x00005555557bf4a1 in coroutine_trampoline (i0=-402635264, i1=32767) at ../util/coroutine-ucontext.c:177
        #14 0x00007ffff6e75c20 in ?? () from /lib64/libc.so.6
        #15 0x00007fffefffa870 in ?? ()
        #16 0x0000000000000000 in ?? ()
      
      Fix this by creating a new blk_co_get_geometry() that takes the lock,
      and changing blk_get_geometry() to be a co_wrapper_mixed around it.
      
      To make the resulting code cleaner, virtio-blk-handler.c can directly
      call the coroutine version now (though that wouldn't be necessary for
      fixing the bug, taking the lock in blk_co_get_geometry() is what fixes
      it).
      
      Fixes: 8ab8140a
      Reported-by: default avatarLukáš Doktor <ldoktor@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Message-Id: <20230327113959.60071-1-kwolf@redhat.com>
      Reviewed-by: default avatarEmanuele Giuseppe Esposito <eesposit@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      d8fbf9aa
  8. Feb 23, 2023
  9. Feb 17, 2023
  10. Feb 01, 2023
  11. Jan 24, 2023
  12. Jan 20, 2023
    • Markus Armbruster's avatar
      include/block: Untangle inclusion loops · e2c1c34f
      Markus Armbruster authored
      
      We have two inclusion loops:
      
             block/block.h
          -> block/block-global-state.h
          -> block/block-common.h
          -> block/blockjob.h
          -> block/block.h
      
             block/block.h
          -> block/block-io.h
          -> block/block-common.h
          -> block/blockjob.h
          -> block/block.h
      
      I believe these go back to Emanuele's reorganization of the block API,
      merged a few months ago in commit d7e2fe4a.
      
      Fortunately, breaking them is merely a matter of deleting unnecessary
      includes from headers, and adding them back in places where they are
      now missing.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20221221133551.3967339-2-armbru@redhat.com>
      e2c1c34f
Loading