Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1106652imu; Fri, 25 Jan 2019 17:57:26 -0800 (PST) X-Google-Smtp-Source: ALg8bN5LkrkAREJJneGl2d8mH8F4GhCep+m7dZc3iwGneD6/MA1CzzBnxwOZt7okSs37jgLtkkld X-Received: by 2002:a62:ca03:: with SMTP id n3mr13738609pfg.241.1548467846017; Fri, 25 Jan 2019 17:57:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548467845; cv=none; d=google.com; s=arc-20160816; b=wyfC9e4NxF8smLq0dgUVYZnZeeT7h3LcyhcmV2oZc70K5wWTuCrcfXQmuQ5lnWT3ts MpP2YcqCH4TvWRiVY11+7FmYwhjJDSFIrxINHQ5dU1VCSxJvX1VYZvyugNfMW2zE+tBo 3Bt84GDLHIjgRVk9JQfGRKkBS4qLVSqYzDUPmq0gdlr8QVVnklp4F3yxaPcYhml/0vR4 Ax9TRMtfpk+A4P3g8LJGf1j6JUo8Taq/dcl9fjdK5kvDb1w8jiyrtArSBS825YDM8boU fx4Q7Gd4iVtyERA3vzUkRBdVfCCW+2Yyc14W/QCDw4XsUAWAhhaH50VQb7SnaR9uUFh2 SKAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=vCQigGJo5Mn6zVHWDFJ7kjPYzxP/O+aT6X8KSRh95JY=; b=zYQnyGgHUiXkANkhmQmUekfhBbvX2hsbpW5PuKu/0YxSelau2A8fA3mEqDC0yg4hTv IV2DC+pt/QXNpDAo4XYyF6ydpeYayeDhG41xF33eRwrucd3DLwtTlJa4XRbKsvvcopaI PiH87fwzVGA+l4KLGs+lmbWVs5H3BDQHJl3jUUeUX4lYdwVSTssXaNG6RHrn3slCfspZ 1shTYFXxhxuOkdki2JwRuXi1CoN3JR1c4YEKn6udRfYW5+2LG0yPMuATC2wzWVfy5a6q u7un0K2V0OdkdbDphTedfxedj/NcYDzRVyO8FumkEF7WvXFeYyLNiiylfP7Jqpi3tcgk DofQ== 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 m15si25987367pgc.381.2019.01.25.17.57.10; Fri, 25 Jan 2019 17:57:25 -0800 (PST) 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 S1726863AbfAZB5F (ORCPT + 99 others); Fri, 25 Jan 2019 20:57:05 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:52693 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbfAZB5E (ORCPT ); Fri, 25 Jan 2019 20:57:04 -0500 Received: from fsav107.sakura.ne.jp (fsav107.sakura.ne.jp [27.133.134.234]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id x0Q1v3dZ074969; Sat, 26 Jan 2019 10:57:03 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav107.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav107.sakura.ne.jp); Sat, 26 Jan 2019 10:57:03 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav107.sakura.ne.jp) Received: from [192.168.1.8] (softbank126126163036.bbtec.net [126.126.163.36]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id x0Q1v3aU074964 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2019 10:57:03 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: possible deadlock in __do_page_fault To: Joel Fernandes Cc: Andrew Morton , Todd Kjos , syzbot+a76129f18c89f3e2ddd4@syzkaller.appspotmail.com, ak@linux.intel.com, Johannes Weiner , jack@suse.cz, jrdr.linux@gmail.com, LKML , linux-mm@kvack.org, mawilcox@microsoft.com, mgorman@techsingularity.net, syzkaller-bugs@googlegroups.com, =?UTF-8?Q?Arve_Hj=c3=b8nnev=c3=a5g?= , Todd Kjos , Martijn Coenen , Greg Kroah-Hartman References: <201901230201.x0N214eq043832@www262.sakura.ne.jp> <20190123155751.GA168927@google.com> <201901240152.x0O1qUUU069046@www262.sakura.ne.jp> <20190124134646.GA53008@google.com> From: Tetsuo Handa Message-ID: <06b4806c-6b53-85a5-84db-fa432ea4ccd0@i-love.sakura.ne.jp> Date: Sat, 26 Jan 2019 10:57:03 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190124134646.GA53008@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/01/24 22:46, Joel Fernandes wrote: > On Thu, Jan 24, 2019 at 10:52:30AM +0900, Tetsuo Handa wrote: >> Then, I'm tempted to eliminate shrinker and LRU list (like a draft patch shown >> below). I think this is not equivalent to current code because this shrinks >> upon only range_alloc() time and I don't know whether it is OK to temporarily >> release ashmem_mutex during range_alloc() at "Case #4" of ashmem_pin(), but >> can't we go this direction? > > No, the point of the shrinker is to do a lazy free. We cannot free things > during unpin since it can be pinned again and we need to find that range by > going through the list. We also cannot get rid of any lists. Since if > something is re-pinned, we need to find it and find out if it was purged. We > also need the list for knowing what was unpinned so the shrinker works. > > By the way, all this may be going away quite soon (the whole driver) as I > said, so just give it a little bit of time. > > I am happy to fix it soon if that's not the case (which I should know soon - > like a couple of weeks) but I'd like to hold off till then. > >> By the way, why not to check range_alloc() failure before calling range_shrink() ? > > That would be a nice thing to do. Send a patch? OK. Here is a patch. I chose __GFP_NOFAIL rather than adding error handling, for small GFP_KERNEL allocation won't fail unless current thread was killed by the OOM killer or memory allocation fault injection forces it fail, and range_alloc() will not be called for multiple times from one syscall. But note that doing GFP_KERNEL allocation with ashmem_mutex held has a risk of needlessly invoking the OOM killer because "the point of the shrinker is to do a lazy free" counts on ashmem_mutex not held by GFP_KERNEL allocating thread. Although other shrinkers likely make forward progress by releasing memory, technically you should avoid doing GFP_KERNEL allocation with ashmem_mutex held if shrinker depends on ashmem_mutex not held. From e1c4a9b53b0bb11a0743a8f861915c043deb616d Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sat, 26 Jan 2019 10:52:39 +0900 Subject: [PATCH] staging: android: ashmem: Don't allow range_alloc() to fail. ashmem_pin() is calling range_shrink() without checking whether range_alloc() succeeded. Since memory allocation fault injection might force range_alloc() to fail while range_alloc() is called for only once for one ioctl() request, make range_alloc() not to fail. Signed-off-by: Tetsuo Handa --- drivers/staging/android/ashmem.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index d40c1d2..a8070a2 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -171,18 +171,14 @@ static inline void lru_del(struct ashmem_range *range) * @end: The ending page (inclusive) * * This function is protected by ashmem_mutex. - * - * Return: 0 if successful, or -ENOMEM if there is an error */ -static int range_alloc(struct ashmem_area *asma, - struct ashmem_range *prev_range, unsigned int purged, - size_t start, size_t end) +static void range_alloc(struct ashmem_area *asma, + struct ashmem_range *prev_range, unsigned int purged, + size_t start, size_t end) { struct ashmem_range *range; - range = kmem_cache_zalloc(ashmem_range_cachep, GFP_KERNEL); - if (!range) - return -ENOMEM; + range = kmem_cache_zalloc(ashmem_range_cachep, GFP_KERNEL | __GFP_NOFAIL); range->asma = asma; range->pgstart = start; @@ -193,8 +189,6 @@ static int range_alloc(struct ashmem_area *asma, if (range_on_lru(range)) lru_add(range); - - return 0; } /** @@ -687,7 +681,8 @@ static int ashmem_unpin(struct ashmem_area *asma, size_t pgstart, size_t pgend) } } - return range_alloc(asma, range, purged, pgstart, pgend); + range_alloc(asma, range, purged, pgstart, pgend); + return 0; } /* -- 1.8.3.1