Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755226AbdC1Xl3 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 28 Mar 2017 19:41:29 -0400
Received: from mail-pg0-f65.google.com ([74.125.83.65]:36380 "EHLO
        mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753312AbdC1Xl2 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 28 Mar 2017 19:41:28 -0400
MIME-Version: 1.0
In-Reply-To: <20170328130128.101773-1-dvyukov@google.com>
References: <20170328130128.101773-1-dvyukov@google.com>
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Wed, 29 Mar 2017 08:41:06 +0900
Message-ID: <CAC5umyhYbez6bpM0QnS3icuRCq2g-=0Yf-pj4+kxedmrp6hnwA@mail.gmail.com>
Subject: Re: [PATCH v2] fault-inject: support systematic fault injection
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1145
Lines: 23

2017-03-28 22:01 GMT+09:00 Dmitry Vyukov <dvyukov@google.com>:
> Add /proc/self/task/<current-tid>/fail-nth file that allows failing
> 0-th, 1-st, 2-nd and so on calls systematically.
> Excerpt from the added documentation:
>
> ===
> Write to this file of integer N makes N-th call in the current task fail
> (N is 0-based). Read from this file returns a single char 'Y' or 'N'
> that says if the fault setup with a previous write to this file was
> injected or not, and disables the fault if it wasn't yet injected.
> Note that this file enables all types of faults (slab, futex, etc).
> This setting takes precedence over all other generic settings like
> probability, interval, times, etc. But per-capability settings
> (e.g. fail_futex/ignore-private) take precedence over it.
> This feature is intended for systematic testing of faults in a single
> system call. See an example below.
> ===

This asymmetric read/write interface looks a bit odd. (write a string
representation of integer, but read Y or N).

How about just return the string representation of task->fail_nth for
read and let the user space tools check if it is zero or not?