Re: [Qemu-devel] [PATCH v12 16/17] blkdebug: fix "once" rule

[John Snow <jsnow@redhat.com>]

On 02/11/2015 04:50 PM, Max Reitz wrote:
> On 2015-02-09 at 20:35, John Snow wrote:
>> Background:
>>    The blkdebug scripts are currently engineered so that when a debug
>> event occurs, a prefilter browses a master list of parsed rules for a
>> certain event and adds them to an "active list" of rules to be used for
>> the forthcoming action, provided the events and state numbers match.
>>
>>    Then, once the request is received, the last active rule is used to
>> inject an error if certain parameters match.
>>
>>    This active list is cleared every time the prefilter injects a new
>> rule for the first time during a debug event.
>>
>>    The "once" rule currently causes the error injection, if it is
>> triggered, to only clear the active list. This is insufficient for
>> preventing future injections of the same rule.
>>
>> Remedy:
>>    This patch /deletes/ the rule from the list that the prefilter
>> browses, so it is gone for good. In V2, we remove only the rule of
>> interest from the active list instead of allowing the "once" rule to
>> clear the entire list of active rules.
>>
>> Impact:
>>    This affects iotests 026. Several ENOSPC tests that used "once" can
>> be seen to have output that shows multiple failure messages. After
>> this patch, the error messages tend to be smaller and less severe, but
>> the injection can still be seen to be working. I have patched the
>> expected output to expect the smaller error messages.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>> ---
>>   block/blkdebug.c           |  6 ++++--
>>   tests/qemu-iotests/026.out | 24 ++++--------------------
>>   2 files changed, 8 insertions(+), 22 deletions(-)
>
> Well, I think this shouldn't be part of this series, but you can find my
> R-b here:
> http://lists.nongnu.org/archive/html/qemu-devel/2015-02/msg01209.html
>
> Max

I will need to do a version bump to address patches 7-9, fix error 
messages, and other house-cleaning issues.

I can just put in the cover letter that this series *depends* on that 
other patch.

Otherwise, this series can be merged up to this patch before it's 
actually needed and it won't have any ill effect.

--js