Re: [PREVIEW] Avoid memory corruption and segfaults during ufs cache store maintenance

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 25 Jul 2012 21:36:53 -0600

On 07/25/2012 09:17 PM, Amos Jeffries wrote:
> On 26.07.2012 12:33, Alex Rousskov wrote:
>> Hello,
>>
>> The attached patch avoids memory corruption and segfaults during ufs
>> cache store maintenance by removing being-deleted StoreEntry from ufs
>> cache replacement policies.
>>
>> SMP Store changes added a SwapDir::disconnect() method that notified
>> entry's cache_dir that its entry is being destroyed. I added that code
>> so that shared cache_dirs can update their index when idle store_table
>> entries are destroyed on cleanup (completely avoiding idle entries
>> proved to be too difficult with store_table still around).
>>
>> However, I did not realize that non-shared cache_dirs have the same
>> problem: Their StoreEntries may be deleted without cache_dirs knowing
>> that. UFS cache_dir now implement the SwapDir::disconnect() API to stay
>> in sync. It is likely that the problem was introduced by SMP Store
>> changes, but I do not know whether there is a better fix for it.
>>
>> I also added assertions to catch cases where a dirty StoreEntry or
>> MemObject (i.e., an entry or object that is still in some replacement
>> policy index) is being destroyed.
>>
>>
>> TODO: This patch breaks "make check". We need more STUBs somewhere!
>>
>>
>> Alex.
>
>
> I've been thinking for some time that we need to implement a list of
> being-deleted entries in each cache and add a unlinkd response handler
> to erase them from that list after actual deletion which unregisters the
> fileno for re-use.

Yes, something like that would help ufs caches to better track their
stuff. Not sure this is worth spending the time on though because ufs
has so many other inefficiencies. And premature StoreEntry deletion will
only complicate implementing that unlink tracking.

Cheers,

Alex.
Received on Thu Jul 26 2012 - 03:36:56 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 26 2012 - 12:00:03 MDT