[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56D688FC.9020202@huawei.com>
Date: Wed, 2 Mar 2016 14:32:28 +0800
From: "majun (F)" <majun258@...wei.com>
To: Al Viro <viro@...IV.linux.org.uk>
CC: <ebiederm@...ssion.com>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<akpm@...ux-foundation.org>, <dhowells@...hat.com>,
<Waiman.Long@...com>, <dingtianhong@...wei.com>,
<guohanjun@...wei.com>, <fanjinke1@...wei.com>
Subject: Re: [PATCH] Change the spin_lock/unlock_irq interface in
proc_alloc_inum() function
在 2016/3/2 11:09, Al Viro 写道:
> On Wed, Mar 02, 2016 at 10:47:59AM +0800, MaJun wrote:
>> From: Ma Jun <majun258@...wei.com>
>>
>> The spin_lock/unlock_irq interface is not safe when this function is called
>> at some case which need irq disabled.
>
>> For example:
>> spin_lock_irqsave()
>> |
>> request_irq() --> proc_alloc_inum()
>> |
>> spin_unlock_irqrestore()
>
> Do you even read your own patch?
>
>> if (!ida_pre_get(&proc_inum_ida, GFP_KERNEL))
> ^^^^^^^^^^
> This.
>
> It can block. You *can't* call that under spin_lock_irqsave(). At all.
> You also can't do request_irq() under a spinlock, no matter whether you
> disable irqs or not - it also blocks. So does proc_mkdir(), for that
> matter, and not only in proc_alloc_inum().
>
> NAKed. Don't do it. request_irq() is not to be called under spinlocks,
> with or without irqs disabled.
>
Sorry,I made a wrong example for this problem.
I want to say this interface may change the irq status after this function
be called.
Thanks!
MaJun
> .
>
Powered by blists - more mailing lists