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 BFE0FC5B543 for ; Wed, 4 Jun 2025 07:03:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED3766B04D7; Wed, 4 Jun 2025 03:03:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E83F96B04D9; Wed, 4 Jun 2025 03:03:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D72666B04DB; Wed, 4 Jun 2025 03:03:57 -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 B79996B04D7 for ; Wed, 4 Jun 2025 03:03:57 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 41BCA1D462D for ; Wed, 4 Jun 2025 07:03:57 +0000 (UTC) X-FDA: 83516828514.11.E7194C9 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by imf29.hostedemail.com (Postfix) with ESMTP id 70A4012000C for ; Wed, 4 Jun 2025 07:03:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XrOSVBhZ; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749020635; 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=40ajQCpqDRjpuGjCnS6LNsF3WHnh2o2xFeFnau3dKQk=; b=OIv6bpTk0KiZfvqGWUdQP0LED7Xji+Uqj9LsQXmkACcff1Eq8XyAIYcKbHl76PYl1/P5rU ve0iwSDw+HNMs2VTh88zJ86hNSq6MCbH33EY4a3Qwx0H+3ceovSJzElogP+EzlRU7EouhR SSR10ADg8obftGJAIy0GDgO11fGztlA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=XrOSVBhZ; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749020635; a=rsa-sha256; cv=none; b=GSLHggKu8OMOrL4FQNWbHc7pIOj6f7BvmK6O6BrMf8oqkrL2Y0Nrb/q6/QxIg9ndUaBTuE 9nMYodljW+tetWzy3rqDXHH8ZBD+daBLV6p20ndWuZjJtBnnMMZCP0ELiwN2cyaB9wZX64 g/8yhDJ8YhfUuTV3B+JaBUYdjVxiMIw= Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-40791b696a2so1182998b6e.2 for ; Wed, 04 Jun 2025 00:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1749020634; x=1749625434; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=40ajQCpqDRjpuGjCnS6LNsF3WHnh2o2xFeFnau3dKQk=; b=XrOSVBhZqMtXnmksClhMvlbZLHtOG3zfURFpeH96wvTTLARLFr0XucmOs2Zw4+NF8M zO/KGIASbG3yWBTWqi/IafeazNBIlnooFZ7qU+7TJBL0S5bbotXBptbXzvbTVu2QIeIK U40BqrzR2kbCW45saeVOLhTxjBy2UUbtnQ4D0d7Nmn/pHbc8Kwcumc6WwXNTqQvFXojK KzBHwuiYWbW4GGEiWX0ec77hQo2jEPSGY1oMJ1xfIGcPNw9ayhob8ryFAV9of99f38Uj urNyVfe//NY+PKZ9XbzdXguB6sU3uHnzruSiPBU4zwH4UtTSuRWuET2ANmDNSDJWFHJG Ybhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749020634; x=1749625434; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=40ajQCpqDRjpuGjCnS6LNsF3WHnh2o2xFeFnau3dKQk=; b=gVB4w6tl1QD8IGPXTahwF37sda32tRRoB3zwt6M4Hn7yUiS5I0zlFoARvXnEea68Pg OmlGPaln0BYJhy2tMAH/m+j+3T9fNnpF90sac8S1fAMCpX+NRVn4o1I6cnP17sq6Y0wl ByXUxiRNUs85Njw6RmaoRCoIQzra3tSCIyBe04VFfUq/qFXoxmJzSKt4xWu1wfrJyI2I nGliGNtV8UBpcdOneiDfWg8fLoV3iu97iy5vu7+/7NIDTkfzFnDDs6VZhdqpVcEaQLdR qJFU5+Z5WXP1OC/MWkLv8FYXoWlJkMBc2gXSOIRr9HXKNnmXzTdcpaZ32/tZAsD7Xu3W YNQw== X-Forwarded-Encrypted: i=1; AJvYcCWK7CthIOlEAFp2OePkuwbOF/oJHUCDMA3447Me3Au0gLPDNu7pFa/J5n6AyXL+0iHXSMqqzeaXvA==@kvack.org X-Gm-Message-State: AOJu0YxBdvf2p20u6skv2ybPTONo99E8/1kV4HfGFXnGMatQpQV1tCIg fzWLU+uNGA8ZIx610SBxvDkm9HemQocRk1Fxdv7ohcPAaAoi/AN+iEeS5ciyGfgtTQ== X-Gm-Gg: ASbGnctn8s9mlbfnq0boPYiRJyewGeSmZeradUxn0tu41c8Ciapr9D/a8dRpNAaVb/J oSFLFo3RgTSyKSQktfe43xvFq38Q/iCkQS00DqFckDLkR/tldZx4RgqRqTtb95wxKE5SYOwMkD+ GZfj+ysGhxumwR0E7cGitPrQ/6yTi/QxTKCBeeMck4CGjeEJ12iTCAOYBXiaIZ5waXO6lA6IqSX jJrBYWk/KuTEN1gBO9DoHChFwVJDHTECyJgFOa6VE7iFrlZTV2daoVzLd2XU3vcIv0Bqitw7C0J hOdfJb7wbdX33KzUTeRhu52mGGbs7b77gHJrVKJXSlndBoUK5estwk/cSX7TJrcY99TKUVmHj02 yPF48iZ8tLK8peMLkeAp9irfGZOvP8G9xKdn+7jFbrgrb0A== X-Google-Smtp-Source: AGHT+IFdbMc3chGS05aazK3NptvjeJGMEive3vKl+DZZ1wIg+JEq+OKIn9JnQGVLtzmO09GrSJUS4w== X-Received: by 2002:a05:6808:6b96:b0:3f6:a476:f7d3 with SMTP id 5614622812f47-408f0ed6388mr1629259b6e.9.1749020634210; Wed, 04 Jun 2025 00:03:54 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 5614622812f47-40678bf3374sm2140123b6e.8.2025.06.04.00.03.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Jun 2025 00:03:52 -0700 (PDT) Date: Wed, 4 Jun 2025 00:03:18 -0700 (PDT) From: Hugh Dickins To: =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Steven Rostedt cc: Linus Torvalds , Matthew Wilcox , Hugh Dickins , LKML , linux-mm@kvack.org, Andrew Morton , Christian Koenig , Huang Rui , Matthew Auld , Matthew Brost , dri-devel@lists.freedesktop.org, Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter Subject: Re: [PATCH] mm: Fix compile error when CONFIG_SHMEM is not set In-Reply-To: <20250603140632.168190f9@gandalf.local.home> Message-ID: References: <20250602170500.48713a2b@gandalf.local.home> <20250602171458.7ceabb1c@gandalf.local.home> <20250603102959.20c85adb@gandalf.local.home> <20250603132736.554f611d@gandalf.local.home> <20250603140632.168190f9@gandalf.local.home> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463770367-150941725-1749020632=:5058" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 70A4012000C X-Stat-Signature: 655mex8c7d541fykisxgo9kctcixjpem X-Rspam-User: X-HE-Tag: 1749020635-890996 X-HE-Meta: U2FsdGVkX18IkIQVgmJwabHcGCsleqI9yhRRxekq7UvjBCbTLFqT2NWYksYNaNEzpEZB7Fx+6Fz4G+0QbhI8cxIHZrXmjKLGjMrH9Dgvip7CUTP/0bY4o34vbpUEc5s3fZalnQlns6ckAwVvnAXi7D8G+dcmwh4h+xdpGpcKifqerF5bO4IkWa4ClQ6MYmMMAbB5ISgaZ+7grv4sGvdQc3mTBDVxmpMNAqVD+G8eY9mHSJU/OtUFQ7Niv5E2VOq78Xu6P0Pc43RTOGadnHe2KRUY3vsMwz/205+GeREofZEu+aM1smHU7Q4LNl74b6KCHj1Rc/WLmZquFDF64ksIyM+szlfN0bJqSvJ6J5yA1Dz+Az4oyAs0fZNwlrz6Mc0Oy7M4k5d334E6UOc9+ujP0SFdfW7TVYrAC5+KK+bDaFXIV+tLhUwPITM4PLVBVAAhyGbGV13eqMxD+7F4QRIOy8Y2axRjzL97r8x/8vwpSu4bJURKVWckwV4akrzOKGk2Ms9X8hDVkj/9ygJRWpX8ER56yct2h5GSY/A+AZDsDIK1SL1p6q+AzM10CcreuvqEhLRZyVm3XSm2GpbDhdFPF3BwauNJbUZdOjr43v0lMRQeViHwhjMrP3Jk5EAirjngWdRSLVP+CEkhLgcy/vvgAwj02OObgO3XgkqdXrnvDTuaxQgMNVHmFKO4iHNeFagLVf+k3o6do7scZkhFcy5unW68Q5LE1bpBaKH+oYEqfV0TfRi52Jz+TyfDntnScTxBgzhbSPWsb50I+BPe2q9ZbXAN4g3IpQfgiOWMe460qr8ib1mUCojMpBQVAC9eu61nfM1iUb9gUqgYNz2UsIcv6EENx2oGFihY+zbJ4HlbOg1YwhrVmLkvrWjSxZntK6e5Y41stMQB5jNMmAPPJQdyID52EymvhBSkaT73JdEhiCYV9HbkgVPVUWegSMyRwmomAGx54sjisWb7neruNnY t6tmTQPu 7i1QO8feCdvohgtGNRIF1JxjdYd4oqe04GC1s3NKtRGKnhiSFTx/xP1vKgjmP+bpD6qjDICZoikIsQa8XAzzAYyji9q5gsWgsYBzI0Yv48qcmWaS1iLGfQ8Em1jWHW7DTgsNBSHdWIQR2sFL0tbV4UmBh2zPo/jKmL8o7KV4yi3KS6H/9m1jq+FgBa+tugYSL4YEtb7SFK6jKXziU5/VsiT5mhjH8JmyZaLK4FuZzKnnAwMvGxTIVrm4Rn38zrmyZvGM1eKWMrfpn25/83TqNawVIXZStFVxpJht+kLLXtDHw6q8zgylXwW0iV4j9EL+aZWE0oNp9heyLVXQSTwgx+qLH5PL9XQ5O3qYb7V65AZMWASzCl54Zdz3yb7K1+fr8jkCUlvVLqquMx0Pb0+jke2zDFts1fAbm4/llRDOhQTZxQyNfC8jpvVNA91dUzY/71lOuqxnEM65Z1mXLCcZn1Qh6f8AQ6g+HRCJfq2dHs6LY2/R2lZVzDnEdrFWHiOBEtrwp2aFyLPhmDJXqF744PA+zwYygzFmN+lbyM9iHLKtxEO7dcWDKVYdY/khBVM+1eRwj9nDs84Xup3LoF/uAjhNY/fEahTxWMyDI 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463770367-150941725-1749020632=:5058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Adding Thomas Hellstr=C3=B6m, father of ttm_backup_backup_page(): Steve doesn't have CONFIG_SHMEM=3Dy, so now gets a build error because there's no shmem_writeout(); whereas before 6.16, backup_backup writeback would have oopsed on calling NULL ram_aops.writepage when CONFIG_SHMEM is not set. On Tue, 3 Jun 2025, Steven Rostedt wrote: > On Tue, 3 Jun 2025 10:54:49 -0700 > Linus Torvalds wrote: > > On Tue, 3 Jun 2025 at 10:26, Steven Rostedt wrote= : > > > > > > config DRM_TTM > > > tristate > > > - depends on DRM && MMU > > > + depends on DRM && MMU && SHMEM =20 > >=20 > > Yeah, except I think you should just make it be > >=20 > > depends on DRM && SHMEM > >=20 > > because SHMEM already depends on MMU. >=20 > Yeah, if I had made this a real patch I would have done that, but this wa= s > only for seeing it it would work. Many in drivers/gpu/drm do already "select SHMEM", so I came to think that --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -188,6 +188,7 @@ source "drivers/gpu/drm/display/Kconfig" config DRM_TTM =09tristate =09depends on DRM && MMU +=09select SHMEM =09help =09 GPU memory management subsystem for devices with multiple =09 GPU memory types. Will be enabled automatically if a device driver would be the right answer. But perhaps that adds bloat to kernels that don't need backup_backup writeback, and some #ifdef CONFIG_SHMEMs in or around backup_backup would be more to the point. Maybe add that "select SHMEM" line before rc1, then refine ttm_backup.c with #ifdefs at leisure? But I just don't appreciate backup_backup and its place in the drm world: it's a matter for Thomas and dri-devel to work out. >=20 > >=20 > > That said, our docs already say that if you disable SHMEM, it gets > > replaced by RAMFS, so maybe just having a ramfs version is the > > RightThing(tm). > >=20 > > I don't think such a ramfs version should just return 0 - much less an > > error. I think it should always redirty the page. > >=20 > > IOW, I think the "ramfs" version should look something like > >=20 > > folio_mark_dirty(folio); > > if (wbc->for_reclaim) > > return AOP_WRITEPAGE_ACTIVATE; /* Return with folio lo= cked */ > > folio_unlock(folio); > > return 0; > >=20 > > which is what shmem does for the "page is locked" case. >=20 > I'll let someone that understand the code a bit more than I do to make su= ch > a change. My patch was just a "this makes my system build" thing and let > those that know this code do the RightThing(tm). I did start out from the position that mm/shmem.c should provide a good shmem_writeout() stub for the tiny !CONFIG_SHMEM case. But seeing as nobody else has wanted it before, and backup_backup would have been crashing in such a case, it now seems to me pointless to add such a stub. Unless all those drm "select SHMEM"s got added long ago to avoid exactly such crashes, and a shmem stub is preferred throughout drivers/gpu/drm. I vote for the "select SHMEM", but Thomas and dri-devel and Linus should decide. Hugh ---1463770367-150941725-1749020632=:5058--