linux-kernel - Re: [POC] recoverable fault injection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAC5umyj07UmPtoFowqquoOBERaVa4KngJ=cOa8_AgkcJ_EksSw@mail.gmail.com>
Date:	Thu, 22 Nov 2012 22:29:42 +0900
From:	Akinobu Mita <akinobu.mita@...il.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: [POC] recoverable fault injection

2012/11/22 Johannes Berg <johannes@...solutions.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));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/