Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b5bd2b39-7e1e-148f-7462-9565773f6d41@oracle.com>
Date:   Wed, 7 Jun 2023 13:35:05 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH 6.3.y] mm/hugetlb: revert use of page_cache_next_miss()
Content-Language: en-US
To:     Greg KH <greg@kroah.com>
Cc:     stable@vger.kernel.org, linux-kernel@vger.kernel.org,
        songmuchun@bytedance.com, mike.kravetz@oracle.com,
        Ackerley Tng <ackerleytng@google.com>
References: <20230606172022.128441-1-sidhartha.kumar@oracle.com>
 <2023060650-overlying-skiing-191d@gregkh>
 <c6ead868-3523-f25c-3f04-119da28a50ff@oracle.com>
 <2023060745-kilometer-omnivore-4471@gregkh>
From:   Sidhartha Kumar <sidhartha.kumar@oracle.com>
In-Reply-To: <2023060745-kilometer-omnivore-4471@gregkh>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TjVBN3h4ek9veUhGWUFSalJ0RnpSekFIMnBHVm1Bd3cwTkVzQ05QZ0RlVkM5?=
 =?utf-8?B?SW93N0o3V1VvRkUvdGtFS2hIYmRKUEYwZTR1aGN2dUJQMVhoVVVMMmdNck1u?=
 =?utf-8?B?RmcxWWJRMWQ2L3didm1RRC9Va2tXWEwyek9UeW5DZGtYeGdMcUZFdmNrOVVm?=
 =?utf-8?B?ZDRFMzlIZFZBNVMzQ2xsczB2Slc0N3ZIYTlDTmJVeXJqNU5iZk0zVWN4T1ZK?=
 =?utf-8?B?RVd4cUZYZmVEbkZHOVRqditUVVZmL0FqLzFsSHFGb3hCeTZHeEJiUGZud3R2?=
 =?utf-8?B?TndvOGZxTFVlRmdXaUpiOWNTOS9CSDV2MFJHajBBVHl5NkwvZnZzaDIyeVNJ?=
 =?utf-8?B?SGVLbnJmU1pWRXNwNHRxeW12UmYwMHBFbDNNblUrbjN4YmVmWEY0a2xLNndR?=
 =?utf-8?B?czVDc1FYWUthVktaM0pTNlhmVWJjQ1oxcnd4bHY1TnovZHJWRm9nUTY0ckM5?=
 =?utf-8?B?UTQzVUc1YXQ1ZkFHWkZGdzBNTFVoMmFzYU56V3RzdzRERTY0ZmZvNmo3QVk5?=
 =?utf-8?B?a1JTOXlpZzZmRER1cERESWVoSSt4czZOWnU5ZW9JQjBxRmdBUUo4ZnVNYndN?=
 =?utf-8?B?TmpDOFZIZnYyWHZFaTVlY09PZ2pNd1h0VXJ1MlN3cmxiUnIxMG9sTDR0clJn?=
 =?utf-8?B?WlBoK00wRXdva2dxdUJaTnlMLzJpeHBlRC9uN05OYnY5Mm82RGF5Q2lSMWVZ?=
 =?utf-8?B?RjVnMzdNK2hFYnRrMGNjRTVncU0rSFZIaDdEMnpYcU1qdXZDb3BaQkJ4R1Jq?=
 =?utf-8?B?RmdYeW5GSWpNOUx5VmltQWRKM2d4MDhOZU9KUWVIbDJkRUVNeFNKbk9Xd1Zn?=
 =?utf-8?B?T3JzNnBKRTJpcnFpOWJ1UDA3cmdsT3A1blNpNlhDVk11ekxBRGV2MXhUOWpW?=
 =?utf-8?B?SGxYb0luclZBTndmMlltSzRNNEc5cnpkcjltSHUrNGNYV0ZxaW1ZbXA2bEph?=
 =?utf-8?B?UW9SdU4wOW1HWXJIQXZXTks2OEtZc2g1SEwxRTl3aU9pRmlzWGpTemhzcWgv?=
 =?utf-8?B?dXFkdEVING5tRnRwZHFCNzBaUGkrRHUxWkhiUG5pKzR5dlpJWmMySFUzc1oz?=
 =?utf-8?B?ZjNMeEgyMHFLY2FIM2ZpVTF6WUwxQ21sUlBnZ0kvQzE2Z0FjVWtPSkY1NWJM?=
 =?utf-8?B?NjRNYXhDc0IzRUVmeXBGTmgvUERBcWdXeVFCc1RkNjcySGtOSUNPN2F3MXlp?=
 =?utf-8?B?T2t4TmpQMGM3Z0gyRkxPZTJlV1lZdGxwVnN4Qm1jL1F6RU9BcUE5SDdad3Vu?=
 =?utf-8?B?Z2pDMjF6NmxkcVFtQ0tDays0aDVYcnBpRWl3UGtETjRWa2ttcVBaN1V3dHFa?=
 =?utf-8?B?dDZ5WTdETkZZYWowYVpOWmpKbWJmSitMdjVsTXdRT2FpaE03SWxBWWdMeFZJ?=
 =?utf-8?B?L1o1bFFuaG5ZNjI4MjRtMW9BUzd0UUZ4RVViYlliTUZhL1JxLy85b2xUdWlt?=
 =?utf-8?B?eUx5alFwQzgvQ29qb1U3WFQ1TG51N0xNcUR0MnRxL1liNFAzaHNlL01UZmZK?=
 =?utf-8?B?WXRkcUVUOFNweGlhUUhPYkxldy90NVA3b1NnaHdSM1pPL2ovTk55S3lXTTBW?=
 =?utf-8?B?WERMbHR6bmZCN3JwZTdDbm5BZXhmVDNYTVJsUk9pTFBmTDBiVERneUNOVEx5?=
 =?utf-8?B?QkRZQmFNbVpKemlaVFhGaHIrM0tlK2FZbGdMTEtpRFAzS1Z3RCtCdGtKOENL?=
 =?utf-8?B?d3o0T2ZIdmxuczljT29aZFJ2N25nUzlJQ09uNUlkR1FybkVVVGFjeGRYc2dD?=
 =?utf-8?B?cDEvenlrc29XTkhWM2FXNkl3TXVpUkQ3Z01md2lMWTU2c1F0ZWc1MjYwcFo0?=
 =?utf-8?B?V0YwclhTbk0xZTBVQm9hR0JMT3BGQnpVNjV2OTN3UUVoNlo4dy9xN2srSklk?=
 =?utf-8?B?SlMwM2JIRnBnMm94bHFZS0lNVWRVd1dTeUF0ZnE5ZlhnWll4azJvQnpIcmJS?=
 =?utf-8?B?RXQzSGhhNHJNaWFlZnlRVkNnbVpBM3F2dk5mSmdoMzRkd2xRQkVvSmNwK1lq?=
 =?utf-8?B?TzViUEVHdENyNklHOEpIeTVoVTVYYWt0amlid0V2UTlXRnJWU2FwdngvS291?=
 =?utf-8?B?bi93UjROQTNVTzA0NjQzSXMzaU5iN0M5ZHp1ZlZFY0pXZ2J3Z0hRaEo5NlJu?=
 =?utf-8?B?aUl0dlR6OWg2Ri9WbThNZE13NENIdVBqVDBwdkpyTFRCUDhtRTNCQytyc1ha?=
 =?utf-8?Q?1eEfRA9nBjl3tEcWqX0O+xQ=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: s5gzwFT8LGMoccznw51Yh+gOML6dMeYoaeIOmgyJtT0d3gzoPx2JSQrbp1arW82tJej4j/6ZQcvPOBv6H3qxv2Ck3fQ6lcPCAcXbpUF09cFdz+FvvM0ncim5NKn4Q8hdl1C2KotgCHFfPMYSwDtAkaiuyxxIJpEx7pgCI9zLTca/e2cZPNoeIv00IDn5JXLIU/xFKhb/zz7z3+a6c9qiAhe1dlvvnWwPeO8t/cIVdmM83lCkcX6S9eNXLhIBV7lXtoe4G1q5bRQiGaueO/yBz98GRw3Sk8J+S6G29RMY3VBvSugl7bM0xndAGOq2nk9/6BUB+4AwAY96f3qkn0icIhyPSSPiRu7lu7b2yeMic5oZ79cdQVRHSWt30xBRMuERzqRZhJHC1AnoJ9hh9lht4rowFUnAFu+wly59sIVLLUrystMcdODLJdBEnMkdeukZ/AOgsF55sUsdNPC+ZIVC87Yf0gtVwEiv5H1MOZFsKgQFjMxIpaRKi5SNU1wS4eTnmn0c2yTit2Krxbh0LbBAdOvTgGGWlgz5/fojj4s8ucYh+KZJXq05YEd/iQVIwjC/yDexrdSbL5WmstO6RozmLB+icmnzN5DINqVeQ8ZBuQU+f8wxvlnGG7H/bZ/Rw4qu3EinfwOcI2uzoxmzAYo3NAGfmHsVwWmlf/9BBN6rpVuJsLsQxbdj/Me3zZt7iXcQ1HpuG0VdkvaEunp41bH4d9SuHuff1rJRIN2o0Y9Hk5YU5TVz0F3BA5a8rKKcKcEsNS9icOZyIh1kTsYfHGrTo7ce7A8uAn1z4SS1HmRCB651l9NPD0oc440uNyIAhay6rCmtVM21Erd+mKSIhONLODZHbQPL6N8/kjxgjMGlff8=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bcbe31d3-3bfc-43a0-7815-08db6796af2e
X-MS-Exchange-CrossTenant-AuthSource: CH0PR10MB5113.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2023 20:35:08.7070
 (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: zg588+2wrHcZYPeeD2Xg6X1/GuYJjunlnqd3geG5EFlafoQmsCSpc6uop2Ae4/OiyRY6Ahkrd4AdwWObUCl0EhCa+Z6qpphp/IjK1VDK9rM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB6300
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-07_11,2023-06-07_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 mlxscore=0
 malwarescore=0 adultscore=0 mlxlogscore=999 bulkscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000
 definitions=main-2306070178
X-Proofpoint-GUID: 9LvBAKC5RbBIaJI-LY9tj7LqWjFTgG8R
X-Proofpoint-ORIG-GUID: 9LvBAKC5RbBIaJI-LY9tj7LqWjFTgG8R
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 6/7/23 11:33 AM, Greg KH wrote:
> On Tue, Jun 06, 2023 at 11:13:05AM -0700, Sidhartha Kumar wrote:
>> On 6/6/23 10:38 AM, Greg KH wrote:
>>> On Tue, Jun 06, 2023 at 10:20:22AM -0700, Sidhartha Kumar wrote:
>>>> As reported by Ackerley[1], the use of page_cache_next_miss() in
>>>> hugetlbfs_fallocate() introduces a bug where a second fallocate() call to
>>>> same offset fails with -EEXIST. Revert this change and go back to the
>>>> previous method of using get from the page cache and then dropping the
>>>> reference on success.
>>>>
>>>> hugetlbfs_pagecache_present() was also refactored to use
>>>> page_cache_next_miss(), revert the usage there as well.
>>>>
>>>> User visible impacts include hugetlb fallocate incorrectly returning
>>>> EEXIST if pages are already present in the file. In addition, hugetlb
>>>> pages will not be included in core dumps if they need to be brought in via
>>>> GUP. userfaultfd UFFDIO_COPY also uses this code and will not notice pages
>>>> already present in the cache. It may try to allocate a new page and
>>>> potentially return ENOMEM as opposed to EEXIST.
>>>>
>>>> Fixes: d0ce0e47b323 ("mm/hugetlb: convert hugetlb fault paths to use alloc_hugetlb_folio()")
>>>> Cc: <stable@vger.kernel.org> #v6.3
>>>> Reported-by: Ackerley Tng <ackerleytng@google.com>
>>>> Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
>>>> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
>>>>
>>>> [1] https://lore.kernel.org/linux-mm/cover.1683069252.git.ackerleytng@google.com/
>>>> ---
>>>>
>>>> This revert is the safest way to fix 6.3. The upstream fix will either
>>>> fix page_cache_next_miss() itself or use Ackerley's patch to introduce a
>>>> new function to check if a page is present in the page cache. Both
>>>> directions are currently under review so we can use this safe and simple
>>>> fix for 6.3
>>>
>>> Is there any specific reason why we don't just wait for the fix for
>>> Linus's tree before applying this one, or applying the real fix instead?
>>
>> I missed Andrew's message stating he would prefer the real fix[1].
>>
>> Sorry for the noise,
>> Sidhartha Kumar
>>
>> [1] https://lore.kernel.org/lkml/20230603022209.GA114055@monkey/T/#mea6c8a015dbea5f9c2be88b9791996f4be6c2de8
> 
> Great, is that going to Linus's tree soon?
> 

Andrew just added it to mm-hotfixes-stable so it should be in Linus's 
tree soon.

Thanks,
Sidhartha Kumar

> thanks,
> 
> greg k-h