commit 19d1f1cc0a2180730219a5fe24580c6d7fbcc239
from: Vladimir Davydov <vdavydov@tarantool.org>
via: Vladimir Davydov <vdavydov.dev@gmail.com>
date: Thu Jun 13 07:26:03 2024 UTC

tuple: don't use offset_slot_cache in vinyl threads

`key_part::offset_slot_cache` and `key_part::format_epoch` are used for
speeding up tuple field lookup in `tuple_field_raw_by_part()`. These
structure members are accessed and updated without any locks, assuming
this code is executed exclusively in the tx thread. However, this isn't
necessarily true because we also perform tuple field lookups in vinyl
read threads. Apparently, this can result in unexpected races and bugs,
for example:

```
  #1  0x590be9f7eb6d in crash_collect+256
  #2  0x590be9f7f5a9 in crash_signal_cb+100
  #3  0x72b111642520 in __sigaction+80
  #4  0x590bea385e3c in load_u32+35
  #5  0x590bea231eba in field_map_get_offset+46
  #6  0x590bea23242a in tuple_field_raw_by_path+417
  #7  0x590bea23282b in tuple_field_raw_by_part+203
  #8  0x590bea23288c in tuple_field_by_part+91
  #9  0x590bea24cd2d in unsigned long tuple_hint<(field_type)5, false, false>(tuple*, key_def*)+103
  #10 0x590be9d4fba3 in tuple_hint+40
  #11 0x590be9d50acf in vy_stmt_hint+178
  #12 0x590be9d53531 in vy_page_stmt+168
  #13 0x590be9d535ea in vy_page_find_key+142
  #14 0x590be9d545e6 in vy_page_read_cb+210
  #15 0x590be9f94ef0 in cbus_call_perform+44
  #16 0x590be9f94eae in cmsg_deliver+52
  #17 0x590be9f9583e in cbus_process+100
  #18 0x590be9f958a5 in cbus_loop+28
  #19 0x590be9d512da in vy_run_reader_f+381
  #20 0x590be9cb4147 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34
  #21 0x590be9f8b697 in fiber_loop+219
  #22 0x590bea374bb6 in coro_init+120
```

Fix this by skipping this optimization for threads other than tx.

No test is added because reproducing this race is tricky. Ideally, bugs
like this one should be caught by fuzzing tests or thread sanitizers.

Closes #10123

NO_DOC=bug fix
NO_TEST=tested manually with fuzzer

commit - 7b72080ddf926d271a4a4cad6f6ffe6e6c00e332
commit + 19d1f1cc0a2180730219a5fe24580c6d7fbcc239
blob - /dev/null
blob + 201f3af65239141f4911cd715f10a698fc2bb3f3 (mode 644)
--- /dev/null
+++ changelogs/unreleased/gh-10123-vy-tuple-field-lookup-fix.md
@@ -0,0 +1,4 @@
+## bugfix/vinyl
+
+* Fixed a bug when internal optimization algorithm caused a crash while a read
+  thread tried to look up a tuple field (gh-10123).
blob - f0873279909740da73c514f90acb4c82d73d71bf
blob + df0cad361bd46a0f0ddac35fd060173f476c9a18
--- src/box/tuple.h
+++ src/box/tuple.h
@@ -1106,19 +1106,23 @@ tuple_field_raw_by_part(struct tuple_format *format, c
 			const uint32_t *field_map,
 			struct key_part *part, int multikey_idx)
 {
-	if (unlikely(part->format_epoch != format->epoch)) {
-		assert(format->epoch != 0);
-		part->format_epoch = format->epoch;
-		/*
-		 * Clear the offset slot cache, since it's stale.
-		 * The cache will be reset by the lookup.
-		 */
-		part->offset_slot_cache = TUPLE_OFFSET_SLOT_NIL;
+	int32_t *offset_slot_cache = NULL;
+	if (cord_is_main()) {
+		offset_slot_cache = &part->offset_slot_cache;
+		if (unlikely(part->format_epoch != format->epoch)) {
+			assert(format->epoch != 0);
+			part->format_epoch = format->epoch;
+			/*
+			 * Clear the offset slot cache, since it's stale.
+			 * The cache will be reset by the lookup.
+			 */
+			*offset_slot_cache = TUPLE_OFFSET_SLOT_NIL;
+		}
 	}
 	return tuple_field_raw_by_path(format, data, field_map, part->fieldno,
 				       part->path, part->path_len,
 				       TUPLE_INDEX_BASE,
-				       &part->offset_slot_cache, multikey_idx);
+				       offset_slot_cache, multikey_idx);
 }
 
 /**