diff options
author | NIIBE Yutaka <gniibe@fsij.org> | 2017-10-27 02:54:48 +0200 |
---|---|---|
committer | Werner Koch <wk@gnupg.org> | 2017-10-27 14:15:58 +0200 |
commit | 3924e1442c6625a2b57573a1a634a5ec56b09a29 (patch) | |
tree | eaea4b4a9e471d5585851ae70b8d937362127b01 /common | |
parent | agent: Allow recursive use of pinentry. (diff) | |
download | gnupg2-3924e1442c6625a2b57573a1a634a5ec56b09a29.tar.xz gnupg2-3924e1442c6625a2b57573a1a634a5ec56b09a29.zip |
agent: Clean up pinentry access locking.
* agent/agent.h (struct server_control_s): Rename PINENTRY_ACTIVE.
* agent/call-pinentry.c (entry_owner): Remove.
(agent_reset_query): Use thread private object of PINENTRY_ACTIVE.
(unlock_pinentry): Add CTRL to arguments to access thread private.
Check and decrement PINENTRY_ACTIVE for recursive use.
(start_pinentry): Check and increment PINENTRY_ACTIVE for recursion.
(agent_askpin): Follow the change of unlock_pinentry API.
(agent_get_passphrase, agent_get_confirmation): Likewise.
(agent_show_message, agent_popup_message_start): Likewise.
(agent_popup_message_stop, agent_clear_passphrase): Likewise.
--
We use the member PINENTRY_ACTIVE as a thread private object.
It's only valid for a single thread at a time.
It would be possible to have a thread shared object of
PINENTRY_ACTIVE, keeping ENTRY_OWNER for distinguishing its
owner (which is also a thread shared object). But, in this case,
access to ENTRY_OWNER is tricky (only comparison to accessing thread
would be OK with no lock), or we need to introduce another lock for
accessing ENTRY_OWNER, which complicates the code too much.
So, simply have a thread private object for recursive pinentry access.
GnuPG-bug-id: 3190
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
(cherry picked from commit fb7828676cc2c01047498898378711e049f73fee)
Diffstat (limited to 'common')
0 files changed, 0 insertions, 0 deletions