Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1516407imm; Wed, 20 Jun 2018 20:44:36 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLda5Mda6PNkHCofsa80T96NZtIsyrXhPuwUGa7RsDBmCr6EIE52soRYke7z9mu/9ajtrPt X-Received: by 2002:a63:6fce:: with SMTP id k197-v6mr21124789pgc.307.1529552676210; Wed, 20 Jun 2018 20:44:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529552676; cv=none; d=google.com; s=arc-20160816; b=Ts0V0Yoqi9N6tFRgbVfKeM9W/7bioixxmQMwdbrxi1IFkjjShwGTBZf8hR+bBZaFq5 zPdio/Bc+uxUPt+WyycqFMVAbBDiLcGt2i4fJuff0ReKlw+0l38psB205TGWsiYJUq0Z yAUutdmNFZeXBa/oZ8Kwv62D9asYEOEjcY+R866CuLTMDIWaRy6pFZUKJKP8VUaHi9VI s3sRz/ZTDuoDrgDfCuJ2IPnGLOoBGsBApxkeZk9C1LOxiN48LagBDON/oMYCHx7CfYTs ghe8qE9MYlL9GX/I+AP/MF1A3mJ6akPVwQClk+PZ0FwDFhJDIkMVegCc3zzQj/2x/2+i vluQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=zh1RdFz8NR+6JRJmMEIZO25oauv6UcDJ7F0dyv7G3RU=; b=E8hg+ykA6ViV1c6UUyeMMHVH0u5F79vIA+WUuAisHv//Pjt1gv9AW3qX7o6Yi/TOC2 lQ5+0KA7T0bN6MqAKsEMkls5CkyqfW7/GY9dYZqaJdlQfae7ITuU+wzAR9jwQjnewTiX kgqrFZSkDCgddKEl6HmrF0uJqyj2MpLyZO9tUU2b41P50LfourdPfPBljZd8a4l0nMph /I1Eg1xO+3xABLN4XTMUu0NVavqEU9loL5dnoY1zxdORHWMsmcOr6QcslA8X6XEmXatL gE0zPLLbil4+RduDiSwisNhCRndcskNJXwv/NFP9gFYH2LqSzXmpBy46a3Vbm0zPoQT0 fp3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si3683176plk.191.2018.06.20.20.44.21; Wed, 20 Jun 2018 20:44:36 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754304AbeFUDnn (ORCPT + 99 others); Wed, 20 Jun 2018 23:43:43 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:48370 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754207AbeFUDnm (ORCPT ); Wed, 20 Jun 2018 23:43:42 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fVqVU-0000gn-1A; Thu, 21 Jun 2018 03:43:36 +0000 Date: Thu, 21 Jun 2018 04:43:36 +0100 From: Al Viro To: Jia-Ju Bai Cc: akpm@linux-foundation.org, dvyukov@google.com, Greg KH , tchibo@google.com, aryabinin@virtuozzo.com, Linux Kernel Mailing List Subject: Re: [BUG] kernel: kcov: a possible sleep-in-atomic-context bug in kcov_ioctl() Message-ID: <20180621034335.GT30522@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.