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: [BUG] kernel: kcov: a possible sleep-in-atomic-context bug in
 kcov_ioctl()
To:     Al Viro <viro@ZenIV.linux.org.uk>
Cc:     akpm@linux-foundation.org, dvyukov@google.com,
        Greg KH <gregkh@linuxfoundation.org>, tchibo@google.com,
        aryabinin@virtuozzo.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <ca2e4f0b-dd08-8d66-51e3-05cc69e15d65@gmail.com>
 <20180621034335.GT30522@ZenIV.linux.org.uk>
From:   Jia-Ju Bai <baijiaju1990@gmail.com>
Message-ID: <3dc2431d-e474-a3b6-c6c9-9f7079a9cb9b@gmail.com>
Date:   Thu, 21 Jun 2018 11:50:54 +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: <20180621034335.GT30522@ZenIV.linux.org.uk>
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/6/21 11:43, Al Viro wrote:
> On Thu, Jun 21, 2018 at 11:20:59AM +0800, Jia-Ju Bai wrote:
>> The kernel may sleep with holding a spinlock.
>> The function call path (from bottom to top) in Linux-4.16.7 is:
>>
>> [FUNC] vfree --> can sleep
>> kernel/kcov.c, 237: vfree in kcov_put
>> kernel/kcov.c, 396: kcov_put in kcov_ioctl_locked
>> kernel/kcov.c, 410: kcov_ioctl_locked in kcov_ioctl
>> kernel/kcov.c, 409: spin_lock in kcov_ioctl
>>
>> This bug is found by my static analysis tool (DSAC-2) and checked by my
>> code review.
>>
>> I do not know how to correctly fix this bug, so I just report them.
> Assuming it's a bug in the first place, that is.  Note that
> 	* we never modify task->kcov for task != current
> 	* task->kcov contributes to refcount
> 	* opened file contributes to refcount
> 	* that kcov_put() of yours happens from ->ioctl() and removes
> current->kcov reference; it *can't* be the last reference - the one
> held by struct file used to call ->ioctl() is also there.
>
> IOW, it's a false positive.

Okay, thanks for your reply and explanation.
I agree that my report is false.


Best wishes,
Jia-Ju Bai