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 35363C021B2 for ; Sun, 23 Feb 2025 02:42:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCF086B0083; Sat, 22 Feb 2025 21:42:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B7F206B0085; Sat, 22 Feb 2025 21:42:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6DBA6B0088; Sat, 22 Feb 2025 21:42:18 -0500 (EST) 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 8961A6B0083 for ; Sat, 22 Feb 2025 21:42:18 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id ED9A3141E13 for ; Sun, 23 Feb 2025 02:42:17 +0000 (UTC) X-FDA: 83149660314.14.2AFE709 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id 2F317A0006 for ; Sun, 23 Feb 2025 02:42:15 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=WSm0Ox81; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740278536; 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=Wc7Z0C11VCJFYQ57krjgsaNwLdklCNggyK9O158fz1g=; b=tyKDAUKbgCZfk/T9pomM5TFSuSA4vCrvrtu2Q5nyp6qdHT5rwkJQQsr1aZn5iRSY5i5thP 865GY0SVlJR3FSRskXbJ25vUdkcD6AkabMyB4Lm3zz2JK+F26PKt5tU5/YcBzFTTTfsQtM NKSr/ieafce4Usnt87sWHXyD3d+1GLU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=WSm0Ox81; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740278536; a=rsa-sha256; cv=none; b=umVflWPq861lRN2xoLGCvyLrWVO03V6ZSZVrPsNjpysfHDi7+xF0dPFB5eDv5Nt89wR9/u Tqz1EbNJWPiz4MFBGKQjQBRFEkqG7RgSWvrykKCJHfLrWq+63edz7BNQiPhSYCRy+tMBBt GTkwkx0C6b7fKHtss7S8nUfsgqtL/N4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Wc7Z0C11VCJFYQ57krjgsaNwLdklCNggyK9O158fz1g=; b=WSm0Ox81k5GehJtP7NwLYMw+Av MJp1BllrBn3mRVssCWlxg1sl3FW0w3CFmGhV6LDRoAkv9d2e9aa53Sbv+a+IiYC0+/JKJ2sJ0pkdy QvOwxvLNPQedGP8KVcJBtO8zwrS25EzKGZKsza/w5+wxLPq684U4pOFDKCkb9fRj/nZmxrcD11Q/V VzKVJ7N3uDPkJM2VhXj+DjHpn1rTb8QMbUbopAUUFe1k009vlH4MbVdb24kPBdsFW6I0f4xM08iEi HmFDYXjoW1Ru0JSwL5Ge1l+TNB4Xql4vJkKsU0I8aXS6fpAKEBfog2+F0uClAw+5gU+9nXDy3M0gd caJxKFIw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tm1wO-000000023c5-1TKn; Sun, 23 Feb 2025 02:42:00 +0000 Date: Sun, 23 Feb 2025 02:42:00 +0000 From: Matthew Wilcox To: mawupeng Cc: akpm@linux-foundation.org, david@redhat.com, kasong@tencent.com, ryan.roberts@arm.com, chrisl@kernel.org, huang.ying.caritas@gmail.com, schatzberg.dan@gmail.com, baohua@kernel.org, hanchuanhua@oppo.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: swap: Avoid infinite loop if no valid swap entry found during do_swap_page Message-ID: References: <20250222024617.2790609-1-mawupeng1@huawei.com> <2c7dfa44-266a-4aa6-9401-7528368f171e@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c7dfa44-266a-4aa6-9401-7528368f171e@huawei.com> X-Rspamd-Queue-Id: 2F317A0006 X-Stat-Signature: g9tabqeehieitrrkhmny96b11moj89n3 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740278535-572876 X-HE-Meta: U2FsdGVkX1/lcLjSMqD6eW9h2RKKtoHkoUCHM/j8R3779lXw6fLBcHDo3rMmBQlpwfUnRuluPUTA0Zpr9MrSrUFMWx/QmbYvBEz6qqdyEUuj6yUL2rU6dWqJmaZvswsN/GJHmvgMIAYIijm4Gl7DIERrn3ncqtVOTkcPnVz0kqln8OI0ZaqfMowKBFXu1pkPY9pynz7BhviLWpSZxtLKQVVjxOCFiZrL3bAKXQ9puZl7Cx+p+1RUgPXAyIbWtlqADcQYh1smhvA0Sp77/cCQIPWsxqmIdF7ifHo1QssFjbLM/9eXe0NExx3QqVDhNVjdB38HjU9cKRGENOMFGXidC5pY3zX2Xydj4WXIC3ZbFBKdlZbbHoXvDFGrRQPQH9LXxp8hJcCx2/ehbZtC7QWyMUy++UKRlWELHxoV7n/IPLEql29cUh5sgs3YQ5PWzdrcv+JCspEzY/4lMs9/i80enxsG1ydUi+JS9GOSO23fLLms7RH+dCC9fOBJc7kYWeoms1dQPIVIzg0CRTMf7X1OdtkOjcFz/8dbpHiDbkkm5ORbNTi5kIwt1mhfQ1HD5lyxisjGp23VVAdorvVK0lGpNc9MN6NHfucKQ4aivQgIfPb3Bry4n8lk3fhTIR61R737HsoaCkWMtTEez1SbxWPxA0QUOr6n/MYBpbzVNqQOOVhtoeQCjeYJ9RzqzsA34ZKMChTWUyOuOuA3mN3hFClTw/aPdoWZ4PKXq2ZvzDLOCnST2/S63RrZkGc0cDXZLoBRdOWqZ0suHc3vB2aHzCMHlFf/qx+7l/rlQhZfAQxHIvvicsFVk2MJi03c58/qAnMcQR6dkCQIuhO5gYRfv2ynq78zIXABmE5GLb1tYbTZ/X+ZOz1+fSEOWnduXKQANp1DlFbHVPdMiiB7R/5WY7kj9mRxwgHt31qBkrrnHqvVZ5SM2+fThbuLihvPOPHfcv83yQecQame8E3ig3t7sjQ Qfn5gg+U 0/eKSHmhjXFjovdyRjMdcpz8yX6CzCHvKb+R3ioyWBIcP5SvrKDEZ5GL6YVuA6rDSi+a7ezm+Fho5HWPg/eYtVgKpbvsAXFQGoQgnPjBpJhRm6P6jiBlbV7TINLn8vOeG+fiu5szprdzeLSWtYp+D4DreEF6Q50tRP5mpF6XozkRy1ciBMBoJPxMJ7NZCKPE2jpY2vg/V9Pj9vRbH+muLPbvMsBdpiYdN18wFeOMWovxzWYutbgXEhjufhNXQVk+ThPrksI/etRuF8XXOrAUmaGpcLjR03lWQVXg+SB1YWIlODGheZflybvPsvXBN9Vr+i3P0TlsQJKds85KFsTNf5lsPnVRDDNTSpHBd X-Bogosity: Ham, tests=bogofilter, spamicity=0.004439, 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 Sat, Feb 22, 2025 at 11:59:53AM +0800, mawupeng wrote: > > > On 2025/2/22 11:45, Matthew Wilcox wrote: > > On Sat, Feb 22, 2025 at 10:46:17AM +0800, Wupeng Ma wrote: > >> Digging into the source, we found that the swap entry is invalid due to > >> unknown reason, and this lead to invalid swap_info_struct. Excessive log > >> printing can fill up the prioritized log space, leading to the purging of > >> originally valid logs and hindering problem troubleshooting. To make this > >> more robust, kill this task. > > > > this seems like a very bad way to fix this problem > > Sure, It's a bad way to fix this. Just a proper way to make it more robust? > Since it will produce lots of invalid and same log? We have a mechanism to prevent flooding the log: . If you grep for 'ratelimit' in include, you'll see a number of convenience functions exist; not sure whether you'll need to use the raw ratelilmit stuff, or if you can just use one of the prepared ones.