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] isdn: mISDN: tei: Fix a sleep-in-atomic-context bug in
 create_teimgr()
To:     isdn@linux-pingi.de
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20180901120019.31664-1-baijiaju1990@gmail.com>
 <3ecd32b2-81e5-038e-edc9-fd06d6e21851@linux-pingi.de>
From:   Jia-Ju Bai <baijiaju1990@gmail.com>
Message-ID: <c7562383-8255-31f4-8f91-057011172b65@gmail.com>
Date:   Mon, 3 Sep 2018 09:40:10 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <3ecd32b2-81e5-038e-edc9-fd06d6e21851@linux-pingi.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2018/9/3 0:31, isdn@linux-pingi.de wrote:
> Hi,
>
> I do not understand the analysis and do not see that the spinlock is a
> problem here.
> I think your DSAC analyzer assumes that the FUNC_PTR mgr_ctrl call calls
> the  mgr_ctrl in tei.c, but in real it calls l2->ch.ctrl() which is the
> function in layer2.c, not tei.c. And the function in layer2.c should not
> do any GFP_KERNEL allocation.
>
> Same for your 2. reported issue.

Okay, thanks for your reply.
My analysis handles the function pointer using the function type and 
structure field, but it cannot distinguish the different variables of 
the same type and field now.
I will try to improve my tool, thanks for your explanation.


Best wishes,
Jia-Ju Bai