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 53F49C7EE29 for ; Sat, 10 Jun 2023 06:50:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5006C8E0003; Sat, 10 Jun 2023 02:50:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B03A8E0002; Sat, 10 Jun 2023 02:50:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 378648E0003; Sat, 10 Jun 2023 02:50:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 255038E0002 for ; Sat, 10 Jun 2023 02:50:40 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E4001C012D for ; Sat, 10 Jun 2023 06:50:39 +0000 (UTC) X-FDA: 80885914998.21.11ED4A7 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf04.hostedemail.com (Postfix) with ESMTP id AEA3140014 for ; Sat, 10 Jun 2023 06:50:37 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=qSpiITNS; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf04.hostedemail.com: domain of tsahu@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=tsahu@linux.ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686379837; 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=9KgI/yR+aq24mmtwuyPThyCJd707Xtg4oppDr5emJrk=; b=MmAuhugOH/1in7Oejjs2xMwH8QmBVKrq2bORJQc+Ul/FoMZ14Ja0m7YR7Q8LzoTwnmZrvG 045ccYOdclsRJsgv1GfSvWSn2qNQfo8ycJhwAuIX8w3BeNPXJ6fI2N3NqkcvhjjyG0wfjt ehiWKhh/aEFUIv+7RBapxhYF5qNRH9U= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=qSpiITNS; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf04.hostedemail.com: domain of tsahu@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=tsahu@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686379837; a=rsa-sha256; cv=none; b=7kMAgvAATPqxODEkEydxJx0f736qGx5XeGtGsBCB2++c4VbyPUCImIV/S+MccDgnwUO5i4 dwnjJ88p879FvF7/GMf8pgNXJoI3Uq3sR5PGbTIMXYh/8aDYs8iWDkAmWyj5MZCrOQRXnI iOMMCaiwWlZfKotC8eR5pPpoDOozAbA= Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35A6m0OW026791; Sat, 10 Jun 2023 06:50:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : content-type : mime-version; s=pp1; bh=9KgI/yR+aq24mmtwuyPThyCJd707Xtg4oppDr5emJrk=; b=qSpiITNSiCrg8oF8shIgfl5I73JO24kAnnyInJQ9LO49LoApYhh4cYTSExAPN4boQ/Gh juUF5IKYiOSYZ44gBkCJ81fAsC14NuXMbROZn2mRPBIFsiVsHCMn0SAlvX15GL91PCU/ HxrNxK+aiOJ5ULYopYVdPAV+XMloXHHzlmm+q9TLZxpZ5g9HcaGIWKNvGEMnAZapblJ8 GMsULKsob/sMF+Upnif1Ty3xcQqP1pMW0Yx2LRT4a+0g51QkPl6sEMGYV2zCoUG22X/t 2MqZ7fba6Ec90GoTOcxHcQ6kdEqo5OiHYdzKYH1fcSdps40oCjPkBwbQv8LPi/hVkV2Y ZQ== Received: from ppma05fra.de.ibm.com (6c.4a.5195.ip4.static.sl-reverse.com [149.81.74.108]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3r4m7h81qk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2023 06:50:29 +0000 Received: from pps.filterd (ppma05fra.de.ibm.com [127.0.0.1]) by ppma05fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35A6edlc009424; Sat, 10 Jun 2023 06:50:27 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma05fra.de.ibm.com (PPS) with ESMTPS id 3r4gt4r2xn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2023 06:50:27 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35A6oN1a59572534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 10 Jun 2023 06:50:23 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B75D720043; Sat, 10 Jun 2023 06:50:23 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F18A320040; Sat, 10 Jun 2023 06:50:21 +0000 (GMT) Received: from tarunpc (unknown [9.43.84.45]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS; Sat, 10 Jun 2023 06:50:21 +0000 (GMT) From: Tarun Sahu To: Andrew Morton Cc: linux-mm@kvack.org, muchun.song@linux.dev, mike.kravetz@oracle.com, aneesh.kumar@linux.ibm.com, willy@infradead.org, sidhartha.kumar@oracle.com, gerald.schaefer@linux.ibm.com, linux-kernel@vger.kernel.org, jaypatel@linux.ibm.com Subject: Re: [PATCH v3] mm/folio: Avoid special handling for order value 0 in folio_set_order In-Reply-To: <20230609112944.fc08936beb29a18f7bfb5ae3@linux-foundation.org> References: <20230609162907.111756-1-tsahu@linux.ibm.com> <20230609112944.fc08936beb29a18f7bfb5ae3@linux-foundation.org> Date: Sat, 10 Jun 2023 12:20:20 +0530 Message-ID: <87ilbverpv.fsf@linux.ibm.com> Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: n7mibCUA91808dtpVYJZBlKzMX6dDCmA X-Proofpoint-ORIG-GUID: n7mibCUA91808dtpVYJZBlKzMX6dDCmA X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-06-10_04,2023-06-09_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 adultscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 clxscore=1015 malwarescore=0 spamscore=0 mlxlogscore=952 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306100054 X-Rspamd-Queue-Id: AEA3140014 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 8fh9k88s8ssaxe58eq4xmsgqf53juokp X-HE-Tag: 1686379837-917945 X-HE-Meta: U2FsdGVkX19v00mrgC8r9Rx+hXhP5S+o6kNt3Ozbq2ROerQiEgszNAgdQYPfN4B+eF3fDAEH8YRR3+e10T66CU4R97vfsg+nNsWz6A4QItCSVxhQBAjqB9ursm4uMpyLIkQNbPzda78Ardxi3E2CeP2zqYStIzn5Jbo7pz8VB/o+s5/as7ypH4VE9LvDVhu1lUAi35alxBRKf7QQCYyZcvQbtNzKUWf5sEbw5TCrd1GxUqMHu0Ayu35Udv3JTWPm0Po4OS2O//RUKeAaGvrISS36EtwoZhWGpLfLb3bz+Dk99YyEKDJ09zaiqAz5BVnjySK8floZyZF8rL9uHolSsdyndE5HRSLX+ENOdnVGMSeLJiIQ7ZU8WgJ0IQmtjXPP47qi6sUj1gTtsc0NuO5pvNxX5dfZIoD51ht1FktnMLibmvhQzjGIy9ujAcl6PRSzEgXPZiQe+9jWOy7eW7blT2dH00OEV3u1XpsXbQwM2Pw97FaPxmviifgFA5tojmvEN8bTfftZGjUxOJepFD3gPw4Ltv0Jiq5EMpdlSWFBmw9EF2xvqQ69F4bT6+MzKPMMFuB/HmaPHtRedQjHboTM8EXwwYO61ApUZendGR7trPDFMWr7LhmOpqiO0kBDD83TeLFEys0dS9h4snfkAw0wlkS/bauCGZ45SzChh51xPX47XYBPQNTPFNhnUPvWTs8xKiMpMujAb3rOIe7nn/U0x4CUUN9GCSnYGAkh039KJ/Gk91piocN8yPvto8smKMJZrG1qmXNYbwnll/6LHqaaATDsMgUpmUwT+XWczWsT8YEsklq4ZnpqFWeL6hNfkl3NjSS0nzU0luSQNHUYCA/q/V0KogZ+QGXOo1g/stuCaWvNH4pc96GZYYAHTK0htzyzPzU6GGjPiWflDtqwIq+svCK92EhlBI6fsuv5yZRzFgU9Bwf3YsLL9r8nyIN2aqPhqgZpacOwysz4ihYMX7e ZolTMadf Mv7FO+kiP2neebHUCOB+015uXL5RzvUbjAOEItoNQQVPkYyCS/o9Zk97pjgW12jwH9tNnC2VYWkiOOfP1mCur+t0f4P55mgnXs9dGuAMOdxTPeLINwgwGxgnwpqyq2Ahn6TDU5cJhuJ/+/5q3ZYo+JMF/0u5nM+ccoJU4Xu5VG+5mQU5Y3g/7zufM54XHouPZs4QO5bTA7DoSMTObtNzSMIUAN6hhGt9GLPHzrEHnpFVALKI= 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: Hi Andrew, TLDR: It is not bug fix, it is just cleanup. Andrew Morton writes: > On Fri, 9 Jun 2023 21:59:07 +0530 Tarun Sahu wrote: > >> folio_set_order(folio, 0) is used in kernel at two places >> __destroy_compound_gigantic_folio and __prep_compound_gigantic_folio. >> Currently, It is called to clear out the folio->_folio_nr_pages and >> folio->_folio_order. >> >> For __destroy_compound_gigantic_folio: >> In past, folio_set_order(folio, 0) was needed because page->mapping used >> to overlap with _folio_nr_pages and _folio_order. So if these fields were >> left uncleared during freeing gigantic hugepages, they were causing >> "BUG: bad page state" due to non-zero page->mapping. Now, After >> Commit a01f43901cfb ("hugetlb: be sure to free demoted CMA pages to >> CMA") page->mapping has explicitly been cleared out for tail pages. Also, >> _folio_order and _folio_nr_pages no longer overlaps with page->mapping. >> >> So, folio_set_order(folio, 0) can be removed from freeing gigantic >> folio path (__destroy_compound_gigantic_folio). > > The above appears to be a code cleanup only? yes, > >> Another place, folio_set_order(folio, 0) is called inside >> __prep_compound_gigantic_folio during error path. Here, >> folio_set_order(folio, 0) can also be removed if we move >> folio_set_order(folio, order) after for loop. >> >> The patch also moves _folio_set_head call in __prep_compound_gigantic_folio() >> such that we avoid clearing them in the error path. > > And the above also sounds like a code cleanup. yes > >> Also, as Mike pointed out: >> "It would actually be better to move the calls _folio_set_head and >> folio_set_order in __prep_compound_gigantic_folio() as suggested here. Why? >> In the current code, the ref count on the 'head page' is still 1 (or more) >> while those calls are made. So, someone could take a speculative ref on the >> page BEFORE the tail pages are set up." >> >> This way, folio_set_order(folio, 0) is no more needed. And it will also >> helps removing the confusion of folio order being set to 0 (as _folio_order >> field is part of first tail page). >> >> Testing: I have run LTP tests, which all passes. and also I have written >> the test in LTP which tests the bug caused by compound_nr and page->mapping >> overlapping. > > What bug? Please describe the end-user visible effects of any bug. > > And if a bug is indeed fixed, please let's try to identify a Fixes: > target and let's decide whether a -stable backport is needed. > > Thanks. > No bug fixed here, The above cleanup modifies the code which touches the code path that a past patch had added to resolve the bug. The above test just check if the resolution is not affected. >> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/hugetlb/hugemmap/hugemmap32.c >> >> Running on older kernel ( < 5.10-rc7) with the above bug this fails while >> on newer kernel and, also with this patch it passes. >>