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 B0455C43334 for ; Mon, 18 Jul 2022 21:34:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 453F06B0087; Mon, 18 Jul 2022 17:34:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 403368E0001; Mon, 18 Jul 2022 17:34:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CA606B0089; Mon, 18 Jul 2022 17:34:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1CE8F6B0087 for ; Mon, 18 Jul 2022 17:34:21 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E163C20B6F for ; Mon, 18 Jul 2022 21:34:20 +0000 (UTC) X-FDA: 79701524280.14.4EC3575 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf22.hostedemail.com (Postfix) with ESMTP id 70040C0075 for ; Mon, 18 Jul 2022 21:34:20 +0000 (UTC) Received: by mail-qt1-f180.google.com with SMTP id y9so6414082qtv.5 for ; Mon, 18 Jul 2022 14:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=suUG4NbxQ9Jc3ynJZYSSIg0ST38XjFLBT9pq2CkXbaQ=; b=b0pxV4EfxBXsSBC2H3gma7vsR1kQNKR2IEM+ZlJTjB6+KE9bMMdkfPugTlRcm2Gy7o F50+Slq8nFJGAmp1b4+kcJ/PmUSNBSl5P5T8cZZRupf5GdWDpZlvxo4kUaJ7zIuVnZ/k o1ncUXcuiKonkqAuQyuo11YJCxDbb+JK7S+NTTJ8wi8gCdd0+dCkdUE9EEQ6yjVmRsRM 8S2jTk9A3MaoTdXAxDbqpN2H2jcs4y/wGQJ4zJQDkt0vu4OXSNv14Hn1sP7spyXBPO8n VUbV6mFd4MJQSsvqp2Mr1WARi5qZDfM9soD3kVT0qVkhTkdvBBuE3tgdhNZuWz4nQjOR 9c2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=suUG4NbxQ9Jc3ynJZYSSIg0ST38XjFLBT9pq2CkXbaQ=; b=PmgmGrBYwo+OPCypxr6zzwnYrJSM/VzdMUdFHKOLZKScfIGWQVJ3kJXUP631CT5F5K SppOlEAveo8BM0hFez5KgFbp7P8bbqAT+xTfBzgJ2L63COdgCt5VMA/Sj/sCt9nxyXlu 2kWBzskukJl8ajxsdmK655vHh44Hp7T+g5yxaI4ZS+cRGfvCsOgV0ICxlDDhSWPThtPa B6EFPbaJd/U+Zi8HJ6k2hN6iOFzWMx+eZNM/ig7QbxoT0JiXojoE5S8EKxIspxz46dUN vkWnogtKfv72Am42CRHDVK0KbtpXVO88VSELmoigBawT2HScFWYfCbTtJBL43ExiL140 f9RA== X-Gm-Message-State: AJIora9NydP++JDWG2XT13X10uvVfmf8cf7k59kQqC+OvSb1h55bz5ms Z2kaY6jTp6i6AG5Cou45+JgMqw== X-Google-Smtp-Source: AGRyM1uQvjddRJ8GTU4jNcb8q7gfa6t0XJN3XwYL2TU+081VWIyu/CfILm0ovHBg/Rjy20DpC/4D9w== X-Received: by 2002:ac8:5f09:0:b0:31e:9704:dfab with SMTP id x9-20020ac85f09000000b0031e9704dfabmr22960730qta.375.1658180059610; Mon, 18 Jul 2022 14:34:19 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id ez12-20020a05622a4c8c00b0031eb0bb5c3csm10047906qtb.28.2022.07.18.14.34.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 14:34:18 -0700 (PDT) Date: Mon, 18 Jul 2022 14:34:01 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Liam Howlett cc: Hugh Dickins , David Hildenbrand , Andrew Morton , Yu Zhao , Matthew Wilcox , "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] maple_tree: Fix sparse reported issues In-Reply-To: <20220718174733.dya2xjigqeud6clx@revolver> Message-ID: References: <20220713132926.3sl7gs67dyjj7kit@revolver> <44a478e8-2ccc-e82-bd5a-172778c01529@google.com> <20220713175013.aoemaelds45aavc4@revolver> <20220715195301.r7ozt6ph2scti7vz@revolver> <20220718022718.wtlw7grwp6dv5fcp@revolver> <1098dd4d-8f12-4493-5aff-1ee489d8e7@google.com> <20220718125649.cpatlh7ublgf7bvg@revolver> <20220718134541.ucbpuqdfcnfxravx@revolver> <7db5a8c5-9084-a7fe-6e83-713e52ed8539@google.com> <20220718174733.dya2xjigqeud6clx@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658180060; a=rsa-sha256; cv=none; b=QgkM6Y+zvhfaBf7ZAMf3i5DsQJxc+xkiL3ICyiL1TSkwFnoFVSqnykn7SesD29nYNhcQ5o GnThxEwqIYkg4Nxo+mt+82/sNkSjN6XVz0Shxut78obmfounqsLYD0dEKGvb3EkqZlaT8w nH4A2E3qKjXNYff9BRjYirPrAuseizM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=b0pxV4Ef; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658180060; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=suUG4NbxQ9Jc3ynJZYSSIg0ST38XjFLBT9pq2CkXbaQ=; b=PVCUgpue+XrvfWK6B6jWPTdTOqGx/PQRNHfuOoJshF+jFxcnTNGUc42LjW5RJq46TXZ4av CAPi/eDkoyEAVZHp1pQhRFZQA0LUs05PsdHXq8Vdju2bEJYsd7RBp7goT1ZJeUab1uN1ON /S/DiUeiZXvQ2tLu5IhM8AcLzh6+nj0= X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=b0pxV4Ef; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=hughd@google.com X-Stat-Signature: jzgojnu99fd6xg7mqd5no74uw6dx5oj4 X-Rspamd-Queue-Id: 70040C0075 X-Rspamd-Server: rspam02 X-HE-Tag: 1658180060-928203 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 Mon, 18 Jul 2022, Liam Howlett wrote: > > > > I said before that I expected the test run to hit the swapops.h > > migration entry !PageLocked BUG, but it did not. It ran for > > nearly 7 hours, and then one of its builds terminated with > > > > {standard input}: Assembler messages: > > {standard input}: Error: open CFI at the end of file; > > missing .cfi_endproc directive > > gcc: fatal error: Killed signal terminated program cc1 > > compilation terminated. > > > > which I've never seen before. Usually I'd put something like that down > > to a error in swap, or a TLB flushing error (but I include Nadav's fix > > in my kernel, and wouldn't get very far without it): neither related to > > the maple tree patchset. > > > > But on this occasion, my guess is that it's actually an example of what > > the swapops.h migration entry !PageLocked BUG is trying to alert us to. > > > > Imagine when such a "stale" migration entry is found, but the page it > > points to (now reused for something else) just happens to be PageLocked > > at that instant. Then the BUG won't fire, and we proceed to use the > > page as if it's ours, but it's not. I think that's what happened. > > > > I must get on with the day: more testing, and thinking. > > > I think this is the same issue seen here: > https://lore.kernel.org/linux-mm/YsQt3IHbJnAhsSWl@casper.infradead.org/ Yes, that's a swapops.h migration entry !PageLocked BUG on brk. > > Note that on 20220616, the maple tree was in the next. > > I suspect I am doing something wrong in do_brk_munmap(). I am using a > false VMA to munmap a partial vma by setting it up like the part of the > VMA that would have been split, inserted into the tree, then removed and > freed. I must be missing something necessary for this to function > correctly. Thanks for pointing to that, yes, the vma_init(&unmap, mm) etc in do_brk_munmap(): I hadn't noticed struct vma_area_struct unmap before. And almost coincident with your mail, my next test run crashed on kernel BUG at mm/huge_memory.c:2013, VM_BUG_ON_VMA(vma->vm_start > haddr), in __split_huge_pmd_locked(), while servicing do_brk_munmap(): no doubt for a (different but) related reason. Presumably you noticed an opportunity to optimize out some maple tree operations by giving do_brk_munmap() its own processing. But I think you're going to have to undo all that, and make do_brk_munmap() do things in the standard, less direct, munmap() way - using do_mas_align_munmap() I presume. (Oh dear, I see that doing mas_preallocate() at the beginning, but then __split_vma()s inside, and __split_vma() will do a vma_adjust(), which will do a mas_preallocate(). Ah, but they are on distinct "mas"es at different levels, so it's probably okay.) If rmap is to be sure to find migration entries that it inserted earlier, you must hold anon_vma_lock_write() (in the brk case) across the tricky vma manipulations. No doubt you could write an optimized do_brk_munmap() which does everything under anon_vma_lock_write(), but you'd then be duplicating far too much of the care in __vma_adjust() for my taste (I'm already not so happy to find it duplicated in vma_expand()). I'll continue with some testing, but expect it to keep hitting these issues until do_brk_munmap() is rewritten - perhaps it reduces to little more than a wrapper like do_munmap() or do_mas_munmap(). Hugh