share mode memcache enties must not be evicted from the memcache. If we use the general memcache this could happen. If the cache gets full and a share mode entry is evicted, this leads to smbd crashes. Patch to follow.
Here is the valgrind smbd gets error if a share mode entry gets evicted from the generic memcache. ==189102== Invalid read of size 8 ==189102== at 0x715DF8E: _tc_free_internal (talloc.c:1162) ==189102== by 0x715F341: _tc_free_children_internal (talloc.c:1666) ==189102== by 0x715E1B2: _tc_free_internal (talloc.c:1183) ==189102== by 0x715F341: _tc_free_children_internal (talloc.c:1666) ==189102== by 0x715E1B2: _tc_free_internal (talloc.c:1183) ==189102== by 0x715E428: _talloc_free_internal (talloc.c:1247) ==189102== by 0x715F78E: _talloc_free (talloc.c:1789) ==189102== by 0x5A5CAC7: open_file_ntcreate (open.c:3851) ==189102== by 0x5A6008F: create_file_unixpath (open.c:5298) ==189102== by 0x5A60D55: create_file_default (open.c:5706) ==189102== by 0x5BDE1E5: vfswrap_create_file (vfs_default.c:582) ==189102== by 0x5A6D54B: smb_vfs_call_create_file (vfs.c:1627) ==189102== Address 0x1f9cd460 is 48 bytes inside a block of size 248 free'd ==189102== at 0x4C2CDBB: free (vg_replace_malloc.c:530) ==189102== by 0x715E370: _tc_free_internal (talloc.c:1221) ==189102== by 0x715E428: _talloc_free_internal (talloc.c:1247) ==189102== by 0x715F78E: _talloc_free (talloc.c:1789) ==189102== by 0x569D681: memcache_delete_element (memcache.c:213) ==189102== by 0x569D73E: memcache_trim (memcache.c:228) ==189102== by 0x569DC54: memcache_do_add (memcache.c:334) ==189102== by 0x569DD7D: memcache_add_talloc (memcache.c:357) ==189102== by 0x5B2D1ED: share_mode_memcache_store (share_mode_lock.c:185) ==189102== by 0x5B2DC72: share_mode_data_destructor (share_mode_lock.c:442) ==189102== by 0x715DF81: _tc_free_internal (talloc.c:1157) ==189102== by 0x715F341: _tc_free_children_internal (talloc.c:1666) ==189102== Block was alloc'd at ==189102== at 0x4C2BB8F: malloc (vg_replace_malloc.c:299) ==189102== by 0x715D324: __talloc_with_prefix (talloc.c:782) ==189102== by 0x715D4BE: __talloc (talloc.c:824) ==189102== by 0x715D944: _talloc_named_const (talloc.c:981) ==189102== by 0x7160D9D: _talloc_zero (talloc.c:2422) ==189102== by 0x5B2DCDC: fresh_share_mode_lock (share_mode_lock.c:463) ==189102== by 0x5B2DF31: get_share_mode_lock_internal (share_mode_lock.c:519) ==189102== by 0x5B2E1EE: get_share_mode_lock (share_mode_lock.c:578) ==189102== by 0x5A5BC7E: open_file_ntcreate (open.c:3448) ==189102== by 0x5A6008F: create_file_unixpath (open.c:5298) ==189102== by 0x5A60D55: create_file_default (open.c:5706) ==189102== by 0x5BDE1E5: vfswrap_create_file (vfs_default.c:582) Patch to follow.
Created attachment 15020 [details] git-am fix for master. CI pipeline: https://gitlab.com/samba-team/devel/samba/pipelines/54322492 ---------------------------------------------- Create a separate, non-size-limited memcache cache for share modes. They must not be evicted from the cache (which they could be from the generic cache) if the cache gets full, this leads to smbd crashes. ----------------------------------------------
Note, the valgrind crash can be reproduced using the patchset from bug: https://bugzilla.samba.org/show_bug.cgi?id=13865 using the test: make test TESTS=samba3.base.rw1
Created attachment 15022 [details] git-am fix for master (v2) Minor update on previous (added if (share_mode_memcache == NULL) check in init function).
Pipeline passed.
Comment on attachment 15022 [details] git-am fix for master (v2) Withdrawing review requests. Looks like the patch in: https://bugzilla.samba.org/show_bug.cgi?id=13865 bugger up the memcache size calculations, so this isn't a bug (I don't think).
ENOTABUG. The dependent bug patch causes the problem by messing up memcache size calculations (phew, this is a relief :-). Please ignore this bug. Jeremy.