On Sat, Aug 29, 2015 at 12:43:03AM +0200, Thomas Graf wrote: > On 08/28/15 at 03:34pm, Phil Sutter wrote: > > Quite ugly, IMHO: rhashtable_insert_fast() may return -ENOMEM as > > non-permanent error, if allocation in GFP_ATOMIC failed. In this case, > > allocation in GFP_KERNEL is retried by rht_deferred_worker(). Sadly, > > there is no way to determine if that has already been tried and failed. > > > > The thread test triggers GFP_ATOMIC allocation failure quite easily, so > > I can't really just ignore this issue. :) > > Return EBUSY or ENOBUFS in the non-permanent case? It is definitely > helpful if the API allows to differ between permanent and > non-permanent errors.
Yes, indeed. Therefore rht_deferred_worker() needs to check the return value of rhashtable_expand(). The question is how to propagate the error condition, as the worker's return value is not being kept track of (function returns void even). Should we introduce a new field to struct rhashtable to track the internal state? This might allow to clean up some rather obscure tests, e.g. whether a table resize is in progress or not. Cheers, Phil -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
