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 B0FB7C021B8 for ; Wed, 26 Feb 2025 16:45:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33D076B0085; Wed, 26 Feb 2025 11:45:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C5466B0088; Wed, 26 Feb 2025 11:45:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13FAA6B0089; Wed, 26 Feb 2025 11:45:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E77626B0085 for ; Wed, 26 Feb 2025 11:45:37 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7F150B773A for ; Wed, 26 Feb 2025 16:45:37 +0000 (UTC) X-FDA: 83162671914.07.556B49A Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) by imf12.hostedemail.com (Postfix) with ESMTP id 3505C40025 for ; Wed, 26 Feb 2025 16:45:34 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=eJfriWQZ; spf=pass (imf12.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740588335; 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=3Ltc6Nrepc04jaCjrI+QJSTPw7Gz4OtZN8fv65LynWE=; b=3x3BtJW6fTqv+cECGofwdYToyYuLaK/qAW9MucyVB6OVhXbqdz3rpxBxzwZuBF2JXS9TVa 2h/r+o3j2Ruaj6idx9iB+p/2WjUq5B+bFkcFqSLRq21JpIiSLCoyTSnQa1k+fkrvHYPd/1 89xKNvHQXA4sPl8rqF/UgnC9YjXkvTw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=eJfriWQZ; spf=pass (imf12.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740588335; a=rsa-sha256; cv=none; b=ZUazKoaj5toAU1tnB660wtqpFa0Go2hx/vE+CC9LN54iL8xmKKOrQUHz4AcBCYhj1BRwUg SsFsLexGIDlVmI0EyZ0RlZVJCeKIL/BeiFbUq4A9jTGhPLYW3WlnZDOxmKOrOU18KcZdZA sPHl/wA/W/eeONbJjWHpB8utQaDySkU= Date: Wed, 26 Feb 2025 16:45:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740588332; h=from:from: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; bh=3Ltc6Nrepc04jaCjrI+QJSTPw7Gz4OtZN8fv65LynWE=; b=eJfriWQZf4Tt/jOznTwKWWClO5fXKDgVtMW2VCBjL8QeyXfFyVPKNeSZtu18grXZGhPqha +3FWLN0NkTDQ3p8bJb5sVm+wvsDyOiNBTuHs6HK9cjYJRtJ++veq8Q/3N662VT95zC807K HIKj+HZeA/olEAX2Ru0ext5IFRSO5AQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Ira Weiny Cc: syzbot , Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, chengming.zhou@linux.dev, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [mm?] kernel BUG in sg_init_one Message-ID: References: <20240318204212.36505-1-21cnbao@gmail.com> <0000000000009221d60613f58726@google.com> <67bf3ad9ac2df_41ae42942@iweiny-mobl.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <67bf3ad9ac2df_41ae42942@iweiny-mobl.notmuch> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: go7m41bx9j11xdosnryqxjooxsiqu1gj X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3505C40025 X-HE-Tag: 1740588334-873548 X-HE-Meta: U2FsdGVkX1/RlFxo/36UXf5bdtUVc+B50+4VRjR60RlbGz9AdmTJH5dNcOelqS6ZyGOFiVSurLxom74nMPDWvPRZFQ5rpLBSIc6NtJr6i4b8i0YYEZXvKoPNZWONlwmCHxbYYTltbhFtnPw1uOnccGg2TmZXBQdQPQDsPuN7R7DiHIYY6o6zaUip9b0GBwQ4qq+DH/EejS29r3BQFHqIweUGYtQ2cXKYMwQwVo6diAr3ZpciFq+YIAGxgq/1p7kVhofDBupD1ZzIBJogzZj+G9p6dQVoQWdcHl+V2HI3qz3O1ZDk8NS5BOU2YIrAPKsXuJzzVmR7s/hHf4NyEVgMVkTZjKKEUhbJemUyZYS3YfXjM8Ujf9eqrLdHzqVKY716+48JUVV5yz84XrOAnr8CdbKH61t0klS06QI/1r2axWjF6yJkSLhyMNfPfCmD1suY9T0WlPcj4RtUZzT/6mzuB0NicMoJ3LFfb2RRQTDgDtELb6mtWAW+1A0X6Q3oWtgoWPwWnzstVOh82bSL+RWMjJDjTgOmzUEQ61kFhgcBpYyRuVqjcPZQD5CHKZ1nR5+VBmZX6OCxaRi6EnR9vDdkeSENvhI/nOTWv8DnHrvzJLxC6xjVvfTGKE7W2t1UZWhj+5VznpdUfe4yR6H0yShskIHjXZEEfaB14sUpl1qaiTRVtW35gX2msO7lT1qXz8606RX054ZPYO48Tg2xl43T2nNMYJfX7+D2aht4H3c3h3F6Ozq2XB5741HEfFT/vecGfwpD2V3DJH2ztNPsdFO/radaLqXBGF6U2FaMOfPja+6WWw8ahZB2iZW7MwaJ2YmADt/4Q+hxS2M47Mg9igy7A0qE/nBcGgoqmcya+qK+KcI0GwtY+m8+voCLA/pGomkEwaHM7dUVUHl/mJ3BJ8pqxvw1Kq5u7OHLxXdenOMcgdSldiDw3mQ6FCDvdW00f6921az6B7JazJxxFshLjxP W4gsxgtu fbLESEereKB3JhkiAfQfGBcaeNp0+d34qAuKRr+97fLwR2/uW9UAu0TRQ6SVgoWUoVDzwPS+EL2tDm5Tb2Uv2ls4B0vPnvbT2L5ZikjH1GVB7PG0SYFnJfFoHISZgzxrw7uH/68gRY8tc5psP0g0XwDRZlH6FCtLhTmvqk4JoYvqlpVLb/VCoiVI0zTpRvZHpilok5CyReQDmElwpk3ZoCGq9eovu/1OxxKYuJWDtwKu16OFnuNhAClpDlO6qghIFQkYb86hyLWDGd2+SufCN3BFuwJTziny6GuLxVnVF0Ns7woNovEqpunMbpWjmPcnmTGvbyu8vhdqbYUBm/HviAhYBf9Zl5GyazqH8FAgpV1ZC21C35/04xGU2cisFWqiZHBbjfx0MEce527Nki0hH8HXRlfOxx60UGrzXreYNATgaVlEAZ5OCXwM/HYICAcC/NsXfXTQuvID1N6qsjVaZUrSiG3P1QnToEOniwiqr+eGkdxnbU+qbX1qhktxfxrJF1XR3u7V4nxoWmEFhBJo8pwcrI08K3gsvscWwf7psxJ17BnqqflvKUitQ2mpfz64ui0axZZrzeGm8oP+wSauACTC99g== 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 10:01:29AM -0600, Ira Weiny wrote: > Yosry Ahmed wrote: > > On Wed, Feb 12, 2025 at 09:20:24AM -0800, Yosry Ahmed wrote: > > > On Mon, Mar 18, 2024 at 2:03 PM Barry Song <21cnbao@gmail.com> wrote: > > > > > > > > On Tue, Mar 19, 2024 at 9:52 AM syzbot > > > > wrote: > > > > > > > > > > Hello, > > > > > > > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > > > > > WARNING in __kmap_to_page > > > > > > > > > > ------------[ cut here ]------------ > > > > > WARNING: CPU: 0 PID: 3529 at mm/highmem.c:167 __kmap_to_page+0x100/0x194 mm/highmem.c:167 > > > > > Modules linked in: > > > > > > > > + Ira > > > > > > > > Hi Ira, > > > > > > > > I noticed this warning is coming from commit ef6e06b2ef87077. > > > > > > > > you have a commit message like > > > > " Because it is intended to remove kmap_to_page() add a warn on once to > > > > the kmap checks to flag potential issues early. > > > > " > > > > > > > > Do we have a replacement for kmap_to_page()? The background is that we > > > > want to pass a highmem buffer to sg_set_page() but we only know its virt > > > > address. > > > > > > I am reviving this thread because new zsmalloc changes will make > > > mappings sleepable, which will allow zswap to drop the memcpy() in > > > zswap_decompress() -- except for the !virt_addr_valid() case. We can > > > get rid of that too if we can use kmap_tp_page() in the scatterlist > > > code. > > > > > > Ira, could you please answer Barry's question above about > > > kmap_to_page()? It has been a year and kmap_to_page() is still around. > > > > (Trying again with Ira as the main recepient just in case) > > > > Ira, could you please help us out here? :) > > Apologies, > > No there is no alternative to kmap_to_page(). The work I was doing has > stalled out and I really don't know if it will resume. > > There are a few folks, like me, who would like to remove highmem but every > time the subject comes up someone speaks up about a rare (mostly embedded) > platform which really needs it. So I don't see it going away soon. > > Removing the warning could be justified by saying that highmem removal can > be done completely within the kmap calls and only when that has been > completed can these calls go away. But generally kmap_to_page() is not a > popular call and it might be seen as a step backwards by some. > > For example: > https://lore.kernel.org/linux-mm/20221216070621.GA24832@lst.de/ > > The patch with the warnings was a stop gap to ensure current users did not > break. > > Do you have evidence that the extra memcpy is bad enough performance that > you could justify using kmap_to_page? It's not about performance, it's about cleaning up the code. Currently we have a special memcpy path [1] with a huge comment in zswap_decompress() to handle zsmalloc not being sleepable and the kmap case. The zsmalloc case is going away soon, and we'd like to remove the special handling completely. Using kmap_to_page() will allow us to do so. As you mentioned, this would not be blocking to removing highmem. The call can just be replaced with virt_to_page() once this is done. If this is okay with you I can send a patch removing the warnings in __kmap_to_page() when I start using the function. [1]https://elixir.bootlin.com/linux/v6.13.4/source/mm/zswap.c#L1012 > Ira > > > > > > > > > Thanks. > > > >