Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp652407imm; Thu, 31 May 2018 07:09:20 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIhac2HOv2Tv26JCi0DWBgA9kvnkkAlOQrdKkrt6wJq2iSpjFwKr9dhX/+Ms2nqxyRQHAY0 X-Received: by 2002:a65:5183:: with SMTP id h3-v6mr5591865pgq.58.1527775760474; Thu, 31 May 2018 07:09:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527775760; cv=none; d=google.com; s=arc-20160816; b=f/lEwartLeJjlnChabZs9qFjiDAm+7azdOHcqv05TG/jIDhu15oAVLbLSzkcteoTsA Zu+wtUF4SGsZi8ib8FD7izH403nCCLdIh7RCQzR7WsjlHzfVSfrZvzkGiOCUuFteXLvq w+AFrRpAiEZhUo/cQecmRiICDrf1/IyQpOlAov8OKeChhQSVas0lFD38PTvGshzeS9Nm A/jwkILalcgXLaf78dFLDGMZcZRffo0nSgtWEfc09FLdPsLeimxsOKyXCfcA87jViD0B 1G537aZPdaZPdYTDZbIg8FXLeNeLeORHmedSgQKTBvoftqAn+XOH7N1wjGyQpBPOuOzb RbwQ== 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:dkim-signature:arc-authentication-results; bh=PTABKKqKVoaz2fQqSPbkFlWbG2l7pp8v8nbSja5OKT8=; b=B/XqsX7Kp6XDWj1cwqMHizdk3BHB+I+okHX3zkjM1/X8DS+q6AEv65yJhQtmomoBui 5HCU4/1ZE4GcQ6EL3TgxmtNW7jXRd4BBMT5MYdvo1Gq8QBJNwBaOP/55F7Uz6Bn7YEnh ZX4nKqehlcuL36iXJaL82XL7Bfovwsw7mi6+YZk7x3u5w14PZc7iY/PgUVokpYy8CKl4 VAjb6y5iSwv1ZVKhc86HH5o//Ys3TJP3h2fNz7M65a8OpQT5XZE0sm+E3saUV1rBaTzq NwrcxNfNbW/K1ReS7Fn1AzwFsWc3fbVoGGuGsYT7jEKd+J7heEbdWFgT0sjphsvsGqTx rbEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=AyyqjqsE; 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 a80-v6si1542561pfg.200.2018.05.31.07.09.06; Thu, 31 May 2018 07:09:20 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=AyyqjqsE; 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 S1755358AbeEaOIQ (ORCPT + 99 others); Thu, 31 May 2018 10:08:16 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:50442 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755093AbeEaOIN (ORCPT ); Thu, 31 May 2018 10:08:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PTABKKqKVoaz2fQqSPbkFlWbG2l7pp8v8nbSja5OKT8=; b=AyyqjqsEWNeI1a2EWFGtKWEI8 ueVSXHgoOhG7e/FUkbCj+TS387XU/kAMLaVf3HFMBNGfTny2lUENJ36NeIIXef8h8Bi7+YPyP2ECQ SGRsLgG+WVz/P4acj6QtkqtkVbMZNIhU45FxEoYcNKC0SFEHgEMN24BeNZTeyYAls0kqjkGGLFHO1 39Mx+oCeqifr85ZLNSDX/YYqlk/VLyKcf+sDDM3T9HvZfoF6jIEzhfE23LVucoQXnHBht1b1J0TMn N0dnha1AbOuMTY7CNhCzgKIflFIXjlAABav8wf88WS+m5We21URsdNYQD7yuQH5qflOG9aG+P1hL3 i6VR7jfew==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1fOOFM-0004Q2-La; Thu, 31 May 2018 14:08:08 +0000 Date: Thu, 31 May 2018 07:08:08 -0700 From: Matthew Wilcox To: Jia-Ju Bai Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-mm@kvack.org, Linux Kernel Mailing List Subject: Re: Can kfree() sleep at runtime? Message-ID: <20180531140808.GA30221@bombadil.infradead.org> References: <30ecafd7-ed61-907b-f924-77fc37dcc753@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30ecafd7-ed61-907b-f924-77fc37dcc753@gmail.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote: > I write a static analysis tool (DSAC), and it finds that kfree() can sleep. > > Here is the call path for kfree(). > Please look at it *from the bottom up*. > > [FUNC] alloc_pages(GFP_KERNEL) > arch/x86/mm/pageattr.c, 756: alloc_pages in split_large_page > arch/x86/mm/pageattr.c, 1283: split_large_page in __change_page_attr Here's your bug. Coming from kfree(), we can't end up in the split_large_page() path. __change_page_attr may be called in several different circumstances in which it would have to split a large page, but the path from kfree() is not one of them. I think the path from kfree() will lead to the 'level == PG_LEVEL_4K' path, but I'm not really familiar with this x86 code. > arch/x86/mm/pageattr.c, 1391: __change_page_attr in > __change_page_attr_set_clr > arch/x86/mm/pageattr.c, 2014: __change_page_attr_set_clr in __set_pages_np > arch/x86/mm/pageattr.c, 2034: __set_pages_np in __kernel_map_pages > ./include/linux/mm.h, 2488: __kernel_map_pages in kernel_map_pages > mm/page_alloc.c, 1074: kernel_map_pages in free_pages_prepare > mm/page_alloc.c, 1264: free_pages_prepare in __free_pages_ok > mm/page_alloc.c, 4312: __free_pages_ok in __free_pages > mm/slub.c, 3914: __free_pages in kfree > > I always have an impression that kfree() never sleeps, so I feel confused > here. > So could someone please help me to find the mistake? > Thanks in advance :) > > Best wishes, > Jia-Ju Bai