2012/11/22 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>:
> I thought about something like that, I actually initially played with
> macros like this:
>
> #define FAULT_RECOVERABLE_START(ids) \
> /* set up the task state */ \
> fault_recovery_retry:
>
> #define FAULT_RECOVERABLE_END(ids) \
> if (current->encountered_fault) \
> goto fault_recovery_retry;
>
> or so. However, the problem is that if you exit the function between
> these points, and this is true for your functions as well, you leave the
> task's fault injection enabled which isn't what you want. So adding
> functions or macros like this didn't really seem right. Also, functions
> (rather than macros) have the problem that the retry can't be
> encapsulated -- note how my macro calls the function again if it failed.
> So with functions like that, you introduce new manually-coded error and
> retry paths, that seemed undesirable.
>
> As you can see in my macro, it's also possible for an allocation to fail
> but the function to succeed, so the function that is called must have a
> return value indicating success or failure. I ran into this with debug
> objects, their allocation failed all the time but obviously the function
> succeeded as debug objects fail gracefully if they can't allocate
> memory.
Oh, I completely missed retrying part in your macro.
I looked into FAULT_INJECT_CALL_RECOVERABLE_FUNCTION again,
then I realized that it is not necessary to be variadic macro.
You can define macro like wait_event() family and use it like below:
return FAULT_INJECT_CALL_RECOVERABLE_FUNCTION(
BIT(FAULT_ATTR_SLAB) | BIT(FAULT_ATTR_PAGE_ALLOC),
_nl80211_remain_on_channel(skb, info));
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
