On Tue, Feb 05, 2019 at 09:57:02AM -0800, Christoph Hellwig wrote: > On Tue, Feb 05, 2019 at 09:53:09AM -0800, Darrick J. Wong wrote: > > Good point, we could be much more resilient to backref cache failures > > since we do have the option of doing it the slow way. > > I don't think there is any failure that can happen during normal > operation as long as we use KM_SLEEP.. I dug even deeper into the rhashtable code it looks like it can fail a GFP_ATOMIC allocation for new buckets, which will bubble ENOMEM up to the caller, so Brian's right that we have to handle various errors, and should do so in a manner that doesn't kill the filesystem. Seeing as it's a backref cache and not critical to correct operation, I think I can change add_backref to ignore errors other than EEXIST (because having duplicate entries is a sign that we've screwed something up). change_backref can absorb all the error codes, though it'll have to handle the case that lookup_fast returns ENOENT. --D
