From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F879C77B6F for ; Wed, 12 Apr 2023 00:15:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 956B3900002; Tue, 11 Apr 2023 20:15:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DFCE6B0075; Tue, 11 Apr 2023 20:15:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78445900002; Tue, 11 Apr 2023 20:15:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6315B6B0074 for ; Tue, 11 Apr 2023 20:15:42 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3BFEE16038F for ; Wed, 12 Apr 2023 00:15:42 +0000 (UTC) X-FDA: 80670820524.24.7FE8FF4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 583F514000B for ; Wed, 12 Apr 2023 00:15:39 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kPrR+RF5; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681258539; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4WsSWnY2kqFX61IYIBf6y0a4nF49VBg8vofZJ1+DUXw=; b=WplaCl3bLE0Zc6jL3WxEXb0A798SbSASRXLUF0QySIDdeAk5Mts4LNc4FU7Ylk9G4+BOo4 YfbRLVHYlF+vBU7iAhVtjEIXkPepwQ7AHKLsKWfIdvgK1vR52Z7h2JbtrlsZyOYBvYEK4L ePx+AOeuozuus5dJ1ODEGzC+/mLx1Zo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kPrR+RF5; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681258539; a=rsa-sha256; cv=none; b=2aIolam9MM18rX+Y5blLefZfJR5PW/yjQ/wBET8GpZCFplx7yLW04OhbNSlj11uQBU8mac 5R2eUIRvslRbZXRX0x7O2J21+nQ+nE3n+BRhnFw4nM+xq7LG7zQbbS6Y5oSRL8W+km2+20 AY4LeOXGJE2/1Gbu6dMQX0CkaBjz4z0= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 519A460F53; Wed, 12 Apr 2023 00:15:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 752C0C433EF; Wed, 12 Apr 2023 00:15:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1681258537; bh=+4+26YeShVOy7ToR1aCgF4tHlAF/edewLYy1hsvDreo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kPrR+RF5l0d0OtWpJ2ln+3K16rNYnnm9appIm0pPLkOrKrtPpX7uY9XtzB4q36I0w 9MUqIW/lhNIWqUu9X7f3GRzjNW9J0kADvH4gj3/q6g1AZt0KIOIsFfkn7OhLifbzTX thgoN+JVF7F6bcsWpbTmT+CTZ6NahIcSOXkrkVPw= Date: Tue, 11 Apr 2023 17:15:36 -0700 From: Andrew Morton To: Matthew Wilcox Cc: "xiaosong.ma" , Alexander Viro , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , yuming.han@unisoc.com, ke.wang@unisoc.com Subject: Re: [PATCH V2] fs: perform the check when page without mapping but page->mapping contains junk or random bitscribble Message-Id: <20230411171536.2e53b4b7507304d5618aa24e@linux-foundation.org> In-Reply-To: References: <1681091102-31907-1-git-send-email-Xiaosong.Ma@unisoc.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 583F514000B X-Stat-Signature: kqw8x3rz75w13x38fbthz647opk89bzm X-HE-Tag: 1681258539-554471 X-HE-Meta: U2FsdGVkX1+MC9NLnwOvNyLlmiRfEV1m5WQJK2w8WOjKvyfNCOMcj7Mk8RnRw/sK4O0i/u18Su0FJ88cg7qFxD8kof7Qv9DPCC6dtqACXmdoPSBtABflhosDLphErR02AcY36n1zt9mtzjnNbA0CXip78K8cUqVufTb3Mv28XlZoB0NZxbKl7nI7scMgNznyeEZtI3favjrgY1qKt99Y6Wcqh100oyPqIRJyL2X6c2J6ptBzq8X1bboVL5mNCxEQ292yCfQgCmSQA+YRtlvr375GbkyU1qBAxmlaOenb4LOu+uW9q9vyipsTC5ju2AmZOkNIFD6o+vnHP4AR4mLwOKjDmrYqVYq1ysbdnhANzMWQ21EzfSpK9t36vHDRNZaoD9e7YjlmW5Wj/5J06Yy7rNAHyJQOdYsGwhr5I7QFHbppZqGt6Kng4O2ZrK2C6OoqaKFY/o20IzMelqrwMwqixjO+H1h0zsu4VscmjstscWO/KAogVu7jDBGI6EO+BkTz/ragRbUlXFscuUms2T/KA7QQkhHi7/ij7PW3iHuwfcYVI7J71VfpGwZUvTj5tRKFzPbQOKuhYn92lvVBaoTJ8nhycDvI2c7dfF58Xw634ZI5eIr2C5s8byySr+5yObQA0B7jQpIpR991gIoixlUFtmmfNz0brV4vuVtpR0jFZxftkgyiS9GlazR+XxgepaDj58SdZJTURhDxRnAvRqkA89sv5wVjPJFbYEEDp2pbKJz0HLBjmNKbdQ7YAWckA+8Pq9TeQLNRKkTmXReFVjOTG7hUaN+5iUsGly5bhQkYPUnWxUt2o1Epjach37KASjV2UYZLXeMrP/8P5+lHm+oHV/cG9//Koo6yOFIlMwjAdAKvogM3ZfKlJTU+ta7Q9RiXc18gijnYZWGYoLLb4zDTNVYMPwyxA0wEEDuQ+hHrjykEEeUwLULeYaV6oUsBHJITm0T1ITRkOCMjWj+KQOU m+wl8/cO 9nG++OSHXzPmqxY9gX/5Af4uDQrnrjGGNfAdL5zhqZ4K3FHxlLbrXbKUYkUbSmEpA/5sxRlyQ57P01e8F0X/XoFUygtdniJog+X2FrjdITNLHfoCyEYEyE3yFQqXrFjbbrfIgqbZxs2Pm++VfE9/m9IgZYTIzQothxfifngSAfjcTLgdD5/DrAn+yUAUvf3LJIpnBrJ1aCqaDu2rKBI0NeezGv7MPOiX68cJAn6DLVbkqoXt4qmW1YFcj5MHkFwob3rVld4Z6grerMXO+9Z0VAC9bXSmDjlfcV6Eg5LaqxDdwPa/pPzw3XqBjEFgJdSAL5ki74zAAqL2LakQcEE0IucjE9vxvImjL3No2WFlf7936Ek2IGe628ybtc01ps1heHnzQFMKEOPBrZwauIc77/fafxeXiLsVfvc97Tn9AD8ishBHkPUpE6S4dI1IJHlwmv1riTZD1KrFws5wMA55+emmbLLHGPYIicLfH2L0Wz7PdV1E8+dsjBkfqlFlkTTi7dKRhybqlRb4YATk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 11 Apr 2023 13:16:18 +0100 Matthew Wilcox wrote: > On Mon, Apr 10, 2023 at 09:45:02AM +0800, xiaosong.ma wrote: > > perform the check in dump_mapping() to print warning info and avoid crash with invalid non-NULL page->mapping. > > For example, a panic with following backtraces show dump_page will show wrong info and panic when the bad page > > is non-NULL mapping and page->mapping is 0x80000000000. > > > > crash_arm64> bt > > PID: 232 TASK: ffffff80e8c2c340 CPU: 0 COMMAND: "Binder:232_2" > > #0 [ffffffc013e5b080] sysdump_panic_event$b2bce43a479f4f7762201bfee02d7889 at ffffffc0108d7c2c > > #1 [ffffffc013e5b0c0] atomic_notifier_call_chain at ffffffc010300228 > > #2 [ffffffc013e5b2c0] panic at ffffffc0102c926c > > #3 [ffffffc013e5b370] die at ffffffc010267670 > > #4 [ffffffc013e5b3a0] die_kernel_fault at ffffffc0102808a4 > > #5 [ffffffc013e5b3d0] __do_kernel_fault at ffffffc010280820 > > #6 [ffffffc013e5b410] do_bad_area at ffffffc01028059c > > #7 [ffffffc013e5b440] do_translation_fault$4df5decbea5d08a63349aa36f07426b2 at ffffffc0111149c8 > > #8 [ffffffc013e5b470] do_mem_abort at ffffffc0100a4488 > > #9 [ffffffc013e5b5e0] el1_ia at ffffffc0100a6c00 > > #10 [ffffffc013e5b5f0] __dump_page at ffffffc0104beecc > > This doesn't show a crash in dump_mapping(), it shows a crash in > __dump_page(). um, yes. But if page->mapping is corrupted, where does __dump_page() dereference it? The initial patch (https://lkml.kernel.org/r/1680587425-4683-1-git-send-email-Xiaosong.Ma@unisoc.com) prevented __dump_page() from calling dump_mapping() if page->mapping is bad, and that presumably fixed things. > > diff --git a/fs/inode.c b/fs/inode.c > > index f453eb5..c9021e5 100644 > > --- a/fs/inode.c > > +++ b/fs/inode.c > > @@ -564,7 +564,8 @@ void dump_mapping(const struct address_space *mapping) > > * If mapping is an invalid pointer, we don't want to crash > > * accessing it, so probe everything depending on it carefully. > > */ > > - if (get_kernel_nofault(host, &mapping->host) || > > + if (get_kernel_nofault(mapping, &mapping) || > > + get_kernel_nofault(host, &mapping->host) || > > This patch makes no sense. Essentially, you're saying > mapping = &mapping > which is obviously wrong. We're checking for mapping==junk, so this could be get_kernel_nofault(tmp, mapping) or go direct to copy_from_kernel_nofault(). We used to have a probe_kernel_address() for this... So confusion reigns. I think making dump_mapping() tolerant of a wild mapping pointer makes sense, but I don't think we actually know why the reporter's kernel crashed.