database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00
Code Activity

MDEV-8173: InnoDB; Failing assertion: crypt_data->type == 1

Browse Source 
Make sure that when we publish the crypt_data we access the
memory cache of the tablespace crypt_data. Make sure that
crypt_data is stored whenever it is really needed.

All this is not yet enough in my opinion because:

sql/encryption.cc has DBUG_ASSERT(scheme->type == 1) i.e.
crypt_data->type == CRYPT_SCHEME_1

However, for InnoDB point of view we have global crypt_data
for every tablespace. When we change variables on crypt_data
we take mutex. However, when we use crypt_data for
encryption/decryption we use pointer to this global
structure and no mutex to protect against changes on
crypt_data.

Tablespace encryption starts in fil_crypt_start_encrypting_space
from crypt_data that has crypt_data->type = CRYPT_SCHEME_UNENCRYPTED
and later we write page 0 CRYPT_SCHEME_1 and finally whe publish
that to memory cache.
This commit is contained in:
Jan Lindström
2015-05-20 13:35:51 +03:00
parent 44cd6f22d4
commit 3e55ef26d4
11 changed files with 125 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
sql/encryption.cc
View File

@ -169,7 +169,13 @@ int do_crypt(const unsigned char* src, unsigned int slen,
compile_time_assert(ENCRYPTION_SCHEME_KEY_INVALID ==
(int)ENCRYPTION_KEY_VERSION_INVALID);
DBUG_ASSERT(scheme->type == 1);
// Maybe temporal solution for MDEV-8173
// Rationale: scheme->type is currently global/object
// and when used here might not represent actual state
// of smaller granularity objects e.g. InnoDB page state
// as type is stored to tablespace (FIL) and could represent
// state where key rotation is trying to reach
//DBUG_ASSERT(scheme->type == 1);
if (key_version == ENCRYPTION_KEY_VERSION_INVALID ||
key_version == ENCRYPTION_KEY_NOT_ENCRYPTED)