From patchwork Thu Nov 22 19:54:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sasha Levin X-Patchwork-Id: 10694779 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 515CF1709 for ; Thu, 22 Nov 2018 19:56:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3F7F62B010 for ; Thu, 22 Nov 2018 19:56:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2FBC02B136; Thu, 22 Nov 2018 19:56:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 79EAB2B010 for ; Thu, 22 Nov 2018 19:56:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75A4C6B2CF8; Thu, 22 Nov 2018 14:56:22 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 709566B2CF9; Thu, 22 Nov 2018 14:56:22 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F9E16B2CFA; Thu, 22 Nov 2018 14:56:22 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by kanga.kvack.org (Postfix) with ESMTP id 1E6096B2CF8 for ; Thu, 22 Nov 2018 14:56:22 -0500 (EST) Received: by mail-pg1-f200.google.com with SMTP id l131so3057426pga.2 for ; Thu, 22 Nov 2018 11:56:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:from:to:cc:subject:date :message-id:in-reply-to:references; bh=HJQM6B1JeeKuxQG1shlJz1zUHOF3lDSR6SD7TN4qYbg=; b=M+G3wnyRQxecOJpd6R/bG0goWwj7UGGJID73+4DakESC+FetERm7p1CfQ4Lf88ot6F IG5ehipmrvKuHHWizbDjo0xlFNofuTzOxIooFOo3qZEVzOZyB5Bnms3QDxgWbNRBfqwq tjist4YabXh5Yq4dQdNZG3+NAQDT3vLKgCsUTddGxCk/AauUiANog9JQMohP0BQjxFli tGpcd0Upo/r173ekFD6kOSc+etwl5jg0/gguIzlSiXBPowgOxqJiIJFaGcAwBqhIMf5f 1Y9QDq1XtsG1fCYZv3+diw9tS4p1NG4Itio3V/Nm/4voDYOOjFGfPNtkEw5IjU6quEGh m0PQ== X-Gm-Message-State: AA+aEWYWNvWDjU4wkz8kTU686sUZKokSdWakRQhGML8KBsnKNpMA5cJ7 xGe033zVNE1DIhPTe2VAS1xZTZKEFQNkE4sYN//rO6wyGgqdW9VrxHKbSHXXAfnWagVGsh45oLF 1BnYg3FIowDmQ+lCBJHrXJqVyTxEjpaJaeWUpDPMVI/0iUiW/G5L6PMBzRUoS2+KJiQ== X-Received: by 2002:a17:902:43e4:: with SMTP id j91mr12202572pld.147.1542916581781; Thu, 22 Nov 2018 11:56:21 -0800 (PST) X-Google-Smtp-Source: AFSGD/UVqis0q1CyxvLADeTXzCC9ta1j04b0O4kfx/XQOzaSfHy0m9GyX60ylOBE4AU25cw9eeYK X-Received: by 2002:a17:902:43e4:: with SMTP id j91mr12202545pld.147.1542916581091; Thu, 22 Nov 2018 11:56:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542916581; cv=none; d=google.com; s=arc-20160816; b=VUQqPbNYKPD5297g3BVmwTx5TQAkEfdzogM2BRgkMSAjY+1o+sPiwSlkf9cKPinVIN utj1ZuStXIlfHpL6qE7X/V73DrEjxiEnZ95HN+DzSu20J6NdkZKorCf5gGAr9/ilXmdk /Eosd/5Mu7Ho4KDBzvePDzH+crqu6SsbfnMA8GXD3gagb4NcW0k/J1Q0ccTbFKuj0RXQ AflbjxUUFA3QUqcOdbRDzqTJNcJOpP3y2M36qQ6ZSG1QF5govTp+i7GKrPkETgFKPNY+ pSD40oRLBTFtme+r1CsAYPNW44BTbH7VVyLqWCS3fd90TSE8xbHJJ8YrUommaemWknfW mhhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=HJQM6B1JeeKuxQG1shlJz1zUHOF3lDSR6SD7TN4qYbg=; b=eWoomqDGViCQk3us+iMMVSF73UrvNcNgSCpq6vJNIK7x+SDT18cjc4w+H0pJwW3f3v EBOnQFod6yr4YQSXQh9/0PkqHNMfj4klH+KA/1yeo/42Sm0mY8aSR8xMMu4MD3D4ONmZ Iw9O+xDZWbI6tTAkY/EN2ZiIhhTcTcuxUQpRGX+KPQ9Dud5HS29G9Z7y3cPm3aglgqSv F5rgocJ5FxduYLSPI+T8Qy8j6MK/lkQO4s9zapgKoV1mj/4yS3t7VNGGK+uxajgYPX6U rGklWXen0Qtj47Lm8+NCktFYcIc9ujur+T67CQiL1izuWAPCqf4kzfHgLnwM6trtwYl2 saOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=zCSP0z9j; spf=pass (google.com: domain of sashal@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=sashal@kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id f61si13275929plb.51.2018.11.22.11.56.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 11:56:21 -0800 (PST) Received-SPF: pass (google.com: domain of sashal@kernel.org designates 198.145.29.99 as permitted sender) client-ip=198.145.29.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=zCSP0z9j; spf=pass (google.com: domain of sashal@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=sashal@kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sasha-vm.mshome.net (unknown [37.142.5.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 937E320864; Thu, 22 Nov 2018 19:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1542916580; bh=sJFYhQVjF2sT8uCmoRl4SvhCC5gDGR0+SXDcj4wN0eU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zCSP0z9j3E0W9ASuOAWGqF2sNF54i0qoC6KOowReJDAEzb9ZY+p9G3OsTRNHTQdOO 1nHV54W22o3adXqFEaRBpliRVehnifor+RVnfGVMpbJRRM8eGHWj6O573SR54LBPgj j1UhyGC9FxLSlfKlgof2/QK/1sStNAerDjWBrdAw= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Michal Hocko , Balbir Singh , Mel Gorman , Pavel Tatashin , Oscar Salvador , Mike Rapoport , Aaron Lu , Joonsoo Kim , Byoungyoung Lee , "Dae R. Jeong" , Andrew Morton , Linus Torvalds , Sasha Levin , linux-mm@kvack.org Subject: [PATCH AUTOSEL 4.14 21/21] mm, page_alloc: check for max order in hot path Date: Thu, 22 Nov 2018 14:54:52 -0500 Message-Id: <20181122195452.13520-21-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181122195452.13520-1-sashal@kernel.org> References: <20181122195452.13520-1-sashal@kernel.org> 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: X-Virus-Scanned: ClamAV using ClamSMTP From: Michal Hocko [ Upstream commit c63ae43ba53bc432b414fd73dd5f4b01fcb1ab43 ] Konstantin has noticed that kvmalloc might trigger the following warning: WARNING: CPU: 0 PID: 6676 at mm/vmstat.c:986 __fragmentation_index+0x54/0x60 [...] Call Trace: fragmentation_index+0x76/0x90 compaction_suitable+0x4f/0xf0 shrink_node+0x295/0x310 node_reclaim+0x205/0x250 get_page_from_freelist+0x649/0xad0 __alloc_pages_nodemask+0x12a/0x2a0 kmalloc_large_node+0x47/0x90 __kmalloc_node+0x22b/0x2e0 kvmalloc_node+0x3e/0x70 xt_alloc_table_info+0x3a/0x80 [x_tables] do_ip6t_set_ctl+0xcd/0x1c0 [ip6_tables] nf_setsockopt+0x44/0x60 SyS_setsockopt+0x6f/0xc0 do_syscall_64+0x67/0x120 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 the problem is that we only check for an out of bound order in the slow path and the node reclaim might happen from the fast path already. This is fixable by making sure that kvmalloc doesn't ever use kmalloc for requests that are larger than KMALLOC_MAX_SIZE but this also shows that the code is rather fragile. A recent UBSAN report just underlines that by the following report UBSAN: Undefined behaviour in mm/page_alloc.c:3117:19 shift exponent 51 is too large for 32-bit type 'int' CPU: 0 PID: 6520 Comm: syz-executor1 Not tainted 4.19.0-rc2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xd2/0x148 lib/dump_stack.c:113 ubsan_epilogue+0x12/0x94 lib/ubsan.c:159 __ubsan_handle_shift_out_of_bounds+0x2b6/0x30b lib/ubsan.c:425 __zone_watermark_ok+0x2c7/0x400 mm/page_alloc.c:3117 zone_watermark_fast mm/page_alloc.c:3216 [inline] get_page_from_freelist+0xc49/0x44c0 mm/page_alloc.c:3300 __alloc_pages_nodemask+0x21e/0x640 mm/page_alloc.c:4370 alloc_pages_current+0xcc/0x210 mm/mempolicy.c:2093 alloc_pages include/linux/gfp.h:509 [inline] __get_free_pages+0x12/0x60 mm/page_alloc.c:4414 dma_mem_alloc+0x36/0x50 arch/x86/include/asm/floppy.h:156 raw_cmd_copyin drivers/block/floppy.c:3159 [inline] raw_cmd_ioctl drivers/block/floppy.c:3206 [inline] fd_locked_ioctl+0xa00/0x2c10 drivers/block/floppy.c:3544 fd_ioctl+0x40/0x60 drivers/block/floppy.c:3571 __blkdev_driver_ioctl block/ioctl.c:303 [inline] blkdev_ioctl+0xb3c/0x1a30 block/ioctl.c:601 block_ioctl+0x105/0x150 fs/block_dev.c:1883 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1c0/0x1150 fs/ioctl.c:687 ksys_ioctl+0x9e/0xb0 fs/ioctl.c:702 __do_sys_ioctl fs/ioctl.c:709 [inline] __se_sys_ioctl fs/ioctl.c:707 [inline] __x64_sys_ioctl+0x7e/0xc0 fs/ioctl.c:707 do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Note that this is not a kvmalloc path. It is just that the fast path really depends on having sanitzed order as well. Therefore move the order check to the fast path. Link: http://lkml.kernel.org/r/20181113094305.GM15120@dhcp22.suse.cz Signed-off-by: Michal Hocko Reported-by: Konstantin Khlebnikov Reported-by: Kyungtae Kim Acked-by: Vlastimil Babka Cc: Balbir Singh Cc: Mel Gorman Cc: Pavel Tatashin Cc: Oscar Salvador Cc: Mike Rapoport Cc: Aaron Lu Cc: Joonsoo Kim Cc: Byoungyoung Lee Cc: "Dae R. Jeong" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- mm/page_alloc.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index a604b5da6755..2074f424dabf 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3867,17 +3867,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, unsigned int cpuset_mems_cookie; int reserve_flags; - /* - * In the slowpath, we sanity check order to avoid ever trying to - * reclaim >= MAX_ORDER areas which will never succeed. Callers may - * be using allocators in order of preference for an area that is - * too large. - */ - if (order >= MAX_ORDER) { - WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); - return NULL; - } - /* * We also sanity check to catch abuse of atomic reserves being used by * callers that are not in atomic context. @@ -4179,6 +4168,15 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid, gfp_t alloc_mask; /* The gfp_t that was actually used for allocation */ struct alloc_context ac = { }; + /* + * There are several places where we assume that the order value is sane + * so bail out early if the request is out of bound. + */ + if (unlikely(order >= MAX_ORDER)) { + WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); + return NULL; + } + gfp_mask &= gfp_allowed_mask; alloc_mask = gfp_mask; if (!prepare_alloc_pages(gfp_mask, order, preferred_nid, nodemask, &ac, &alloc_mask, &alloc_flags))