Received-SPF: pass (google.com: domain of linux-kernel+bounces-23988-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <2db8eba4-f4c8-7a7c-38d3-44abdd0abbd3@oracle.com>
Date: Thu, 11 Jan 2024 10:36:00 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH v4 4/4] selftests/mm: add tests for HWPOISON hugetlbfs
 read
To: Jiaqi Yan <jiaqiyan@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
        Muhammad Usama Anjum <usama.anjum@collabora.com>, linmiaohe@huawei.com,
        mike.kravetz@oracle.com, naoya.horiguchi@nec.com,
        akpm@linux-foundation.org, songmuchun@bytedance.com,
        shy828301@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        jthoughton@google.com, "kernel@collabora.com" <kernel@collabora.com>
References: <20230713001833.3778937-1-jiaqiyan@google.com>
 <20230713001833.3778937-5-jiaqiyan@google.com>
 <be3976b5-0a9c-41c6-8160-88e6c1e5d63e@collabora.com>
 <CACw3F51WvZDVCpVg9j4j8WmnmAFOsnK+FZDDoVqhgLqVwhPTCA@mail.gmail.com>
 <e68488e4-764e-4b25-8a47-05bf8976bd19@collabora.com>
 <079335ab-190f-41f7-b832-6ffe7528fd8b@collabora.com>
 <a20e7bdb-7344-306d-e8f5-5ee69af7d5ea@oracle.com>
 <dd96e476-e1ad-4cb5-b5d1-556f720acd17@collabora.com>
 <CACw3F53PddeCHUHb=m8OSO6yYQJoM==urn+Axp=Xi1szozJH9A@mail.gmail.com>
 <6bacbd7c-88cb-1399-8bd0-db98c93a1adf@oracle.com>
 <ZaAtjVVTETdQDR4B@casper.infradead.org>
 <39b90dce-fe0f-e1d8-3094-75cabbfa38a3@oracle.com>
 <CACw3F52B9ckzqUmGzzQxpskJGRZu+3m+tVRoSekhgsX-mQaeBw@mail.gmail.com>
Content-Language: en-US
From: Sidhartha Kumar <sidhartha.kumar@oracle.com>
In-Reply-To: <CACw3F52B9ckzqUmGzzQxpskJGRZu+3m+tVRoSekhgsX-mQaeBw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?Nk5YeTNRQkVObzFFMkJCTGlrbk93bHpVZS9IV0o2NXZoZlQ1TitCVWtVYW9I?=
 =?utf-8?B?RVpqU3hKOFJjMWVRN1FoM0x2R0hoNW5JZTB3WGprZ2RhQzVrdGVLM1dlNU5N?=
 =?utf-8?B?VWpTZVVJWHZZT3dERWZkNmFpZFJqUHVDTVRqMkNlN3NOVmlFNW5PZU5GYWJM?=
 =?utf-8?B?ZEJFVHdqakxtRy95SDJCa3RpeUtMN2M0c2NtTEhEejRYRmY0TkFkLzFabjdJ?=
 =?utf-8?B?bGdTd05ZYUZTWmVsM2ZYNEtBQmFKVXE4SFhZZU52WlhDRG9mSGxtcVBKYm9C?=
 =?utf-8?B?ZkdQN3Byc0cwUzd1RUVuR01XbnBJNjFsK210dGxKRzR6S25SQ1hUVEpPVkgw?=
 =?utf-8?B?NHNBQTg5NUlQb05qa1V4bkc0dXE4YTV2Y0NSNTNKLytLdm41WnM0Yk80cGpU?=
 =?utf-8?B?aDNSV1JuejQ3OGl1VmpzNGJ2V29qNnNXV3FZVTFuV2k3QWJQVTlmTHgwQlV2?=
 =?utf-8?B?OXFNQ0EvNmNDLzhnQ2ZrUlFqTWFlc3dzZWlrS0liT3daK0UyVEdCVHdBZzhO?=
 =?utf-8?B?cnpCSlR1S0RxZ2o0VzZLMTM0ZDcyRk1PM3FyZC93TERYeElHcmJPWjNwM2Zw?=
 =?utf-8?B?NE1BbVRkbFpvQ1Fvd3ZiNnpxZ0RnK1ZaM2Zxd0Ixajdpdk8vZ1UvK0gzZ1hV?=
 =?utf-8?B?elVCRWJmazUycnJKNzdSQXNVdE5JQ1lEN3RlQkV5b1pKWFJ6MnFzSktnR2JI?=
 =?utf-8?B?YUhyWGh2Tk1ZK0RSaEsrZ21kdVdBNWRlK1dsTXBiaGg4c3lEWGFFYUx6WmxD?=
 =?utf-8?B?K085b0NiREEydDVJbmtSWFZMYzhRdmVodWd0UzdDREk0LzhJRzZBRHp2cFlY?=
 =?utf-8?B?NjlldVBPMEFFczBxRGFBZHBRQ1BpUkF1bWVxeldEVzYwRHRUZlpxSnp4OTdC?=
 =?utf-8?B?ek8yTURub2JSVnBjNG82MzNwVkQ3QWVPNGlKbkE5cXVIYWpUL0lWQk5QTmRq?=
 =?utf-8?B?SG9sL0ZvSmRZQUJPTlJiaFVmeXRna2Q4aS9oNnhoNGFNa2VJcXEwUVJ1bjVn?=
 =?utf-8?B?VXZheTllMzZ5WjN1MXhJSC92aFQ2T01MbFpsaTFrWHNqcjFJc1NUQm02Wi9C?=
 =?utf-8?B?WktuZm5hSXJWL0pPRStJcXNNZWlvdVN6Z2FPZlJyMGNySEp4OVBxWlB0Smd1?=
 =?utf-8?B?dXRWaDdxaVpVU1RmZUJxWWZvd09nZXJHcXZnOEZhWkZQbkloWWRHU2l2TG82?=
 =?utf-8?B?K29pb2JqakNSVldQVXpNdm1NYnA2ZHBNM283LzBJY2t2Z2p6blg5UENqSDdI?=
 =?utf-8?B?L0JyUm1VN3JteU9tSXFyT0tvT2YrMG16dERrTk1IWXltUStTejY3b2JVSGc3?=
 =?utf-8?B?Ny9aZndVa0k4SnZBOGQxOGRPZEdEYW9hdW1HOWhHSjFCUVdpMzhyS25VR0Jt?=
 =?utf-8?B?VERyc2dBbnZzSjc5aStFcmsvcDkyUzMvMkpkdzB6UUNWM2J2M1ZiRUx2UkI5?=
 =?utf-8?B?SzRmSGZTdWh0RnlLUGxJUjZUbHovY2cyM09rblBtOERoNC9BaDNmOTFqak8x?=
 =?utf-8?B?TStlVnlTaTdpUGgxcXZxa0t3WGovZ2JLaXdMQ1Z4TGtWZGlHSjhhbmJtdDZG?=
 =?utf-8?B?Rm04WXlYUEFKbFFGLzkwZ3ZyUm9zVVBpQ2lXUFd0bXcraVlqK3VsMk1pcGdj?=
 =?utf-8?B?T3FFdTczcGZZMXgxNWlxc3B5eENoUlIzczFTbXdURjZ3dW94THM1Q2RUL2ow?=
 =?utf-8?B?aHdkMWJKK1BSWFhURXRSRGMxMEhDODIzc1ZscFFkaU5vNWhrV2ZBZ2RYUE9I?=
 =?utf-8?B?cTJ4MjEzbW43c0NOZkpZclBYSm5iYUl6Vmphd0pQRy91S1gvaFJPSTN2ajBq?=
 =?utf-8?B?Ym1kS2wvRmR5SldvcFl4YnJqWmxsenhwcVo2aHNYUm1IRHErVE84cjMzMW9s?=
 =?utf-8?B?eVV3QlRRUitEWW1oWUFVTFRCd2FSUVVXZStyUmlnako2YlNRN044c0ZQK3Yv?=
 =?utf-8?B?RTd6a1FiNDFNOEwxVXRVVG9CcFNLUzRlaFVpWFZGMEp2eEd4Q3NNM3l3U0li?=
 =?utf-8?B?M2gvK0MwRG0ybDdaQjZYZGIvTHhuUStyTnF1b0I4UHdpUW1VV1cxSVh2UUdN?=
 =?utf-8?B?RG5MN0NMWGxWZmRkZlk5MUw1V0RjMkdqbGtLcnJzZDBxRXZDR1JEbmpwOTZm?=
 =?utf-8?B?UWhFcmxnMHFaQ2lUM0g5eFhndjdZanVTcG1HMTJSQ3JGelBRUXRiSXVZdVpU?=
 =?utf-8?Q?Xf4Cpx1k6WxGBzWq1n6H+qA=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	pUTrw+b0lcvBsA9AZfC5LsilZHcXIMCvRZFtc6ukkep1P7jm2Pc/KNxL3wYFq4hbeg8pX4saBLxFMsD7vl67h/P4aYBSnmLBS2P4jX7cpZ4KDQFEpEFjK5LpxGvUN7V1zNQJfbfpIRezS61tcZo04nyL7+tKJc0GCgzKMmdmol44klqW8LLIfrCuYRFRJGR2BETV9hQt6AKNP6K+K9uFHC9wVssgLs7nSOZdI8Tt6UaEhLAYR86ziJttEuk6DaZypYgD8zCUWWo1pGcF2U5RvZ7OuCfA409a0fGEYgaYHnQV5Ez7ZVR2ErqfhecZHMYvYB6ytiVdyCWSDE5MmXew+GwzhHREW00icNzcp7KdXTmfNmgtm8CP9TrSum7OrHexaoX1i1xbJnLREskpEYXplKkt+JgHZCU30rKN4/r2jZJOe9Dzcv+PVXDu8p1gNTHx5FO72v7AWRfJM7u5//jek57k4wIcfdzRtGsNa5S/FAHWJ9DTkNHf+pZNZm+MDZWJ9z8kGK46+DSXt6xfmyVIDYN3fDJ2b1NhG8WUvdxvi7ci/BG2DuFNcfgT0EnjzCkhYj1A616gr/x2QCpr5XHKgOtPGu9Sx7eXJ61dXZ3HnGQ=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4de04861-8e23-4f4e-ad64-08dc12d42a82
X-MS-Exchange-CrossTenant-AuthSource: CH0PR10MB5113.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2024 18:36:03.6580
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: C2Sl+8Po9f/Py1cH95Bg2q7kE/G6GwO/BicdLb52r5Qvok2lezNByEQrVEnfmtEiXBD48C6hMWTdnEn2msvmzJtemoaPW649kW6c0NNYUbU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB6201
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-01-11_10,2024-01-11_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 bulkscore=0
 mlxscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000
 definitions=main-2401110146
X-Proofpoint-GUID: Yy4S2e8JfO6YJFVWU3jc2huOKs6MZ7Ou
X-Proofpoint-ORIG-GUID: Yy4S2e8JfO6YJFVWU3jc2huOKs6MZ7Ou

On 1/11/24 10:30 AM, Jiaqi Yan wrote:
> On Thu, Jan 11, 2024 at 10:11 AM Sidhartha Kumar
> <sidhartha.kumar@oracle.com> wrote:
>>
>> On 1/11/24 10:03 AM, Matthew Wilcox wrote:
>>> On Thu, Jan 11, 2024 at 09:51:47AM -0800, Sidhartha Kumar wrote:
>>>> On 1/11/24 9:34 AM, Jiaqi Yan wrote:
>>>>>> -                       if (!folio_test_has_hwpoisoned(folio))
>>>>>> +                       if (!folio_test_hwpoison(folio))
>>>>>
>>>>> Sidhartha, just curious why this change is needed? Does
>>>>> PageHasHWPoisoned change after commit
>>>>> "a08c7193e4f18dc8508f2d07d0de2c5b94cb39a3"?
>>>>
>>>> No its not an issue PageHasHWPoisoned(), the original code is testing for
>>>> the wrong flag and I realized that has_hwpoison and hwpoison are two
>>>> different flags. The memory-failure code calls folio_test_set_hwpoison() to
>>>> set the hwpoison flag and does not set the has_hwpoison flag. When
>>>> debugging, I realized this if statement was never true despite the code
>>>> hitting folio_test_set_hwpoison(). Now we are testing the correct flag.
>>>>
>>>>   From page-flags.h
>>>>
>>>> #ifdef CONFIG_MEMORY_FAILURE
>>>>       PG_hwpoison,            /* hardware poisoned page. Don't touch */
>>>> #endif
>>>>
>>>> folio_test_hwpoison() checks this flag ^^^
>>>>
>>>> /* At least one page in this folio has the hwpoison flag set */
>>>> PG_has_hwpoisoned = PG_error,
>>>>
>>>> while folio_test_has_hwpoisoned() checks this flag ^^^
>>>
>>> So what you're saying is that hugetlb behaves differently from THP
>>> with how memory-failure sets the flags?
>>
>> I think so, in memory_failure() THP goes through this path:
>>
>>          hpage = compound_head(p);
>>          if (PageTransHuge(hpage)) {
>>                  /*
>>                   * The flag must be set after the refcount is bumped
>>                   * otherwise it may race with THP split.
>>                   * And the flag can't be set in get_hwpoison_page() since
>>                   * it is called by soft offline too and it is just called
>>                   * for !MF_COUNT_INCREASED.  So here seems to be the best
>>                   * place.
>>                   *
>>                   * Don't need care about the above error handling paths for
>>                   * get_hwpoison_page() since they handle either free page
>>                   * or unhandlable page.  The refcount is bumped iff the
>>                   * page is a valid handlable page.
>>                   */
>>                  SetPageHasHWPoisoned(hpage);
>>
>> which sets has_hwpoisoned flag while hugetlb goes through
>> folio_set_hugetlb_hwpoison() which calls folio_test_set_hwpoison().
> 
> Yes, hugetlb sets HWPoison flag as the whole hugepage is poisoned once
> a raw page is poisoned. It can't split to make other supages still
> available as THP. This "Improve hugetlbfs read on HWPOISON hugepages"
> patchset only improves fs case as splitting is not needed.
> 
> I found commit a08c7193e4f18 ("mm/filemap: remove hugetlb special
> casing in filemap.c") has the following changes in inode.c:
> 
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -334,7 +334,7 @@ static ssize_t hugetlbfs_read_iter(struct kiocb
> *iocb, struct iov_iter *to)
>          ssize_t retval = 0;
> 
>          while (iov_iter_count(to)) {
> -               struct page *page;
> +               struct folio *folio;
>                  size_t nr, copied, want;
> 
>                  /* nr is the maximum number of bytes to copy from this page */
> @@ -352,18 +352,18 @@ static ssize_t hugetlbfs_read_iter(struct kiocb
> *iocb, struct iov_iter *to)
>                  }
>                  nr = nr - offset;
> 
> 
>                  /* nr is the maximum number of bytes to copy from this page */
> @@ -352,18 +352,18 @@ static ssize_t hugetlbfs_read_iter(struct kiocb
> *iocb, struct iov_iter *to)
>                  }
>                  nr = nr - offset;
> 
> -               /* Find the page */
> -               page = find_lock_page(mapping, index);
> -               if (unlikely(page == NULL)) {
> +               /* Find the folio */
> +               folio = filemap_lock_hugetlb_folio(h, mapping, index);
> +               if (IS_ERR(folio)) {
>                          /*
>                           * We have a HOLE, zero out the user-buffer for the
>                           * length of the hole or request.
>                           */
>                          copied = iov_iter_zero(nr, to);
>                  } else {
> -                       unlock_page(page);
> +                       folio_unlock(folio);
> 
> -                       if (!PageHWPoison(page))
> +                       if (!folio_test_has_hwpoisoned(folio))
>                                  want = nr;
> 
> So I guess this "PageHWPoison => folio_test_has_hwpoisoned" change is
> another regression aside from the refcount thing?

ya this is another error. The refcount change fixes the madvise() call in the 
tests but the poison read tests still failed. The change to 
folio_test_hwpoison() fixes the poison read tests after the madvise() call 
succeeds.