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 13CF5C43334 for ; Tue, 21 Jun 2022 09:27:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 66F006B0073; Tue, 21 Jun 2022 05:27:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61E9F6B0074; Tue, 21 Jun 2022 05:27:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E7066B0075; Tue, 21 Jun 2022 05:27:02 -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 3DD6A6B0073 for ; Tue, 21 Jun 2022 05:27:02 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1D76BEB4 for ; Tue, 21 Jun 2022 09:27:02 +0000 (UTC) X-FDA: 79601713884.26.AA342D8 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf25.hostedemail.com (Postfix) with ESMTP id 81F9EA0093 for ; Tue, 21 Jun 2022 09:27:01 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id c2so21381851lfk.0 for ; Tue, 21 Jun 2022 02:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ifnIPViM69Gn0EtfiMceiQQ3U5cbSISeqEVjR7goDIQ=; b=dRU8sRBPetUucKScVySr3WRQ0R4LCu1DEpsBwORL7FYFPBN5BGy3HuK9y49XOmz8Td DUfO/e1VAjE+mzdyDbSi6N/NvsKm+3Kx2vew3EsD94+ptUZiWS9XY7HEyAiB+IP74Epo 3lorCqyPNzIYRm3Xrrr+OQpGe8gNCAjk/jM0Nz+OJv593D9uCLHx+kof9N1l5MTaHWTr 6m47+eiioV/r1dvLj2pz0IwzFytqV+/8nJuKABLj+HYrRArlic0M67GaNRA78SeKpWjc 7IUbdd8WHobLYqdml//X3FipOi0fPzhrrJ5Dj0X5vhheKEeA/fC3OXN1uiuGPoDSvWVb temQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ifnIPViM69Gn0EtfiMceiQQ3U5cbSISeqEVjR7goDIQ=; b=gKTtgflug7rKKvaOqS0pP4QfYEYzXc3UULzmJCfor30Vzrw+ik7b6q/UjfIi/QCEPV 9LnKMDaDgE9iO1+N5BCra+LLtQJWIW3OdlCp9OIBCqn9YCUPV72Jz2CyyHdIVs34IwmD asEZhRBz4XNHpMCXT1VLbMDJ+x+VnwV38P2Yt+lCKzeJ7mr/C/0EbyPO98Le4lerFgXF vWJ3SFNxVR6yRGPmEXMJWMxtXTAJtZ2cmgIbgxv2r7FDjagKBz7zfOT4HCLRJZ981GC9 MUeMZqRM6No1x1GfTgdq1maKV9sP1o7KMDSRib1wuHBcVZtjfZusxqwUq/Hp92wFD2Ur OcsQ== X-Gm-Message-State: AJIora/dw1NwCewNoLesxTjGQ7B4ly4+x8aCYIxhJplJjp3PWnjpapt2 4L7UxI/brx8uz5GMGDlonrE= X-Google-Smtp-Source: AGRyM1uErMFknRztKhYJ14KRUNJAqza0eTiI80x4rR3SsB9hpWmAw7pDVh8SIeiywFQKLmqvAax/jQ== X-Received: by 2002:a05:6512:2292:b0:47f:68b3:3c21 with SMTP id f18-20020a056512229200b0047f68b33c21mr7188798lfu.316.1655803619701; Tue, 21 Jun 2022 02:26:59 -0700 (PDT) Received: from pc638.lan ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id n8-20020a2e7208000000b0024f3d1daeaasm1934476ljc.50.2022.06.21.02.26.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jun 2022 02:26:59 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 21 Jun 2022 11:26:57 +0200 To: Zhaoyang Huang Cc: Uladzislau Rezki , "zhaoyang.huang" , Andrew Morton , "open list:MEMORY MANAGEMENT" , LKML , Ke Wang , Christoph Hellwig Subject: Re: [PATCH] mm: fix racing of vb->va when kasan enabled Message-ID: References: <1653447164-15017-1-git-send-email-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655803621; 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=ifnIPViM69Gn0EtfiMceiQQ3U5cbSISeqEVjR7goDIQ=; b=rCZRMk+KdLGa4u7DynhFNGb6qZJl8WB8QmhK5jWk6Ntn3uwXlOBn3KdaNoUr+xWDLwpAVY jvtto6ZPcxrua1cyhcDDYe8+CzP1qGpBTYYhwqsheuCmhldMVnmQQjH4TqBWqQMglBtzBZ UF44ibz90LpJRy4zJLcoiT9LB1Z5Yfg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dRU8sRBP; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655803621; a=rsa-sha256; cv=none; b=fJUk5kTPBWern3dVeJniC0d0OnPOMRFEIj8VaDAcHbqZsNJuv40K/XNAUgJpyKKQlcbdry B50LAQ7VMBBEA4IdDs9lx8gwI9NkPOdHn1aeNRczLJDgx9zuYC7ECoKl+4gzAhUu1lC2Qf jgn2Fm4CbrhMKrIaJHuiuMTTgkEJdoQ= X-Stat-Signature: apfmfuxpu1saf7hwz4e93s3f31p6ntgm X-Rspamd-Queue-Id: 81F9EA0093 X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dRU8sRBP; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1655803621-653699 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, Jun 20, 2022 at 6:44 PM Uladzislau Rezki wrote: > > > > > > > > > > > Is it easy to reproduce? If so could you please describe the steps? As i see > > > > the freeing of the "vb" is RCU safe whereas vb->va is not. But from the first > > > > glance i do not see how it can accessed twice. Hm.. > > > It was raised from a monkey test on A13_k515 system and got 1/20 pcs > > > failed. IMO, vb->va which out of vmap_purge_lock protection could race > > > with a concurrent ra freeing within __purge_vmap_area_lazy. > > > > > Do you have exact steps how you run "monkey" test? > There are about 30+ kos inserted during startup which could be a > specific criteria for reproduction. Do you have doubts about the test > result or the solution? > > I do not have any doubt about your test results, so if you can trigger it then there is an issue at least on the 5.4.161-android12 kernel. 1. With your fix we get expanded mutex range, thus the worst case of vmalloc allocation can be increased when it fails and repeat. Because it also invokes the purge_vmap_area_lazy() that access the same mutex. 2. You run 5.4.161-android12 kernel what is quite old. Could you please retest with latest kernel? I am asking because on the latest kernel with CONFIG_KASAN i am not able to reproduce it. I do a lot of: vm_map_ram()/vm_unmap_ram()/vmalloc()/vfree() in parallel by 64 kthreads on my 64 CPUs test system. Could you please confirm that you can trigger an issue on the latest kernel? Thanks! -- Uladzislau Rezki