From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-block@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com,
eesposit@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 07/20] graph-lock: Fix GRAPH_RDLOCK_GUARD*() to be reader lock
Date: Thu, 27 Apr 2023 13:28:15 +0200 [thread overview]
Message-ID: <ZEpcT2MNisoGppOk@redhat.com> (raw)
In-Reply-To: <nuzeche33pyoj55mjo6qnv4qay5l4gk34ka2pom3tsdjle5drv@5sgcju7s7z7q>
Am 25.04.2023 um 22:36 hat Eric Blake geschrieben:
> On Tue, Apr 25, 2023 at 07:31:45PM +0200, Kevin Wolf wrote:
> > GRAPH_RDLOCK_GUARD() and GRAPH_RDLOCK_GUARD_MAINLOOP() only take a
> > reader lock for the graph, so the correct annotation for them to use is
> > TSA_ASSERT_SHARED rather than TSA_ASSERT.
>
> The comments at the start of graph-lock.h state that there is only 1
> writer (main loop, under BQL), and all others are readers (coroutines
> in varous AioContext) - but that's regarding the main BdrvGraphRWlock.
I think much of that comment is actually unrelated to BdrvGraphRWlock
(which tracks lock/unlock operations of a single thread), but to graph
locking in general.
> I guess my confusion is over the act of writing the graph (only in the
> main loop) and using TSA annotations to check for safety. Am I
> correct that the reason graph_lockable_auto_lock() only needs a
> TSA_ASSERT_SHARED locking is that it is only reachable from the other
> threads (and not the main loop thread itself) to check that we are
> indeed in a point where we aren't contending with the main loop's
> writable lock?
TSA_ASSERT_SHARED is not a precondition requirement, but a postcondition
assertion. That is, callers of the function can assume that they hold
the lock after this function returns.
This should really be TSA_ACQUIRE_SHARED for graph_lockable_auto_lock(),
but as the comment above it states, this is impossible because TSA
doesn't understand unlocking via the cleanup attribute.
"shared" and "exclusive" in TSA map to "reader" and "writer" lock of a
RWLock. So since we're only taking a reader lock in this function, we
can only assert that the caller now holds a shared lock (which allows
you to call GRAPH_RDLOCK functions), but not an exclusive one like the
code previously suggested (this would allow you to call GRAPH_WRLOCK
functions).
I'm not sure if this fully addresses your confusion yet. Feel free to
ask if there are more unclear parts.
Kevin
next prev parent reply other threads:[~2023-04-27 11:29 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-25 17:31 [PATCH 00/20] Graph locking, part 3 (more block drivers) Kevin Wolf
2023-04-25 17:31 ` [PATCH 01/20] qcow2: Don't call bdrv_getlength() in coroutine_fns Kevin Wolf
2023-04-25 18:37 ` Eric Blake
2023-04-27 11:12 ` Kevin Wolf
2023-04-27 15:07 ` Eric Blake
2023-05-01 15:19 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 02/20] block: Consistently call bdrv_activate() outside coroutine Kevin Wolf
2023-04-25 18:39 ` Eric Blake
2023-05-01 15:21 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 03/20] block: bdrv/blk_co_unref() for calls in coroutine context Kevin Wolf
2023-04-25 20:04 ` Eric Blake
2023-04-27 14:30 ` Paolo Bonzini
2023-04-27 17:00 ` Kevin Wolf
2023-04-27 20:49 ` Paolo Bonzini
2023-05-04 11:18 ` Kevin Wolf
2023-05-01 15:23 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 04/20] block: Don't call no_coroutine_fns in qmp_block_resize() Kevin Wolf
2023-04-25 20:08 ` Eric Blake
2023-04-27 11:15 ` Kevin Wolf
2023-04-27 15:09 ` Eric Blake
2023-05-01 15:24 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 05/20] test-bdrv-drain: Don't modify the graph in coroutines Kevin Wolf
2023-04-25 20:10 ` Eric Blake
2023-05-01 15:30 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 06/20] graph-lock: Add GRAPH_UNLOCKED(_PTR) Kevin Wolf
2023-04-25 20:20 ` Eric Blake
2023-05-01 15:32 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 07/20] graph-lock: Fix GRAPH_RDLOCK_GUARD*() to be reader lock Kevin Wolf
2023-04-25 20:36 ` Eric Blake
2023-04-27 11:28 ` Kevin Wolf [this message]
2023-04-27 15:15 ` Eric Blake
2023-05-01 15:34 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 08/20] block: .bdrv_open is non-coroutine and unlocked Kevin Wolf
2023-04-25 21:04 ` Eric Blake
2023-05-01 16:01 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 09/20] nbd: Remove nbd_co_flush() wrapper function Kevin Wolf
2023-04-25 21:05 ` Eric Blake
2023-05-01 16:02 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 10/20] nbd: Mark nbd_co_do_establish_connection() and callers GRAPH_RDLOCK Kevin Wolf
2023-04-25 21:07 ` Eric Blake
2023-05-01 18:57 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 11/20] vhdx: Take graph lock for accessing a node's parent list Kevin Wolf
2023-04-25 21:08 ` Eric Blake
2023-05-01 18:58 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 12/20] mirror: " Kevin Wolf
2023-04-25 21:09 ` Eric Blake
2023-05-01 18:59 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 13/20] block: Mark bdrv_co_get_allocated_file_size() and callers GRAPH_RDLOCK Kevin Wolf
2023-04-25 21:10 ` Eric Blake
2023-05-01 19:03 ` Stefan Hajnoczi
2023-05-04 10:52 ` Kevin Wolf
2023-04-25 17:31 ` [PATCH 14/20] block: Mark bdrv_co_get_info() " Kevin Wolf
2023-04-25 21:12 ` Eric Blake
2023-05-01 19:04 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 15/20] block: Mark bdrv_co_debug_event() GRAPH_RDLOCK Kevin Wolf
2023-04-25 21:14 ` Eric Blake
2023-05-04 11:12 ` Kevin Wolf
2023-05-01 19:05 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 16/20] block: Mark BlockDriver callbacks for amend job GRAPH_RDLOCK Kevin Wolf
2023-04-25 21:20 ` Eric Blake
2023-05-01 19:07 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 17/20] block: Mark bdrv_query_bds_stats() and callers GRAPH_RDLOCK Kevin Wolf
2023-04-25 21:20 ` Eric Blake
2023-05-01 19:08 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 18/20] block: Mark bdrv_query_block_graph_info() " Kevin Wolf
2023-04-25 21:21 ` Eric Blake
2023-05-01 19:08 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 19/20] block: Mark bdrv_recurse_can_replace() " Kevin Wolf
2023-04-25 21:22 ` Eric Blake
2023-05-01 19:10 ` Stefan Hajnoczi
2023-04-25 17:31 ` [PATCH 20/20] block: Mark bdrv_refresh_limits() " Kevin Wolf
2023-04-25 21:23 ` Eric Blake
2023-05-01 19:10 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZEpcT2MNisoGppOk@redhat.com \
--to=kwolf@redhat.com \
--cc=eblake@redhat.com \
--cc=eesposit@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).