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 26078C021B8 for ; Wed, 26 Feb 2025 23:47:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AED816B0095; Wed, 26 Feb 2025 18:47:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A768D6B0096; Wed, 26 Feb 2025 18:47:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C9776B0098; Wed, 26 Feb 2025 18:47:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 677626B0095 for ; Wed, 26 Feb 2025 18:47:21 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 103891A10C8 for ; Wed, 26 Feb 2025 23:47:21 +0000 (UTC) X-FDA: 83163734682.15.9537F8F Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf14.hostedemail.com (Postfix) with ESMTP id 379AA100009 for ; Wed, 26 Feb 2025 23:47:19 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Wz2p3wh2; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.177 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=1740613639; 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=liXUNycYFC9vjDNrycuN+V1sVb9jvR/WsQuvQlMOVkM=; b=C8imJuOgfRX5tQnBizYs7uAJPpIJf5CPaOUovSveGVLWOWOOqGEiJDsquCWLBa8iyP2UGO wCIeuWCModKU99A6oW7nHOyL2XXMzeRZGJzPxHyrWUHcIr8HyJX4Wt0zPhqcVHcwZ+o4YX fgX2vuwvB1HUpE46UqJcEYomH6CnX9Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740613639; a=rsa-sha256; cv=none; b=TYpcTQYiRH0ikMvyIjARwe3EpMTuH39s+4wBdhcMD+uRRIIXD9nksRqrHEzhRkbfCHnrqs 2AuFWCv9HwH26ielbRxzcfK9oIb0Dj6HiScUDw7xoyO4Gmm54V+a3RmVHH/s/U7lRLbSBo Gak9kjzK8LbcaTesqBP585kLgIFU6jQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Wz2p3wh2; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-7c04df48a5bso38653885a.2 for ; Wed, 26 Feb 2025 15:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740613638; x=1741218438; 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=liXUNycYFC9vjDNrycuN+V1sVb9jvR/WsQuvQlMOVkM=; b=Wz2p3wh2x/Rxdcl/W6moRW0CVhhUd0qfkfRDCeUAm3+3vKcgdIBRGSyFoqlsIZUPxH FEy2oCzRWKCZeysOUvE87S4DVAHr+ppGiEfGusq4GU0ZEec+IIW9GheCo8aIEEqmtJkc MLOYxjdsA79MMfTkK8qlSxmjAIIuz6t6Pfo9oLu8gfdUEdK0y7a8YCqlCErPqxeP4bWj 8pBzqtZ6+OFIzQ7IWfyzFyoErRNUwHaSDx7LtUwMughKS6BxeIe2IeS5cIWwraLxOFNd Q3CmPBDZDGX3qxqN2bteFlXeBB+cTUhaamziZy/IYhu1zxAIFGyXgyiLtNdckXz0bWpj yVnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740613638; x=1741218438; 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=liXUNycYFC9vjDNrycuN+V1sVb9jvR/WsQuvQlMOVkM=; b=BuHEEafAyDP0UkTA3+23bDZOIF8dUBdpMqwQohe5nkdzRZhRcq3rLW91POsnVAiKRf OaLi8tQcI+5oq1tNfXSE7jWRoWK5NDaVsoPo6BW0AVWPhOHOnWLVJ4lIyUG6pgwRLHTE WCXWdcS1yC+mA75xjx5d5EbNEbQyojPmgIb6igfkh9Xz3ZJN028ORkdvk6yc4BvuLdcs 8wm7wg5nA2uy5PqVPY7N/rYG9eqw7x1+PbpfnYBnafrbrq2iKS7FGcnzmNFKYxag5Ytl xWLGevmDG5OkS4t2QeshdQcsyZ9PRi+kvfiI2kAfrarcy5eCVIzowXQnwR5uqikEna3z p9wA== X-Forwarded-Encrypted: i=1; AJvYcCXCgKy34nA3L8lBT/OLooIkS10sy2lD9zrNXesXJw3A0ZhAM2/J1jLASvKP+DvOx0qEOEJHj0oHFA==@kvack.org X-Gm-Message-State: AOJu0YyCHGZZjg7uAeP/3TCniqJ1nRhX++8uGNUWnHOiEX2Su7j314VD fQRM6sPMp/vcZ6C9aYkQkSrUSQrPAUuydjPRUTRYSoEQggSkaxe9RX/zi1Vca2zk7/EvrIGtjlx faeXD4j8iCieP3Mc87UVoGThu7ZY= X-Gm-Gg: ASbGncvnP20sTBNpZHIueuwTSsLhqE9h56TcmVJxnCaKtY98q5pM76moAnyV2SRD1C8 WNB6JV6VnIcqbSnTsx6U3QOxCMQUGX+knUhFcB1TcxSLfWKULa8Epj21Vn3ItMWwHdYuwJQixkE untbO1a26HUBaX/PClju9utq0= X-Google-Smtp-Source: AGHT+IFaza/mzOY4P7cX85X8N+cye/wkhSM/zT8ahz1vKD1VMVe06emD5Zm7qAX9AxwOYAPP284uKjDZVdQ8M6xLzmo= X-Received: by 2002:a05:620a:4441:b0:7c0:99b9:c8a3 with SMTP id af79cd13be357-7c247fe7836mr819662585a.58.1740613638270; Wed, 26 Feb 2025 15:47:18 -0800 (PST) MIME-Version: 1.0 References: <20250226185625.2672936-1-yosry.ahmed@linux.dev> <20250226200016.GB3949421@google.com> <20250226211628.GD3949421@google.com> In-Reply-To: From: Nhat Pham Date: Wed, 26 Feb 2025 15:47:06 -0800 X-Gm-Features: AQ5f1JqW3YIJaViBWFvZwwc9Y_BLX9n108G7cgjKGJSx-48v7AmcKBwq4pCS8uY Message-ID: Subject: Re: [PATCH v2] mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead() To: Yosry Ahmed Cc: Eric Biggers , Andrew Morton , Johannes Weiner , Chengming Zhou , "David S. Miller" , Herbert Xu , linux-mm@kvack.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, syzbot+1a517ccfcbc6a7ab0f82@syzkaller.appspotmail.com, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 379AA100009 X-Rspamd-Server: rspam07 X-Stat-Signature: 5yao4kbn7j6gbgywpn5ty18joka38a9f X-HE-Tag: 1740613639-723330 X-HE-Meta: U2FsdGVkX1+hK6yH7AEeFoy3hpcAhsoxIviyDuGJep8ZQVFybVaRyqaR5MJZQKrLPlVunQ/1DUTCvr+xEWOxNg4MSriObxeibfsN36HIH/GojUDbypx1X2hCacE5MxL2GrY/12gZ3v8d/aBA610gtYAMg45ReoNSjb5IAuxjDok0SjswN0ryJzCJvem7zKzD+aSBYNmPKiWwlgjZ1O3SbQUt5cUjKxoWVzNpriltE2OfGcbhbgXK5g12m3HhOIwwzFF7N78QMvQUGeeEYFAfDsXnSWoWFX+ZXzWFmTbH3y7J3KQbl2KyMtOZxBM1Ucq0GO2YaPgvKe1UiiLB5QbEzNiuXNKn7y67HUsHEADkNHdT6MtGSBv93v30l3O/Y4oLfLa24x6KTX/y6WftrR5p+nrgA2EeR4bkjAFspLSro/dIUV+LN3ZNA8nNCxj5gAy/a9FhQ5IpTCTRE1N+W4KtBQsnmBXazSQBo6GLIasT9kicJkhGZFPFNhuwK2Q1WEDTZRTrrrjCERFs6XQUpqNZhH3z0vmMDbpuDoBFhhsVPLByiXnC9D9+ElzbtM+SHyVl9LFR8oJTAG5I3rpcSlNSN/MkcdHBbEGRAbQTnVWohU2l51CvxvwX6OcsV2GgBm7c5NY2XNJPyiLiMQvp41631Kw50T95hCVJv/O4dL16VV5bqG4SsxaF2SejDF6cHLQfNSzH4Ys5jAYz5W+OuwBK1wRvDDI2Xlq89qt2O1hamnrwrFQqbQWTCHWw2l7yyJU0SKbGkgwRN1uZtgn99NLEr53BZ0n3qAd3gf7USkOEdiJWGMKmRegwdcDrFYCqf5r0+GKNtWNTJzcj3gJSuTv3wISnTKEbVN17RV68Lf430ULMrG3R8azjQurRI2srKNx6XXaI+WAesdxNfpzhgTKOX+wSIQBcONh0b3PvTpAAPeqyU5ZLTsWBK5nTERY2GorsjZaJoqNvaR4QfC7HHqv 2tMGNvVB MVGDW3V7efDQYLkJVfmFvljfa2rMJgXRLH/otjCJjaBujK2ac0uVLGH+0j7OD1DvLkCOeb+4AurIDwjgwWKygs+LGy2d07t+WiO6N1AF8OzTGw5gkqZXRrlAjFLvtCr5b/zo0ny8OhTIZK4qe8dZHALR1D9tyeOOgI/q6qP5znhSIZShICMRxligwr3QhY7zq1m1kjpCYaKrzCz8yJp152P2POyLBJ3J9z7qtVQKzPgKDEWtraAwZm8wc/Fud2eM/glj3G47gH98+pctLzUfj5npEvY87KajRZbbEjM2eDxHhrCX5uik9ReTIwLiJc46sW44IOQyuFzrJewKh5g+8MWOecJy7nElZXRljcNoQ0Y2TY1bFOFjmiCNb2GSPAXVbGMQhC1BkwN0jEAKxRStMEM3ULzxr+X+PWlhf0l18geRsIX82iN0MhYCRiqeDSrdcR0oCjQXZvj2jREB1QOfzEuEHI4zz5z0FMZ8D5B2yGE5nL9AZ/YeT1aoYnPcCJhbHNEN65B753g3ncQiti7PfnWLfyBNKL78AtXUPnHNipoH0z7E= 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 Wed, Feb 26, 2025 at 1:23=E2=80=AFPM Yosry Ahmed = wrote: > > On Wed, Feb 26, 2025 at 09:16:28PM +0000, Eric Biggers wrote: > > On Wed, Feb 26, 2025 at 08:32:22PM +0000, Yosry Ahmed wrote: > > > On Wed, Feb 26, 2025 at 08:00:16PM +0000, Eric Biggers wrote: > > > > On Wed, Feb 26, 2025 at 06:56:25PM +0000, Yosry Ahmed wrote: > > > > > Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while = holding > > > > > the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp= _lock > > > > > (through crypto_exit_scomp_ops_async()). > > > > > > > > > > On the other hand, crypto_alloc_acomp_node() holds the scomp_lock > > > > > (through crypto_scomp_init_tfm()), and then allocates memory. > > > > > If the allocation results in reclaim, we may attempt to hold the = per-CPU > > > > > acomp_ctx mutex. > > > > > > > > The bug is in acomp. crypto_free_acomp() should never have to wait= for a memory > > > > allocation. That is what needs to be fixed. > > > > > > crypto_free_acomp() does not explicitly wait for an allocation, but i= t > > > waits for scomp_lock (in crypto_exit_scomp_ops_async()), which may be > > > held while allocating memory from crypto_scomp_init_tfm(). > > > > > > Are you suggesting that crypto_exit_scomp_ops_async() should not be > > > holding scomp_lock? > > > > I think the solution while keeping the bounce buffer in place would be = to do > > what the patch > > https://lore.kernel.org/linux-crypto/Z6w7Pz8jBeqhijut@gondor.apana.org.= au/ does, > > i.e. make the actual allocation and free happen outside the lock. > > I am fine with a solution like that if Herbert is fine with it. Although > as I mentioned, I think this patch is nice to have anyway. > > > > > > > But really the bounce buffering in acomp (which is what is causing = this problem) > > > > should not exist at all. There is really no practical use case for= it; it's > > > > just there because of the Crypto API's insistence on shoehorning ev= erything into > > > > scatterlists for no reason... > > > > > > I am assuming this about scomp_scratch logic, which is what we need t= o > > > hold the scomp_lock for, resulting in this problem. > > > > Yes. > > > > > If this is something that can be done right away I am fine with dropp= ing > > > this patch for an alternative fix, although it may be nice to reduce = the > > > lock critical section in zswap_cpu_comp_dead() to the bare minimum > > > anyway. > > > > Well, unfortunately the whole Crypto API philosophy of having a single = interface > > for software and for hardware offload doesn't really work. This is jus= t yet > > another example of that; it's a problem caused by shoehorning software > > compression into an interface designed for hardware offload. zcomp rea= lly > > should just use the compression libs directly (like most users of compr= ession in > > the kernel already do), and have an alternate code path specifically fo= r > > hardware offload (using acomp) for the few people who really want that. > > zcomp is for zram, zswap does not use it. If zswap is not going to use > the crypto API we'll want something like zcomp or maybe reuse zcomp > itself. That's a problem for another day :) I'm actually thinking whether we should expose the zcomp API and use it for zswap. There are a couple of parameters for zstd I wanna play with, which zcomp/zram seems to already support, but not the crypto API (zstd level, dictionary, etc.). But yes, a different problem for another day :)