From 3e55ef26d49a900782d2c2bb2c03470faed6ec9d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jan=20Lindstr=C3=B6m?= Date: Wed, 20 May 2015 13:35:51 +0300 Subject: MDEV-8173: InnoDB; Failing assertion: crypt_data->type == 1 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. --- sql/encryption.cc | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'sql/encryption.cc') diff --git a/sql/encryption.cc b/sql/encryption.cc index ab551e00d07..b108eb6a25c 100644 --- a/sql/encryption.cc +++ b/sql/encryption.cc @@ -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) -- cgit v1.2.1