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 32D74EC875F for ; Fri, 8 Sep 2023 00:18:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60E2F6B0071; Thu, 7 Sep 2023 20:18:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 56F026B0072; Thu, 7 Sep 2023 20:18:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40FDD8E0001; Thu, 7 Sep 2023 20:18:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 30D676B0071 for ; Thu, 7 Sep 2023 20:18:10 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F0B38A0486 for ; Fri, 8 Sep 2023 00:18:09 +0000 (UTC) X-FDA: 81211517898.19.E9297FD Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by imf07.hostedemail.com (Postfix) with ESMTP id 2DDF940024 for ; Fri, 8 Sep 2023 00:18:07 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=XjBO039z; spf=pass (imf07.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.52 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694132288; 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=kwqmgF23vQcnqhZph/r7b6EAuDvU+RRr94jnoyag2zI=; b=CtMPrNGoQ4PlF+me+BknSUJBhnIkV4edaZh4LqfA0gsUSOoeZZ4eh02sfX7UfJ79nPdPt0 oRwDfraSPyZGAE9lyXUugZvT0yUV0Vx+QaFcsvR6REKwODv8VwduN4VpSckX/B1g3SZVH7 gLHm5ouOwdC3hY0t024KDUE/absp3iY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694132288; a=rsa-sha256; cv=none; b=o44eFdCb/R3QNQZXUhfMb7747c/lvcsbUAc9bYW2wVN8P0tw2SEbeEqmtNSULhN0xz01rv H8/VTX11lReA4WNtTu3eXt9lY1o8E8GSJehdPBlhgyMbaie1vtRO5W9CdZiU3Nnx5b6nxW n6dFx7z7briMnROzmu7XiTOEbVXgyUs= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=XjBO039z; spf=pass (imf07.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.52 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none Received: by mail-io1-f52.google.com with SMTP id ca18e2360f4ac-79565370a93so58868739f.0 for ; Thu, 07 Sep 2023 17:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1694132287; x=1694737087; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=kwqmgF23vQcnqhZph/r7b6EAuDvU+RRr94jnoyag2zI=; b=XjBO039zqJgQuGtNtchV3CDOgtR3Id+buMEaYeSuN/4ZtgE59gutmr2FQkGeMMccmk iPR/kVLs/IejSAFgwhmerG5/3l5kv61SqtSZQiKeYYlO9t7BlE8LDHOCsSpt1APKswnf LfEyI5koOiR3k34fPVcnn7gy6wnoP3REAdeFI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694132287; x=1694737087; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kwqmgF23vQcnqhZph/r7b6EAuDvU+RRr94jnoyag2zI=; b=WkxjhZCxyBqV5Jm0tXQjMG6VKUw3Y9NfEBeFOcVjXBrSDUjAbhe/jQh/NG7uSGUp9L n6Odf0XGSgOh7oaUTcbzqOCdioC8781FK6N9gboLi/8a9BQ2c6woNNPXY61IvbVfEU2I xjzlFjyI6NYxAEvljh+M+9lOJZ7Zux5xHKYtWDC+Uzxa/qR8uPSAAd0+A9727m4Utdr6 RtiCxraCc/EZyKe4tzfsojEVQB9iL0ZRMWKO4DlY3hZTw0a6JKdpVSPbkJJngPq2rcSx zRnyK2XopzGmLERwHBHq/qNvfKZ3EEsv4CODG1XbDxKbV3bHF8gUbcILq2BELduBrK+G 3FBA== X-Gm-Message-State: AOJu0YySJ995zjHlIAY3LfC417bOyJ8ESo/GtU/CqpsvTgbwLKEm1w0d N0D+vb3OLJa+4yqddp/Vkzkkfw== X-Google-Smtp-Source: AGHT+IH0N9Wu/V5lr5E20iI/yXizux3YQc4t0WJJ5poVDN3LCLNNDsPqZDNXh/R/umIjfpjCExXvYQ== X-Received: by 2002:a6b:610a:0:b0:786:25a3:ef30 with SMTP id v10-20020a6b610a000000b0078625a3ef30mr1337280iob.7.1694132287217; Thu, 07 Sep 2023 17:18:07 -0700 (PDT) Received: from localhost (156.190.123.34.bc.googleusercontent.com. [34.123.190.156]) by smtp.gmail.com with ESMTPSA id u1-20020a02c041000000b0042b1061c6a8sm143948jam.84.2023.09.07.17.18.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Sep 2023 17:18:06 -0700 (PDT) Date: Fri, 8 Sep 2023 00:18:05 +0000 From: Joel Fernandes To: Uladzislau Rezki Cc: Lorenzo Stoakes , linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig , "Paul E. McKenney" , Vlastimil Babka , Zhen Lei , rcu@vger.kernel.org, Zqiang , stable@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 1/2] mm/vmalloc: Add a safer version of find_vm_area() for debug Message-ID: <20230908001805.GA4088026@google.com> References: <20230904180806.1002832-1-joel@joelfernandes.org> <571d4a4a-0674-4c84-b714-8e7582699e30@lucifer.local> <20230905114709.GA3881391@google.com> <20230906224608.GB1646335@google.com> <499537a7-3380-4355-ae34-df7f5c0f41bd@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: t1gzyicsdwdbzb4j65ep471awg9xcf1h X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2DDF940024 X-Rspam-User: X-HE-Tag: 1694132287-952269 X-HE-Meta: U2FsdGVkX1/Mwa9juvx1agK2HtOyqUpyyzueKKvaJmC/2C9Lw/lf+/MvgrVzxWGriMpgyD15fgKmIA45OKhWbqFNK+Vx2bbLRIJbvJFm2P/OBuI0lruJebDEsZHaRYYYNv8vvFsMQKsP6y4a8eGBIk8dohrmfR3/Owj9JDvvbRBMCsYoxD/KUohM/J5hTXomUMTYXT4PLsmtubgZyEwLhhSzqGVZ70WIX1QjJpEH9vRdE6RTpzASCpKlfRRqL9688MPrnsJHMJJivT5Qw3mqSUBRqkokx8EoASx72TwJcuXc18jbnUNy6i5K15+s9IxaKUEN9EPnL0iV6x1A1FfmuizyLGgQyBH5QEqZaM6kMu9esMefBsMUbDqmU8sJXUjo2BlZfCamnQeoGQy8Q/s6rIvgMRhgRFNRhkHGQmvM1OgtsLdhAOEhDr1ThSgKpBeUCGTVwWUCozthVVs1GavFo3nlfk4pUNB0hNjPOmrTrKzF/fYMEY3V7tiBVOhXk/BmpVUnd/0p8lEbc8AGQa0asmmKaB8jW/SOw0BT+omIfMM4weyexsNaQZiIXYcD9TymYz+34OOD7TLOHKYcqOA/LhLxiwbvJYIFiAsvKmHDN2pPDVuJ03x4/wc3Lz36Nz8V95e1hx/10O9qZSiDOtKXoMnlEXKpGiue2W6TiS4cy1xeInA88FoqX+iElXTKZQIggHXly/aYpvITeBZO6r1LM8UlZY120fxTG09YLx1KYXDMMioPF30FlREeeKqJED7wTYG7r0KOpu4h1YH3WVeGNRH3SIYYeErt5pRaWbmdkwqBvkVtdiRteskv8bWXHF2kQMOjDXZh0Osj6XNmteeXcjWCs/+pNJMeMaGHFt1TAhMZBPEfNDHCl7Cjn44R21GY528/G/waONY0j7bCerl9Jxx1z9aHUF+RoYYVrwu0x0b9iT946mjnnOkXm9yi/YjS3NnkZI3LpiUZuDF2YNI BSpfcaDW KZi0JYjwLIsJ9GVM2RRnIj7hn2E00N5L7lXikrWR6s+OHBpFQtvg/J9sXF6TyJ20OA9t/Y9xF0GPoVCreKmZpKmiIfE3UeWFppwK7Q+sZDkT9uee0AGX7iylx4Gk8GxJlAMMaYhytLDicpd9c9u2pQDyQZnjeL3ndSzxCKWwqRW+VI00XJNbftzCokmccVkB2rdGIRLbt7pjV0Cjum4Zs4syp7wAHT30c4pp72Wwvx2Xsxq8o9lcj8o2n5iMkVAuGGBDLVi0njj7f9r9yGcMykL3yafdB1GuceMXFF+cv5tGTYH6VuLTh/i8xXpDivww1zaWOfHFl4dkSkfJCNkEPVXhqk+OjT4HS2UFJO1uZQBoUJldrwMBKG5mtaRUR0CcMrLf70hKXCP3GRnoRffDm15jJftlglWwMPfwGx0pU9goNORIXmcVLn/xNgQ== 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 Thu, Sep 07, 2023 at 11:23:40AM +0200, Uladzislau Rezki wrote: > On Thu, Sep 07, 2023 at 08:11:48AM +0100, Lorenzo Stoakes wrote: [..] > > Anyway, so TL;DR:- > > > > 1. As we both agree, add a comment to explain why you need the spin trylock. > > (there are no further steps :P) > > > > And I don't believe this actually needs any further changes after this > > discussion*, so if you fancy doing a follow up to that effect that will > > suffice for me thanks! Thanks. > For PREEMPT_RT kernels we are not allowed to use "vmap parts" in non > slepable context, this is just reality, because we use a sleep type of > spinlock. > > I am not sure how urgent we need this fix. But to me it looks like > debuging and corner case. Probably i am wrong and miss something. > But if it is correct, i would just bailout for RT kernel and rework > later in a more proper way. For example implement a safe way of RCU > scan but this is also another story. Bailing out for RT kernel is insufficient, as we need the trylock() to avoid self-deadlock as well for !PREEMPT_RT. Plus IIRC in the past there was a opposition to special-casing PREEMPT_RT in code as well. Admittedly those PREEMPT_RT cases were related to detecting preempt-disabled than a lock-held section though. We could optionally do a trylock() loop + bail out after certain number of tries as well but that would compilicate the code a bit more and I am not sure if it is worth it. Still if you guys feel strongly about doing something like that, let me know and I can give it a try :). thanks, - Joel