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 AAE05C61CE8 for ; Fri, 6 Jun 2025 11:56:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BEB56B0093; Fri, 6 Jun 2025 07:56:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 196446B0098; Fri, 6 Jun 2025 07:56:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0ABA76B0099; Fri, 6 Jun 2025 07:56:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E18076B0093 for ; Fri, 6 Jun 2025 07:56:10 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 97A4C120AC9 for ; Fri, 6 Jun 2025 11:56:10 +0000 (UTC) X-FDA: 83524822500.15.1B665F7 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf24.hostedemail.com (Postfix) with ESMTP id C719F180009 for ; Fri, 6 Jun 2025 11:56:08 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Ge9NoNBL; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749210968; 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=Hzp2EzU3gEy1DigZCn3AIvJRWQwen9LjZvTJe0DHtqE=; b=L2SA+xwh0BBrGYblwyxayoYMwfPMoZ9rvyEK8iARXDpUkcSNRGl81QLgESvp0MaXHR19Ty dl3C2LXk5UraaBvUPyVV5I65DfSbd4WNFSps3B+2PDwRgNP2lrvDOWnhuZIKjdoGhg6lom 4B64bepLRUi1ziUaFRpiRKHx2KYIbII= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749210968; a=rsa-sha256; cv=none; b=74PRds/c9pg1rC39VnCU2+sCbE/80ILyw2hniJdLKqqFaNaOMgvpNLxZJpqr7eSFKu4YCh 8CwOL0v//Rh3/q7pE+gERlwd/2lBCzOHBY+FnpNLdWE0NtxzAsdIlL4hvvYG1fe1LhVKhW 7Mc/KQctbuO0FYQ6UovIPLScC0XQJO4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Ge9NoNBL; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-450cea01b9cso6600535e9.0 for ; Fri, 06 Jun 2025 04:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1749210967; x=1749815767; 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=Hzp2EzU3gEy1DigZCn3AIvJRWQwen9LjZvTJe0DHtqE=; b=Ge9NoNBLI2PRJOa8F+OGy5H9L7qQlYlT+OPN6SSPp0m54SzNrpMPtDIFpw8xpa9zVg PkuYH8UDk+5KVYooegA4anE5HaaYNC1ZgT/Vppnp1ZdDR71atqhDGnG54OUY4ayVXPxd aDCj54RDN+UxACUBJWOkEShl6I5rr1vSZ1MpcnLiqWGF5srBWQyriIAJrad/wRVNfauw EHTue8sRG2sOCNpfOZxCYKUsH372J6IxEtB4x8J6bl+S26RKlKxFTV5sMx58y25LhJbX 0udOZufM+qzRZNqwYB9uw559qouVK4XuZId/7HO49bGzdX0WUYbth2Nt2jVbXqQCHMGL vqbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749210967; x=1749815767; 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=Hzp2EzU3gEy1DigZCn3AIvJRWQwen9LjZvTJe0DHtqE=; b=hJxQJcToY88v4tW0jt53M/W2LuZthFb5QNZmrKrUL4x4dedDHb5kvddE7Uuko8IG9F onRb2HFtvmyInSbdFFNQUcB4NZpVj1O1fQvp8B1Duxw8jtZ1j6PKCdunFrI9T7noUcjY xG9G39SkNea1syFIX/XUoyYwAApaDx1iVzQdMg9XWq4wxWId/IgSlVaHh+js5waB0PxD MBoYSqerf5IfmtfQ0PVXhC1LMVQvVgL/ECxPkI5OFj6Mhv1+vs/dViG0fGaJwUAbWX7t e+xoKHAjEgDErl4fcFXS9LBkHrx8+9ZD+8q8hsgukQgmBi6/Ry/jWW4EVAEWg+DDnYe3 J22g== X-Forwarded-Encrypted: i=1; AJvYcCX38cpgQ7FAgwV0boF9k2hD49PU4/Z1OrmMRv60hEAH+PeG5MGmvYqIGhgopBepeZ04fVVAflslZQ==@kvack.org X-Gm-Message-State: AOJu0Yz6+hLpWlP1kbuAQLF6E8tjX4O+v64HJBXBnuaYr0w1U3fEAlXm ZjsW8JTSRVZ7tF1Gln3+AlYy4teSBKlyBS9GeoHd/Yb+aT2byTm87zubFOOEOeudONY= X-Gm-Gg: ASbGncvCn2UO7Zm/HsshhLmGkxZWutoGGyjvfNjQkFsSVq8dqOqXD6rQ88JOFyxZSCv 27cNOL89KPy0Eqmp8NqAzUEg/5MPxkUTKfwzPtKAa56Ir71WsLQBF7USLp0SwcL/u7HVqBciY0v wSpmkHjiL1oUGSNlRzDGvhE0stlxEDURymQ3ritquQABPe6iMMzjF8jhAp05csc1XIZPhdzAuYD a+KtBaTGp3M8UlB4hTdPqKx8iXOsKFWZP7RzJF+IrckpeXTV8wjPFT7azk+2sqiMTInkU88ec6a KEd7uJAXcfTcBcpaVtFMEiVIAbohE1s2qaUFDQ3tkk5CayspY/0XR0yA+nnNabeb X-Google-Smtp-Source: AGHT+IHmoBwJARYFAtkilUp66ubm3Hag5fYQtpJOq/ChI1R63I9vNBKNTT4cU516skYBOn5oOv2jxw== X-Received: by 2002:a05:6000:2dc7:b0:3a3:71cb:f0bd with SMTP id ffacd0b85a97d-3a53188de8bmr2618588f8f.23.1749210967198; Fri, 06 Jun 2025 04:56:07 -0700 (PDT) Received: from localhost (109-81-91-107.rct.o2.cz. [109.81.91.107]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a5323a8c79sm1648209f8f.27.2025.06.06.04.56.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Jun 2025 04:56:06 -0700 (PDT) Date: Fri, 6 Jun 2025 13:56:05 +0200 From: Michal Hocko To: David Hildenbrand Cc: Lorenzo Stoakes , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Jason Gunthorpe , John Hubbard , Peter Xu Subject: Re: [PATCH v1] mm/gup: remove (VM_)BUG_ONs Message-ID: References: <20250604140544.688711-1-david@redhat.com> <1a65d0e6-6088-4a15-9c19-537203fe655c@redhat.com> <50ff9149-2824-4e57-8d74-d8d0c063c87e@lucifer.local> <1a7513cf-4a0a-4e58-b20d-31c1370b760f@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C719F180009 X-Stat-Signature: i118wip79h44htyk4f88c45u7ohmfiq7 X-Rspam-User: X-HE-Tag: 1749210968-338723 X-HE-Meta: U2FsdGVkX18qX3bIfLPNyK26jlla/CkBFqvqF8NQPiyHsXw2j9qPGsS9mWWB3ymq8d0n+zEZnBiWa5xulCHBeNFclJfclJ23+eOVtPQgfzPjHO5S4auN7kwZyCG+uouCbWFfevfqudcSQZC+Gdgts+485c46ss42A2Po+jlbHfEoLV2VmRB8DkT3qqYrt3cd9hkkVOaqwlKmCQimk4HzYy+UVlc76FrHJGvh745V584hoHJI0wxHNNHuy3aHYaUukmYSF2BquJr7Gr3xEU2gkVyM/n5hXvGvt77bfJMBLp49DhOWil0r92kixQ7kWrvi2ARutJji0uly49LJZs3HKL3CToX7lNU/iJ4WoyXUVSxgDZi+NdhXw5Ip3VGIA3l4uO74IfAo0hF6kep5SCYyqZDy2ni+yclVoVe0olhVHlL7/Kgr60HWSLg1OFYUf4P0GGd7YTuidAdjl3zM5MWO+hKsP75yAH/8Luy8pJV/OXwBuitTNgITBWvid0YbAdTZoxSdqro1bsRlDffMVeCN91TJIHJw3mL45Q32tSmhenOcFtDnXWpiyFvlGzxRIt7IB2lTyCyzMkwaZaEnqk9XWC1Uzl6IUjJ67vpm4DwjShnXe20a9KVpfjAeCHXvdP2LOTr8LoKxH1VSXXHAS8xGucxyjZOPg4G3OMmvf+6SO2ykJKe+4SrUpI4tguspC9OGQhT4iWRpP+zhItkpL5hhHmaOoxnN+Cx5H3GA8DatevKrWByY/Ro/IHkM7+kCgSK1xmqJMDmWkOfmFMOciJMp21kuFZDWtiN/u/7cMsxAi5BW8SQPUy2I9ie00mRtSuJo2PLtJgqHl2lOgN6R/nLSgqCC0yFCNBiqO+p4NeZHhZ3sM0mo9G0aXZ9GzXx4f36uEPHWsUG2YBkd75G1/3uwOz2trntVJjE6qdCn5GCCJTItvYjiLHGKDLEAupIaRmukHkRGG05wMvh1E1YSafe pX5xLeAK UHrlZLDudUUw7kUQPyzic0YRHmoEEh7c894C0oV6onSzm7HSn5EndsAGcGiCglb2SsR8f 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: List-Subscribe: List-Unsubscribe: On Fri 06-06-25 13:44:12, David Hildenbrand wrote: > On 06.06.25 13:04, Lorenzo Stoakes wrote: > > On Fri, Jun 06, 2025 at 12:28:28PM +0200, David Hildenbrand wrote: > > > On 06.06.25 12:19, Lorenzo Stoakes wrote: > > > > On Fri, Jun 06, 2025 at 12:13:27PM +0200, Michal Hocko wrote: > > > > > On Fri 06-06-25 11:01:18, David Hildenbrand wrote: > > > > > > On 06.06.25 10:31, Michal Hocko wrote: > > > > > [...] > > > > > > > Turning them into VM_WARN_ON > > > > > > > should be reasonably safe as they are not enabled in production > > > > > > > environment anyway so we cannot really rely on those. Having them in > > > > > > > WARN form would be still useful for debugging and those that really need > > > > > > > a crash dump while debugging can achieve the same result. > > > > > > > > > > > > One question is if we should be VM_WARN_ON vs. VM_WARN_ON_ONCE ... > > > > > > > > > > *WARN_ONCE ha a very limited use from code paths which are generally > > > > > shared by many callers. You just see one and then nothing. Some time ago > > > > > we have discussed an option to have _ONCE per call trace but I haven't > > > > > see any follow up. > > > > > > > > > > Anyway starting without _ONCE seems like safer option because we are not > > > > > losing potentially useful debugging information. Afterall this is > > > > > debugging only thing. But no strong position on my side. > > > > > > > > > > > VM_BUG_ON is essentially a "once" thing so far, but then, we don't continue > > > > > > ... so probably most should be _ONCE. > > > > > > > > > > > > > > > > > > > > So while I agree that many of them could be dropped or made more clear > > > > > > > those could be dealt with after a mass move. An advantage of this would > > > > > > > be that we can drop VM_BUG_ON* and stop new instances from being added. > > > > > > > > > > > > As a first step we could probably just #define them to go to the > > > > > > VM_WARN_ON_* variants and see what happens. > > > > > > > > > > You meand VM_BUG_ON expand to VM_WARN_ON by default? > > > > > > > > Sorry to interject in the conversation, but to boldly throw my two English pence > > > > into the mix: > > > > > > > > As the "king of churn" (TM) you'll not be surprised to hear that I'm in favour > > > > of us just doing a big patch and convert all VM_BUG_ON() -> VM_WARN_ON_ONCE() > > > > and remove VM_BUG_ON*(). > > > > > > > > Pull the band-aid off... I think better than a #define if this indeed what you > > > > meant David. > > > > > > > > But of course, you'd expect me to have this opinion ;) > > > > > > See my reply to Michal regarding keeping VM_BUG_ON() until we actually > > > decided what the right cleanup is. > > > > Sure, but to me the concept of VM_BUG_ON() is surely fundamentally broken - if > > BUG_ON() means 'stop everything we're going to corrupt' then it makes no sense > > to add a '...but only if CONFIG_DEBUG_VM is set' in there. > > > > So to me the only assessment needed is 'do we want to warn on this or not?'. > > Well, when done carefully, it would be when reworking a VM_BUG_ON: > > (a) Should this really only be checked with DEBUG_VM or should this > actually be a WARN_ON_ONCE() + recovery > (b) Does this check even still make sense in current code, or were we > just extra careful initially. > (c) Do we even understand why it is checked or should we add a comment. > (d) Should we use one of the _PAGE / _FOLIO / _VMA etc. variants instead > or even add new ones. This is surelly a very responsible approach and I salute to that. But then the reality hits... > One could argue that the same is true for any other VM_WARN_ON ... but my > point from the beginning was that if we're already touching them, why not > spend some extra time and do it properly .. > > ... but yeah, 600 instances are a bit much. ... exactly this. And I believe that the same could be achieved post factum while having the ugly VM_BUG on gone. > So agreed, let's move forward with a simple conversion. Good call IMHO. [...] > > Am happy to come up with the churn-meister version of this patch and take the > > heat :P > > I assume with "this patch" you mean "a patch that gets rid of VM_BUG_ON > completely", because I want this patch here (that started the discussion) to > go in first. Yes this makes sense. > Fascinating how you are always looking for work :P Thanks to both of you! -- Michal Hocko SUSE Labs