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 D6501C3DA61 for ; Tue, 30 Jul 2024 10:01:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7205A6B0096; Tue, 30 Jul 2024 06:01:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A7FB6B0098; Tue, 30 Jul 2024 06:01:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 548E86B0099; Tue, 30 Jul 2024 06:01:58 -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 369A96B0096 for ; Tue, 30 Jul 2024 06:01:58 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D120A80206 for ; Tue, 30 Jul 2024 10:01:57 +0000 (UTC) X-FDA: 82395977874.18.13DC2CC Received: from m16.mail.126.com (m16.mail.126.com [117.135.210.6]) by imf08.hostedemail.com (Postfix) with ESMTP id DD29D160008 for ; Tue, 30 Jul 2024 10:01:54 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=hBWHkdiZ; dmarc=pass (policy=none) header.from=126.com; spf=pass (imf08.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.6 as permitted sender) smtp.mailfrom=yangge1116@126.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722333655; 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=ZLcbpVCULNRrBnozP+gUuxo88BIerhBLHccbm3mX2/o=; b=z9S3NxKz6tH7pNLrGIUn5SVb2+wvczkdq3+kARzly0NTOn4o9ORrYkDLQhX/mBZrlUBzaI 6nHheM+u7os/B/l1WMDz0sbFjcEUB0rmmGYWRJF3ukdJo/8BboiHxvJ1tI/jqAsL48Jv7K Hsk2lARdS69DCthq6RRYzLdEZIy034I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722333655; a=rsa-sha256; cv=none; b=gQAmOZD7kjzwUSH/oBUOR0bpUvzyu3R1K9xH755srLADyOko8n6c/Hx4R0fuaSffIlMCA5 xcU6c2Qvkjmbocuc+Br17LS4dENnoX4Dtlvu4JRoFmK8S4b65c2UZFblxjEJdhTcAX45Md HFVRB2mF4vuLd/PfPihbb3zPeFSXFAM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=hBWHkdiZ; dmarc=pass (policy=none) header.from=126.com; spf=pass (imf08.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.6 as permitted sender) smtp.mailfrom=yangge1116@126.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:From: Content-Type; bh=ZLcbpVCULNRrBnozP+gUuxo88BIerhBLHccbm3mX2/o=; b=hBWHkdiZY+IiOOhDa/TGrGVXw83g/Wp15tpiiYWaxcR40ci7D/x8/DKnUsJcFK k3yfLqeLoFbCMrKs77Epe5RAQR3dH6oUAzak3OGx4/UWBSEmSor5b1ZkgQLVs2pW Hi+4ankNvHGxT7eeC2IXEqkQya6YwgJyDwfV0E4L/rtM8= Received: from [172.21.22.210] (unknown [118.242.3.34]) by gzga-smtp-mta-g1-0 (Coremail) with SMTP id _____wDnr_kJuqhm1wPgAw--.37433S2; Tue, 30 Jul 2024 18:01:46 +0800 (CST) Message-ID: <18cdbd92-81db-42be-a290-08462759ffe6@126.com> Date: Tue, 30 Jul 2024 18:01:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] mm/gup: Clear the LRU flag of a page before adding to LRU batch To: David Hildenbrand , akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, baolin.wang@linux.alibaba.com, liuzixing@hygon.cn References: <1719038884-1903-1-git-send-email-yangge1116@126.com> <3a2ab0ea-3a07-45a0-ae0e-b9d48bf409bd@redhat.com> <79234eac-d7cc-424b-984d-b78861a5e862@126.com> <9e018975-8a80-46a6-ab38-f3e2945c8878@redhat.com> <1c5f1582-d6ea-4e27-a966-e6e992cf7c22@126.com> <9f1b8c87-6ea4-4f88-9332-13ac4b1b35d9@126.com> From: Ge Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wDnr_kJuqhm1wPgAw--.37433S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7ur13Xr1DWrW7KFWUZrW8Zwb_yoW8Zry8pr WxG3Wqqr4kJr9Fyr4qqr1UJFyUtry3Xa1UXF43GrnrCFn0yrn7Gr47C3yUCFy3Ar1DJF10 qa4Uta4xXa4UZFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jYOJ5UUUUU= X-Originating-IP: [118.242.3.34] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbiWQosG2VLbyXSowABsw X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DD29D160008 X-Stat-Signature: bwhjwfjzbg7mcce7jjkcxbjhkz1jfoy3 X-Rspam-User: X-HE-Tag: 1722333714-798129 X-HE-Meta: U2FsdGVkX18Su+R7/icEd50TJLLZpHlQe0pDBxJLOkYG3o8NNJIXO1d33LUZT8IlYcaORKsa2s5qerTyqgMc7q2ze1kob1Y5wsfca/5f1aWC9+7MuD0Yvvjp7KRWfzRF+fzTm3oWgBRhwAU4q2APkDhw/+xY6znjp+9KSt/jcc6QiDudAkQC8A2laLq2SJ0ZD7GGlHI3wq/MpZCm8EUSxCA0QmxHHEkAOZO4E10vfNJI+IkKc5ui0T/JXOs+bEy919D6wWxSFE9eAIzA6Y39L/C4cNArhl3WKepZHHiDo1l7RX1TwOUGRjriiD74V0b0EV7nHrY08z32UfQBv5L0WsTo2BAk4R67oS+dimq4pPc+S4Y6B9XNn2v1fvU2cgZEc/jL3vHuheHqijGekZQl72WWG87PIX/XXtu7uQzenbAXQ9VVQtcuaDqdUvInfYIn52Vwvc2h3DxdTfnKt/C82a049Nq0W/fTVX5yQj3Im2QFMZ1bpm791WSvA0ZwBvtp3BvcmVrOTgHaDXWaqYCRk69LiNbPvkTIsmh4T4bs5dQCT/VWfovPioAJUeuzsgEylKZTfnMCCyI8sAzaKLIqh1UcDgpOgZQYexUMPk5oAFjusGi3Mtb5QEgJW/b+nlHKKnZ4foOkkuJAcUUPJMASSR1RfFgArr1S1nHHpNm3DN0lOwtYKVjB2L3YlVK//xG0ROrKk0b577ktSVkMPbQ2MzUcxK9GUFqucxnYiTNxuY0BlF6RJYhJDTmlKODIKa0+vuc812XgoS4qZk/FuM2ra3gekBhH5hEsob/i5rY80KaOtT0lHNqyVAJUwbv9BotkhqC/kibg8E7UBrbpX4yiznTtVeB+bgDEeNQG26YR3PZoB7UpsDO1G2W73ySH5bkGT5doGy1eqHnDyBPzLx9sJBcpE+eHVvaty7nKd9Bl5pOaV7abHT8cIix/dq8E/SgoZOmHn2JYvDsAg064wB8 cL6QfVEP qck8DMoEHQmPDU4qoScgjO4bn3I6gPIdc4MWZdb+yYlUUJ0Y3mloj88WCMmtoetTgnQ6CUwk1RFqCcvKK7a6X5zAaEc5PvlsvtkZ2jvpH7tOkasH7wBAIPcBG2LCzMv9tXqTLE/zDF4F+CFOswgriSOJZUUa9C/GXjs468lPC40Tf7bdCHYn8i3yNLzupYubKfCmEzeiGFcBX8tAU7iH8oMUE37aEKJHWvbR0SC6t7T/yGfQwuSJDiuuaFicgwsHd0vuaNfw4bd9ApP2RMeygxCvBJ9f95d/LaOTXHkSpkyvQn7Arq1RMaXOmsom24B0qrCMDqn4dN+qluiGFCuUKTWQqwvp4kX9vS6CBk6PNyXUkvd+5ADqKnd59lQKecsUsxVjuadrvg+OPClooVnng/0dyr+aM3v+NSnr7dJ3tapP1rxGkJdlNlDxV/cXZESUwjudb4Y4KBHy4HwUKDlVPm/7JiA== 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: List-Subscribe: List-Unsubscribe: 在 2024/7/30 17:58, David Hildenbrand 写道: > On 30.07.24 11:56, Ge Yang wrote: >> >> >> 在 2024/7/30 17:41, David Hildenbrand 写道: >>> On 30.07.24 11:36, Ge Yang wrote: >>>> >>>> >>>> 在 2024/7/30 15:45, David Hildenbrand 写道: >>>>>>> Looking at this in more detail, I wonder if we can turn that to >>>>>>> >>>>>>> if (!folio_test_clear_lru(folio)) >>>>>>>         return; >>>>>>> folio_get(folio); >>>>>>> >>>>>>> In all cases? The caller must hold a reference, so this should be >>>>>>> fine. >>>>>>> >>>>>> >>>>>> Seems the caller madvise_free_pte_range(...), calling >>>>>> folio_mark_lazyfree(...), doesn't hold a reference on folio. >>>>>> >>>>> >>>>> If that would be the case and the folio could get freed concurrently, >>>>> the folio_get(folio) would be completely broken. >>>>> >>>>> In madvise_free_pte_range() we hold the PTL, so the folio cannot get >>>>> freed concurrently. >>>>> >>>> >>>> Right. >>>> >>>>> folio_get() is only allowed when we are sure the folio cannot get >>>>> freed >>>>> concurrently, because we know there is a reference that cannot go >>>>> away. >>>>> >>>>> >>>> >>>> When cpu0 runs folio_activate(), and cpu1 runs folio_put() >>>> concurrently, >>>> a possible bad scenario would like: >>>> >>>> cpu0                                           cpu1 >>>> >>>>                                               folio_put_testzero(folio) >>>> if (!folio_test_clear_lru(folio))// Seems folio shouldn't be accessed >>>> >>>>           return; >>>> folio_get(folio); >>>>                                                __folio_put(folio) >>>>                                                __folio_clear_lru(folio) >>>> >>>> >>>> Seems we should use folio_try_get(folio) instead of folio_get(folio). >>> >>> In which case is folio_activate() called without the PTL on a mapped >>> page or without a raised refcount? >>> >> >> No such case has been found. But, folio_put() can be run at anytime, so >> folio_activate() may access a folio with a reference count of 0. > > If you can't find such a case then nothing is broken and no switch to > folio_try_get() is required. > Ok, thanks.