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 AFC24CF3189 for ; Wed, 2 Oct 2024 02:04:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F99644016C; Tue, 1 Oct 2024 22:04:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 381E6440168; Tue, 1 Oct 2024 22:04:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 222CA44016C; Tue, 1 Oct 2024 22:04:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E72FE440168 for ; Tue, 1 Oct 2024 22:04:28 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 49B41407B6 for ; Wed, 2 Oct 2024 02:04:28 +0000 (UTC) X-FDA: 82627017816.28.3554F33 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf28.hostedemail.com (Postfix) with ESMTP id 85820C0009 for ; Wed, 2 Oct 2024 02:04:26 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WcRoWrKC; spf=pass (imf28.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727834601; a=rsa-sha256; cv=none; b=0gDPgCfVYPbKL4mlWMOjrD3LbhUNFHNDtha0MzAWsSqBInLCcsrHbKuQ9zrD6Q2qA51Dzn Gp1q6kgtcZtRLA/n7Q3l1qU9NYp5DiW3RpAGrmqlX0uy2bqHWTgykUtBWjNG8z4BXz0vS4 O7zejxk3G9xJDy3IdbmPwc5Eajs6L+E= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WcRoWrKC; spf=pass (imf28.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727834601; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rlF+vY6/5ObD1JIeV01tvrzQ/SwRs95L/nLrr93gG0c=; b=108QgpCu4cHgixTld8UInmpViBWzDXp5Kn/tHdTiG16WNB7gfYLd6Kuyq/AqkvvRnho3AD w8C0QJWXH8wK69kbgckmAugG1c5p7/fo4H8NmR0t8m7nnz2MHlSnJ8ENWulO24dT0dyyzJ rvAE9QihuYq/OmZvp1AwGYgHopZ4Xug= Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-7ac83a98e5eso38188785a.0 for ; Tue, 01 Oct 2024 19:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727834665; x=1728439465; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rlF+vY6/5ObD1JIeV01tvrzQ/SwRs95L/nLrr93gG0c=; b=WcRoWrKCSlEVfQEHQ23fS8/gFlsi6WZhF6jwfokUFDdtmM3aCimRvGGuaJGrvhVHEy LlbX3QKQE7PhJ7a2mooVViBzclJ6+7XrY4KTYOyjBAFEp38oyf0Wkh0+sI7BVDUiHm6l czCSKY0ApOP3C/lCOAbUqK+GDbhELMDnwO9t3zKwLwhBCGVOOwNYk7MWR9e6BlZ+KMmB GmA8lRyrlbPy4yyo3xTPAa84EffA4dE0N0a+EW+X/f0BPfktXQ5r8Xg+SgQdc28gjAF9 OgD7emVLVcpXaZ3b7bWYp4E+jhi5ib18kJagzqHXZ6Y1KYD6dt4KK9BFa1jwpdIWgbA+ 0HHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727834665; x=1728439465; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rlF+vY6/5ObD1JIeV01tvrzQ/SwRs95L/nLrr93gG0c=; b=NV365YprmtVp+0Con3N6gEJZDTr0cwk/RfEl9CFB9wDZ72KIAoXHw9RXab12sy6GLF W6JsfJSNg9PS2vgeLn0xUSUkGSoKaUyHZEvhOMLCdNz7CI0Nw+9G5Q9MfpVehDwisHxX rbBFKb12Ru5VAr/qk1Xql/jhCWYcAduZtV5+eCgC4a6tXGknBkw5qPnbTCtDorqaa9+b CEdT4YBSvtcjDT254tNXtucYdlPbFVhw/j+KPij89bQ1yrlrNJ9LXTyckfbU/5ME1jAS 7tsENfxXrs6I7mQCg5AawPAj3ULXare16RzwXYmqAaisBKgD9pT2hAebSy2Gh60lP/fK aM2w== X-Forwarded-Encrypted: i=1; AJvYcCV4PAtJoz1ZKFfsFoPGeJhw8e6paxBY/2TbZo7las8aGebVTB3EoLHeYCxOL57m64IOABnEEnuO7A==@kvack.org X-Gm-Message-State: AOJu0YyBSpB7REd/IZdIX+n6afoXLFYsbGcuDWQlqoxwS7No8AnmWHGm pk+vPt3GSyuXfFgruaSLHkmAGXDYoSdvFPtxpSrEi1DXLXraeDBQkdpHqOll35YFLyHtFglx2O5 mqq5nDTLqIdRCKkK0r80bs1J+8Bs= X-Google-Smtp-Source: AGHT+IGyxL3vm0uBsZxQ0LGmaJ+qosmP4coEuiaqBsm1BBOIBXNV8by5vq6QxtiOzRXEWSo3AzmcFx/sm+Z5ysn/9Y8= X-Received: by 2002:a05:620a:45a2:b0:7a9:b4d2:9d68 with SMTP id af79cd13be357-7ae5b853bcamr895222585a.22.1727834665475; Tue, 01 Oct 2024 19:04:25 -0700 (PDT) MIME-Version: 1.0 References: <20241002012042.2753174-1-nphamcs@gmail.com> <20241002012042.2753174-2-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Tue, 1 Oct 2024 19:04:14 -0700 Message-ID: Subject: Re: [PATCH v2 1/1] swap: shmem: remove SWAP_MAP_SHMEM To: Yosry Ahmed Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, hughd@google.com, shakeel.butt@linux.dev, ryan.roberts@arm.com, ying.huang@intel.com, chrisl@kernel.org, david@redhat.com, kasong@tencent.com, willy@infradead.org, viro@zeniv.linux.org.uk, baohua@kernel.org, chengming.zhou@linux.dev, v-songbaohua@oppo.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 94ysw15ithhfs8nxwrdnugugmyhneed6 X-Rspamd-Queue-Id: 85820C0009 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727834666-787896 X-HE-Meta: U2FsdGVkX1+oxxovtI/No6vm6FH5ZpDQY4pSErKVqSyZ1UKdi/P0WUJI6ObTZZBz28p9xA1Cz6o4cb/w58vm/4yd3BLnQSghONzSifRRMN7AgQFseVXuQJC0yYn2gHSTie+i4fLCQjQktU32m786wo4p+f9colvjn5Qbha/8AvXXvQiS8oY2oegcCVfqQ4mj1NiXj2FmqRtVq+TnsQ6bDrKAjp6CuqYqfzzeyaJwpCmDgOHtC3r9KHw9igyKkMHKp9EfjulG0FfuXj4EiFzeGTWVtXgAP5lSMywlGObY4+H5lqhujDZXSXd7fdgCVv06m9LsihBMHiF63+OVwT7KpDzreFIw6QQysM8mCZrDYtqeL/8i5VaBo4Tx/V2VgTX5qrhgNVCd/HnxzNpMTYTwkGH7tS57Hm9ASaRgWmX8RyFeHntHLoYi0CwDu9KKFBs1s/TZpaWofLMltopN7GeWtTtSY3Lm+F0WA/CRmHf5qayBmtXyWxZoSs5uT4fxS0N0JYoqcj40Fnzf1/zsmx5tG/3gPRkBCT3Zlo6Qupdf0K7U8ANFZ73msOon2Cz8Z+d7BfDiDRGYSLJkB5qrqA/XUzbZ2fG5v6YMNA9gITD7W86BNXKJIfiOL+YoeXDQ4co+Xa1EdQnRDvgj3k2Ke0waXtxLr9wa9vLUARab+RFOsh44G28cp/xC+fZopBTVIZCv1Pd7eliJ8ig/tlc8jFy0FgMT2EKpuH/9ekgZyGOx1ZaPGMlaEUuIDJWDBqPJE23Mtm1PWv67LNkbLkgvj4o5ECbHU0AAp2NWubNdM11Iqt5hQEov91I6JGJIf4j0Sw+9F7tdd4Z9okugrcUS+K/OrwKm0VMY3MH/WJfvF5obOnV3CQguaI7GWDPDeTlRBZEa1fmarteLtowTu+os3OXofXSIBNCc/u0Z4mErYPamdO9DMzPnUMOeitOHf2I2+FYAuRKBHT9zWAUg/gX1PHX 2wrC4pVl dlAFVpnOD+uqhL2O/Mbd/10VihupHd2yHfHTcrshEoOzmitfZEDr86eczDs1Na/xRF/77no8ayxLL/tGQaOuIMyMFyjvZaE2Tu9HkkUO2vEieng7SBr6fnvTQMRhTG0akUTqKuWZ+Cnb7SrmyDX2H++QnAw01eWlfKCNs6i+Ngsrh+GNYUgKL97VL/9kZ50nL+/NmfL7Ihl5yO7ofPc8q5N76yf5dtbQTxTm2iYQvWU3Iemtc9SVIVHfgjMyed7303BNkSEOF2t4pWm3BpyeSApmazUphYPyCWmq3xYfLwdOms1GgxI5s3ITxGJqLkCnE1XS+Xwm+y9VeWgihdg651n1801PlCH90dVRxgfhX8uyfdcI63yOXrFtmHpYfCzbZKKz46OjwLYP9aAfUMTCZkH/B5gZYJaFptbJi X-Bogosity: Ham, tests=bogofilter, spamicity=0.103037, 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 Tue, Oct 1, 2024 at 6:58=E2=80=AFPM Nhat Pham wrote: > > On Tue, Oct 1, 2024 at 6:33=E2=80=AFPM Yosry Ahmed wrote: > > I was debating between WARN-ing here, and returning -ENOMEM and > WARN-ing at shmem's callsite. > > My thinking is that if we return -ENOMEM here, it will work in the > current setup, for both shmem and other callsites. However, in the > future, if we add another user of swap_duplicate_nr(), this time > without guaranteeing that we won't need continuation, I think it won't > work unless we have the fallback logic in place as well: > > while (!err && __swap_duplicate(entry, 1, nr) =3D=3D -ENOMEM) > err =3D add_swap_count_continuation(entry, GFP_ATOMIC); Sorry, I accidentally sent out the email without completing my explanation = :) Anyway, the point being, with the current implementation, any new user would immediately hit a WARN and the implementer will know to check. Whereas if we return -ENOMEM in __swap_duplicate(), then I think we would just hang, no? We only try to add swap count continuation to the first entry only, which is not sufficient to fix the problem. I can probably whip up the fallback logic here, but it would be dead, untestable code (as it has no users, and I cannot even conceive one to test it). And the swap abstraction might render all of this moot anyway.