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 B3D36CD1288 for ; Wed, 3 Apr 2024 05:51:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4E1C6B0083; Wed, 3 Apr 2024 01:51:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DFDB76B0085; Wed, 3 Apr 2024 01:51:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC4E16B0087; Wed, 3 Apr 2024 01:51:06 -0400 (EDT) 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 AD6276B0083 for ; Wed, 3 Apr 2024 01:51:06 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 12E74A06E8 for ; Wed, 3 Apr 2024 05:51:06 +0000 (UTC) X-FDA: 81967147332.28.D3F8B96 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf21.hostedemail.com (Postfix) with ESMTP id 3AF1E1C000E for ; Wed, 3 Apr 2024 05:51:03 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P0R7hicj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712123464; 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=pCe99m+lvX3Q9JdwOVipLcUF6ks8hURE2QgW54n2EHA=; b=z5H6lefJjR5l8uuwraPI3stHiKWcqMcvJif1QTnHoafhOSFYOevg9M4x0waAjoIuGkqfDC a4DBZm9jv+WUitluz89UsXLeyZIRXOi3l+c0npASImFp8b30JvcDLAWgu9W8XUjIzJNl2M HX9SCr3eNlc8b12/+FWWHwjpRttNTIk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P0R7hicj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712123464; a=rsa-sha256; cv=none; b=xSr925FT0u4PZKfZjgqMB8BK1s4EYEPPWH+nJCJzGfGCorpA2+AeYHLelnXt2+k6Zaba8B uLTywlFEszlMEGaiVJUYQnMjBntCVoTazncRxJ3Ifp1990M19U2XYmFgYeCi2gJE1OlGem o5S+MJXbuDBpmsMXy1U1QS3ryuSN7Os= Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2d83dddcd65so2856151fa.1 for ; Tue, 02 Apr 2024 22:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712123462; x=1712728262; 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=pCe99m+lvX3Q9JdwOVipLcUF6ks8hURE2QgW54n2EHA=; b=P0R7hicjHNVs6x6Y8FunfGQfSJrToEkG7/I7PU3i8iMMsksL0ODzihn2wAfVmZi3Tq E2hn2Izxljrr2v5lJZsP3bz57gA4LSPM6vrwbDlWb8WUNHio0pVdEXqP7NVgINMcHXX+ n8lDlVCcaECz7gGc6LizbDT9SyOkCLqXRG/M02u67cDjIVFrx0OzDcBj9FRgaO2x1lov 45/zcNS4X/KGgUlDVKyD3CGP4bm5O0q3kwerD0TfujC0vJHIAjLlJZaLp+kpCmn8hab6 ybodb5Wv/8RsMnJW2gFMKcJFgegvwv+6NdlmDdcCcJnWWhcVQERF/9hBWw+nhiqsCTty JEfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712123462; x=1712728262; 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=pCe99m+lvX3Q9JdwOVipLcUF6ks8hURE2QgW54n2EHA=; b=W5OUwoL+WoxzFE1EWOdr8cq8lyOhUMjRIIk9G5w54uLz7UYChy3/sGa1F37EwJN8f8 khhXLLeqtQGRbRA7YBFLJooKwvCfxkehMTluZHnKTq5rz1qmfr/0duwGSZSqICGsxuBe fqoj3hbQ7jq2VEl5Z569nEL87J3PKLQqBCRPa0ATpmg5xMG3CIaxB5piMrOL7ndZynZG yuCLXrsAnAxSwvGLyjr20Cjwl1l7G/4ZvDy7fynwAlpv3O7Qq+fnuKeau4vWW91ffYZw Myz3O9m2yqggjKBToJDQ0+u/u6yXWQFcgFNpGFMgFhVzHT6TjzN2rEfB9KmqIj5PjvcH bVxg== X-Forwarded-Encrypted: i=1; AJvYcCVbJ27fY09jvdd89Erj9aDuPNfJNKlq9ObbwA4U1m3AhFVj7A3DuQVkR0YlMyjigjCVeRuWGHglvl3AV7uNCuoGeVs= X-Gm-Message-State: AOJu0Yx97BF/RnZZAtZxD9d7cPSDtbi2HpmvZ6zCRuUm+qVUOSYjRZpr QWtp4sNJjdGxRNnVD+KasCufW3AAUv0ppSFYIyZLPam6TGs7BhujmlvYs0p3iDIaIsX3FWTtenO tLpIQOozxOi+iNYEp2x3nUAH8qD4= X-Google-Smtp-Source: AGHT+IHFqmXqlBSd2ZbMViKWG+Z1LzyEnCtR30sIJcynrZM9shhHsPMu9mH9re6Zh+Mf/CW35nLpVb9a2Oyge73CAY8= X-Received: by 2002:a2e:b1c9:0:b0:2d4:42da:40fe with SMTP id e9-20020a2eb1c9000000b002d442da40femr9203882lja.17.1712123462056; Tue, 02 Apr 2024 22:51:02 -0700 (PDT) MIME-Version: 1.0 References: <20240401081734.1433755-1-zhaoyang.huang@unisoc.com> <736b982a-57c9-441a-812c-87cdee2e096e@redhat.com> In-Reply-To: <736b982a-57c9-441a-812c-87cdee2e096e@redhat.com> From: Zhaoyang Huang Date: Wed, 3 Apr 2024 13:50:50 +0800 Message-ID: Subject: Re: [PATCHv2 1/1] mm: fix unproperly folio_put by changing API in read_pages To: David Hildenbrand Cc: "zhaoyang.huang" , Andrew Morton , NeilBrown , linux-mm@kvack.org, linux-kernel@vger.kernel.org, steve.kang@unisoc.com, Matthew Wilcox , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 3AF1E1C000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 6w8pwxh4gmki6aoiazbzqs9gkmsqwwri X-HE-Tag: 1712123463-416933 X-HE-Meta: U2FsdGVkX19g5Z570sS8WAEMj8F0qrCBKqWDL6AtrCcGvfMamwQzQ9nhKsKrPUbYpnVj9ZeWA/nMZhThH1ZhR+rQUaiVlLUhnqqJ5n9gy3uMZKbKxZzBRvHtyVBDM1FC4nEcGJOtJB0nSV/yAqPmDd8DS1N4Smlm7PIAwRZSv6HUghJAfU0echjCQy9S4ROefdqoHQsk4R9YMb5oXRIr6/aLrUyaXnxIg1xPfxzlMUYWRiGevJZFE5ANkLN2C0e3KVzNkoC2LN8DWjBETyJq2VHbUkLoX7n/07owf2zU6Z4gTbVnsYIzdOzZ4DO/WxqVSwG/v4llrdjjokHCvaP30OUdVarRkWkBw+Q5nVLjzkbkppkFnkfZKjVnYaBlu212qK9XVg+WBnbYzJAgVaBAY5VXy6f+AicKGGf1vsaqQmc14BGrPQnHTHt+axJ4xgRpEpI2m7Vzk13lw44+dBQsKXwEmpHJjGk4ZwtB3yW1V4U8hlFg0xdDcKCFDA2xe4BfmzfqRiiiI0nsx6oKIA5UYW2dYYJS2JxO3rYbC36YZD6Zn/M2MeqnXHahO+4JE+3E7bFwNF0Mb/WlkiVI52DCgZ0W9bqt9rkhpLL0Dqe4yVs8DmgO2isykpIJr6ZyJx/RjxLyRk4JJabUl66qcsMQtZ0y4CdLoq24FBtz98ie4B8LqNeY65ZVUY9Sy3WaO2qWsgODVpjYAaM49WuW0fbbFLoXfrwE9PRIER1b5ZgstRbCmvX5cR9Z36sAn1rX0LitVUXKnoHCvKoqyzh4ysLI4aLu0v6KtrvS9UutA8V/F+AQdVH+OW32piKi7JhAoM1mIX43xkPD5FRjm20fIMGoImw1OmzGl7+DGtln4fJREjLz6PABvsZC040L8Q55VmExcaVtU/a7RRSuArgTTzdzj447y+5yOBVsaXdeQkQIKUJu2N1+AC2dTVrkQhFoKlYqqpTBLXPC5QwVTg9hzF4 xAU1JevH OZaduSG5xghp2DMlLt0OI1S1PlzKkEM378FoG2J5ipI04iTBBrq10v7fdNP74Trl+gKmB4H8R5lRKxZYl32H5aUitAJTvcQNzzRH0JPgO7cePfEViYj6HKQUyVQQOJYe6oRYgg+KPKmTicSTyZ32efemMju9TkGSYDsjFd3hjbbsuL+O4lrXqeUP9Z3aGwGb96zU3tvIemzLvXWaOL9xbj5Y/yKvFgfxaWl/V7df58P8Jdu3/w/46xJm7o/bncl0pV+76qmW3wFrLpzy9Ug1Ptw934pzjfyWNmVKmriIGiM5BhMAshP2VZDhcjw9eJOA87zhU7j2SirbV1Cv2ph1iLiinidOOj2dAtXt9n1o86N9niPJ9Ciu6dq+Mm+dcW7HYlaIwMXxrY/QNuL6KL+u6JYNsm/M/b+QejHxH0dKNlfgN+uDjCoEs0ukdkUmZeH+frcog+n689fQBk9jAauJ4zb31f94o4M6EoAIc X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, 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, Apr 2, 2024 at 8:58=E2=80=AFPM David Hildenbrand = wrote: > > On 01.04.24 10:17, zhaoyang.huang wrote: > > From: Zhaoyang Huang > > > > An VM_BUG_ON in step 9 of [1] could happen as the refcnt is dropped > > unproperly during the procedure of read_pages()->readahead_folio->folio= _put. > > This is introduced by commit 9fd472af84ab ("mm: improve cleanup when > > ->readpages doesn't process all pages")'. > > > > key steps of[1] in brief: > > 2'. Thread_truncate get folio to its local fbatch by find_get_entry in = step 2 > > 7'. Last refcnt remained which is not as expect as from alloc_pages > > but from thread_truncate's local fbatch in step 7 > > 8'. Thread_reclaim succeed to isolate the folio by the wrong refcnt(not > > the value but meaning) in step 8 > > 9'. Thread_truncate hit the VM_BUG_ON in step 9 > > > > [1] > > Thread_readahead: > > 0. folio =3D filemap_alloc_folio(gfp_mask, 0); > > (refcount 1: alloc_pages) > > 1. ret =3D filemap_add_folio(mapping, folio, index + i, gfp_mask); > > (refcount 2: alloc_pages, page_cache) > > > > Thread_truncate: > > 2. folio =3D find_get_entries(&fbatch_truncate); > > (refcount 3: alloc_pages, page_cache, fbatch_truncate)) > > > > Thread_readahead: > > 3. Then we call read_pages() > > First we call ->readahead() which for some reason stops early. > > 4. Then we call readahead_folio() which calls folio_put() > > (refcount 2: page_cache, fbatch_truncate) > > 5. Then we call folio_get() > > (refcount 3: page_cache, fbatch_truncate, read_pages_temp) > > 6. Then we call filemap_remove_folio() > > (refcount 2: fbatch_truncate, read_pages_temp) > > 7. Then we call folio_unlock() and folio_put() > > (refcount 1: fbatch_truncate) > > > > Thread_reclaim: > > 8. collect the page from LRU and call shrink_inactive_list->isolate_lru= _folios > > shrink_inactive_list > > { > > isolate_lru_folios > > { > > if (!folio_test_lru(folio)) //false > > bail out; > > if (!folio_try_get(folio)) //false > > bail out; > > } > > } > > (refcount 2: fbatch_truncate, reclaim_isolate) > > > > 9. call shrink_folio_list->__remove_mapping > > shrink_folio_list() > > { > > folio_try_lock(folio); > > __remove_mapping() > > { > > if (!folio_ref_freeze(2)) //false > > bail out; > > } > > folio_unlock(folio) > > list_add(folio, free_folios); > > } > > (folio has refcount 0) > > > > Thread_truncate: > > 10. Thread_truncate will hit the refcnt VM_BUG_ON(refcnt =3D=3D 0) in > > release_pages->folio_put_testzero > > truncate_inode_pages_range > > { > > folio =3D find_get_entries(&fbatch_truncate); > > truncate_inode_pages(&fbatch_truncate); > > folio_fbatch_release(&fbatch_truncate); > > { > > folio_put_testzero(folio); //VM_BUG_ON here > > } > > } > > > > fix: commit 9fd472af84ab ("mm: improve cleanup when ->readpages doesn't= process all pages")' > > Something that would help here is an actual reproducer that triggersthis > issue. > > To me, it's unclear at this point if we are talking about an actual > issue or a theoretical issue? Thanks for feedback. Above callstack is a theoretical issue so far which is arised from an ongoing analysis of a practical livelock issue generated by folio_try_get_rcu which is related to abnormal folio refcnt state. So do you think this callstack makes sense? > > -- > Cheers, > > David / dhildenb >