Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] genirq/debugfs: add new config option for trigger
 interrupt from userspace
To:     Marc Zyngier <maz@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org
References: <44a7007d-9624-8ac7-e0ab-fab8bdd39848@oracle.com>
 <006a08b8bfb991853ede8c9d1e29d6a7@kernel.org>
 <a4b3b41b-b0b9-03cd-c394-05d8f0bfc5f4@oracle.com>
 <bd3f06814b4319ddaaee2bf142aaf465@kernel.org>
From:   Joe Jin <joe.jin@oracle.com>
Message-ID: <84d0b879-cd4b-57c4-5ad3-57eab7694d45@oracle.com>
Date:   Fri, 28 Feb 2020 15:04:24 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <bd3f06814b4319ddaaee2bf142aaf465@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2/28/20 11:54 AM, Marc Zyngier wrote:
> On 2020-02-28 19:13, Joe Jin wrote:
>> Hi Marc,
>>
>> Thanks for your reply.
>>
>> On 2/28/20 8:37 AM, Marc Zyngier wrote:
>>> On 2020-02-28 05:42, Joe Jin wrote:
>>>> commit 536e2e34bd00 ("genirq/debugfs: Triggering of interrupts from
>>>> userspace") is allowed developer inject interrupts via irq debugfs, which
>>>> is very useful during development phase, but on a production system, this
>>>> is very dangerous, add new config option, developers can enable it as
>>>> needed instead of enabling it by default when irq debugfs is enabled.
>>>
>>> I don't really mind the patch (although it could be more elegant), but in
>>> general I object to most debugfs options being set on a production kernel.
>>> There is way too much information in most debugfs backends to be comfortable
>>> with it, and you can find things like page table dumps, for example...
>>
>> We should not enable any debug option on production system, actual customer
>> want to resize their BM or VM, cpu offline may lead system not works properly,
>> and if we knew more details of IRQ info it will be very help to identify
>> if it caused by IRQ/vectors, this is the motivation of we want to enable it
>> on production kernel.
> 
> If something doesn't work properly, then you are still debugging, AFAICT.

Yes you're right, there are various reasons to led the problem such like
bad mapping, interrupts lost, vectors used up .... irq debugfs is help to
identify which part caused the problem, and it help to save troubleshooting
time :-)

Thanks,
Joe