Re: [POC] recoverable fault injection

[Akinobu Mita <akinobu.mita@gmail.com>]

2012/11/22 Johannes Berg <johannes@sipsolutions.net>:

> 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));