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 47CDFC433F5 for ; Mon, 25 Apr 2022 20:02:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A84B46B00A6; Mon, 25 Apr 2022 16:02:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A34726B00A7; Mon, 25 Apr 2022 16:02:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D5976B00A8; Mon, 25 Apr 2022 16:02:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 7AB696B00A6 for ; Mon, 25 Apr 2022 16:02:03 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4646E211BF for ; Mon, 25 Apr 2022 20:02:03 +0000 (UTC) X-FDA: 79396472526.28.87468E1 Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) by imf27.hostedemail.com (Postfix) with ESMTP id 486C640048 for ; Mon, 25 Apr 2022 20:02:01 +0000 (UTC) Received: by mail-vs1-f46.google.com with SMTP id f32so15503854vsv.1 for ; Mon, 25 Apr 2022 13:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ipbl5TQBmzxQLxByP8eeV1/87M/skoc9cO2qR76GObw=; b=r51c8MsCuZts96hTOgBMB9l5ucaeMldWh0LftO8XLuhjmUopI4bpnF5LiNu2SXBRBo VckwfD5s2hSbp6UtRhiU/9SBS6YZAmDCB6Oo0PnVzZZK6YZeLJJaHE/gEBGqPd+W+y51 wx1PvO1PHDvkxkCRx7s9ZnyA1PwrMMm+FUfM0MNg4yCJRgVTnplTn9gi9l0+xBK0Sy9d QQSL98y6XSPs0Scpr6w3higdumcI/Or4dpZnW3vF5G2mXonlwj/bzZtm7n45GcsRnR7R /zCZ1qGBV74dyzOnOrxMnv2Ne4MdpRIbzJw8/S0dUXCMrc8oHBcLIMOGMPorgdSCeOs5 36Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ipbl5TQBmzxQLxByP8eeV1/87M/skoc9cO2qR76GObw=; b=8NcglcxOGHvx+JnTBWWtXsmYRIWt0TQvH0B/y/YZJupvZz/11yKj5sbRn6Xa+fJOk+ K8YnBGZDniau5/WcuMyAcmie9Xqk2Rm2tb3jjhLBmi4JEFxS//hG4K27OrbMuHKdnsYU RHtdMLCwWXpNJD57bpYQOjLg7N/AKNYJRrzplwCp3WLRGiqTSz2xp7c+qsz07uajJyy7 DP6zCS1NS64f9y8HwVtktoK6m62KxZkrb2lybp2Dzk7JWuGj75yOmau5ggYG/rEnydm/ ewG5rVygqKcMKuH2+rGNaxOIYZzYiW92GUTc3mIxf7NURB+nv5X9A7Aqo5a8Cv4icCes 4Hng== X-Gm-Message-State: AOAM5326YZ6fmCLf85DvXQXLVqia8LKMWtBrePVN2FFdhRL3CEyV7luK B4WDrHGkH46GLeyRp/Yn4N5joF6VMWOfr9dUMf3csA== X-Google-Smtp-Source: ABdhPJxEKYhd/X+UL6zAs/4j1oJDJoOQK9AIqhshal0SMNW9n9f1uwef7k2qNy7h1iv2IWrg0stUDnsM5QP2GgckCGc= X-Received: by 2002:a05:6102:158a:b0:32a:56ea:3fba with SMTP id g10-20020a056102158a00b0032a56ea3fbamr5534217vsv.84.1650916921320; Mon, 25 Apr 2022 13:02:01 -0700 (PDT) MIME-Version: 1.0 References: <20220416010259.4gbz5hgvm2lgr3sj@revolver> <20220416151923.ig5zavuptjsufm3d@revolver> <20220419155055.qf52xpcftqb3r5nj@revolver> <20220419231748.omnhkl43vl5ep2j5@revolver> <20220420134336.bny7wza3ez2ldjsd@revolver> <20220425195852.qd3dzzjpitwaocx7@revolver> In-Reply-To: <20220425195852.qd3dzzjpitwaocx7@revolver> From: Yu Zhao Date: Mon, 25 Apr 2022 14:01:24 -0600 Message-ID: Subject: Re: [PATCH v7 00/70] Introducing the Maple Tree To: Liam Howlett Cc: Andrew Morton , "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: c9ddtzha6z3gcyurtmo35n6k5xpowkgc Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=r51c8MsC; spf=pass (imf27.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 486C640048 X-HE-Tag: 1650916921-511373 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, Apr 25, 2022 at 1:59 PM Liam Howlett wrote: > > * Yu Zhao [220425 14:06]: > > On Wed, Apr 20, 2022 at 7:43 AM Liam Howlett wrote: > > > > > > * Yu Zhao [220419 19:23]: > > > > On Tue, Apr 19, 2022 at 5:18 PM Liam Howlett wrote: > > > > > > > > > > * Yu Zhao [220419 17:59]: > > > > > > On Tue, Apr 19, 2022 at 9:51 AM Liam Howlett wrote: > > > > > > > > > > > > > > * Yu Zhao [220416 15:30]: > > > > > > > > On Sat, Apr 16, 2022 at 9:19 AM Liam Howlett wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How did you hit this issue? Just on boot? > > > > > > > > > > > > > > > > I was hoping this is known to you or you have something I can verify for you. > > > > > > > > > > > > > > > > > > > > > Thanks, yes. I believe that both crashes are the same root cause. The > > > > > > > cause is that I was not cleaning up after the kmem bulk allocation > > > > > > > failure on my side. Please test with this patch. > > > > > > > > > > > > Thanks. I applied this patch and hit a LOCKDEP and then a BUG_ON: > > > > > > > > > > > > lib/maple_tree.c:847 suspicious rcu_dereference_protected() usage! > > > > > > Call Trace: > > > > > > > > > > > > dump_stack_lvl+0x6c/0x9a > > > > > > dump_stack+0x10/0x12 > > > > > > lockdep_rcu_suspicious+0x12c/0x140 > > > > > > __mt_destroy+0x96/0xd0 > > > > > > exit_mmap+0x2a0/0x360 > > > > > > __mmput+0x34/0x100 > > > > > > mmput+0x2f/0x40 > > > > > > free_bprm+0x64/0xe0 > > > > > > kernel_execve+0x129/0x330 > > > > > > call_usermodehelper_exec_async+0xd8/0x130 > > > > > > ? proc_cap_handler+0x210/0x210 > > > > > > ret_from_fork+0x1f/0x30 > > > > > > > > > > > > > > > > Thanks - I'm not sure how this got through, but this should fix it. > > > > > > > > > > This should be added to 4236a642ad185 to avoid the LOCKDEP issue. > > > > > > > > > > --- a/mm/mmap.c > > > > > +++ b/mm/mmap.c > > > > > @@ -3163,9 +3163,9 @@ void exit_mmap(struct mm_struct *mm) > > > > > > > > > > BUG_ON(count != mm->map_count); > > > > > > > > > > - mmap_write_unlock(mm); > > > > > trace_exit_mmap(mm); > > > > > __mt_destroy(&mm->mm_mt); > > > > > + mmap_write_unlock(mm); > > > > > vm_unacct_memory(nr_accounted); > > > > > } > > > > > > > > Will try this. > > > > > > > > > Andrew, > > > > > > Please add this fix to the commit 4236a642ad185 "mm: start tracking VMAs > > > with maple tree" > > > > > > I've attached the patch for your convenience. > > > > Hi Liam, > > > > I assume you are still looking at the BUG_ON problem. I'll restart my > > testing once you have something for me to try. > > > > Thanks. > > No, The above fix stopped the suspicious rcu dereference. I've found > another issue in the mlock() code which I've also fixed.. but I needed > to change my allocations from within the immap rwsem lock as it triggers > a potential lockdep issue on high memory usage - lockdep complains about > fs-reclaim lock. I've a patch set that works but I'm working through > making it bisectable. I think the easiest thing is to integrate these > fixes and the others sent to Andrew into a v8. I hope to have this done > by the end of the day tomorrow. No worries. Just wanted to make sure I didn't miss anything from you.