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;
Date:   Wed, 7 Sep 2022 07:50:57 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Sven Schnelle <svens@linux.ibm.com>
Cc:     Miaohe Lin <linmiaohe@huawei.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Muchun Song <songmuchun@bytedance.com>,
        David Hildenbrand <david@redhat.com>,
        Michal Hocko <mhocko@suse.com>, Peter Xu <peterx@redhat.com>,
        Naoya Horiguchi <naoya.horiguchi@linux.dev>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Prakash Sangappa <prakash.sangappa@oracle.com>,
        James Houghton <jthoughton@google.com>,
        Mina Almasry <almasrymina@google.com>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Ray Fucillo <Ray.Fucillo@intersystems.com>,
        linux-s390@vger.kernel.org, hca@linux.ibm.com, gor@linux.ibm.com,
        Alexander Gordeev <agordeev@linux.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 4/8] hugetlb: handle truncate racing with page faults
Message-ID: <Yxiv0SkMkZ0JWGGp@monkey>
References: <20220824175757.20590-5-mike.kravetz@oracle.com>
 <yt9dr10ok3lm.fsf@linux.ibm.com>
 <Yxd5z0c8NlKVlVqk@monkey>
 <YxeL7ZMoyNmPAvY0@monkey>
 <YxfTA53/5pkpC7xZ@monkey>
 <367db2b5-5242-9be6-1d5f-d13e35f84167@huawei.com>
 <YxgD7qXPgkJ9VgJn@monkey>
 <25ffa1bf-0025-3421-53cb-79f986468cb6@huawei.com>
 <YxgQbSvDzQq7covC@monkey>
 <yt9d5yhzk30d.fsf@linux.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <yt9d5yhzk30d.fsf@linux.ibm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9ZrXt7ZOwotb7ZjRlLQc1PBYYZiTKG0julH1B1jBcUxLgCplYk0WeK7JwyHC?=
 =?us-ascii?Q?YT+PMO6Z1LncgizckWNQLdAKq0jvfn4pgJer0MlUvzC34ECY1pfw3HFYgq4Y?=
 =?us-ascii?Q?lH2rc/yz/IrIgJxUV1tvu92F8ZMLX75CDHzwsRxlwodkVmtAbGJNKu8Om3lh?=
 =?us-ascii?Q?LU6E0CeVVEDwtpk3HCbn9s9lT6JSJ9hbra8umeXrdzyQP5j8JZuxyiAheYCB?=
 =?us-ascii?Q?OETcG567cDqPUAj9wj12RM0zuYXLosfvCzU++Yx7GNMpUrREDDwcN5sqiJLV?=
 =?us-ascii?Q?EeGkyH4PntLUIVtZZrwctCfPHCiEZE5lX0GQuO254QZ8R9pBDDD/A3YW3PAe?=
 =?us-ascii?Q?evdEvCojYel4ENr4ta7ButcJ+xefqr3Kb2kEXLdEpmxf+spU8K3mO8oggr76?=
 =?us-ascii?Q?FPW5Yft1NHo7k6WbuJ4pvp6/TqOXEUYGtM8BKbKbyVjz0ppifR8+XCrUWgod?=
 =?us-ascii?Q?Gf6zXxcEEwTfnz7R28E0x+PAEtz7PJ4iSjS1L2ionaJf49CZx1hBgi0/5qGP?=
 =?us-ascii?Q?AIY3otdDM0+ESP6ivXFdX9uNo3YfyBffS21hkxfVrUNnJlmUZsYRprOtv7Bx?=
 =?us-ascii?Q?ZNTunqG5DQPVqTG0cNA4C+XMLE3Dq9WlISAEbKEUQzGeIbIRotTGMuGfwU9z?=
 =?us-ascii?Q?nsueF4AvY1AfiaC0/sSx+0Bv2fNWsAiNlXJy4WxxL5A6j2GrVEwvbQlTP8u/?=
 =?us-ascii?Q?I3VRGuu3bw1QMtUHTCxq+Zcq/wQOn5z2fcV+WPynRdQWmkviKOgycsd0xmDt?=
 =?us-ascii?Q?LaB2sV+x2PCd/1AhSjHYtcJfJuBONcSkiQm+s7bAzI0W/LQ4sLOtSDK9dlTG?=
 =?us-ascii?Q?5OFGZnTk7uJIHS/SNwS35LoA7KhshffPdqKZRKUrjTtGIOOMr5XCONvEar00?=
 =?us-ascii?Q?8Cz5qzBH3nPByGcW2jMvA0KoFfe1ZAsix4SeUVCYM+AziW5q6dQNqH91fVjE?=
 =?us-ascii?Q?5nUZgpuS+fJxeqi58XgtTuvw6siGpcTIqfpQLVqOg8q857ZB7qJxiRcLmOqk?=
 =?us-ascii?Q?FFZ2oYmBIlu5HtC2ysXrISbzNixB5oZffd8oLZErGuj/HHF3wXM85vw8JtJu?=
 =?us-ascii?Q?31KEytD6jK60PU0s7K1gqb51K0BubEvsGR9RsG1cx5dhFIgPdRnB+85ToqLi?=
 =?us-ascii?Q?Zq9qcsJo4NUT9BPBpJ8TLkT8unI5oVWDRGdz97026UoDekO+LVQjCWNw9rbu?=
 =?us-ascii?Q?BS+aNNifJ3Huzba7SDJkBhw3iBlN0ATq0Ye6MsmXb/ngPrG1o17c5Zgbclbq?=
 =?us-ascii?Q?FPHs9PXEsd/BSSEdAo21oWqAquYA0QlWr5agPJ9O0zeS4mLZmj79y2Hcrl0E?=
 =?us-ascii?Q?N1PMlGCjlm2XlkmPWw1d+USeEH2Nc9Qy4cc4wqSh3kWmqga2EKKm1aOTeO8s?=
 =?us-ascii?Q?OOfA4s7jqbmAtfVZHh7VTQ5z8Dzeuq21xhqd8qnwxKsfSqVy76PeHcEYpe0n?=
 =?us-ascii?Q?wprCmlkYGFgijp5BlHVMVdbFp7KGkpLCiVZx4mZY0xYH+FmwdjFvWt3R6v/p?=
 =?us-ascii?Q?QXbmawdF5UfW9ziuH26jC5ksQITY6PKzcmWOjDKGfJIwu3e7MO/xjRanHakz?=
 =?us-ascii?Q?hp/v96tlLe063osSHENsUhn8hq48Yz72o5wo99ZypVi9Qwz9seeVNNcXMktx?=
 =?us-ascii?Q?fQ=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 414444bd-4037-46bb-69d7-08da90e0615c
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2022 14:51:01.1397
 (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: eqLfaW3K4DCOzXzjYN3dihSKMjQ9SaCRjBOuFlfWe/9zcDHMjgV+xDWhtIgMW35ct5H2zve9UMuU0A2OalCuoA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR10MB6023
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-07_08,2022-09-07_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 phishscore=0
 mlxlogscore=999 spamscore=0 adultscore=0 mlxscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000
 definitions=main-2209070058
X-Proofpoint-ORIG-GUID: 9W-rLXVrZD-OjkjCfWBDdD3fjxf1xeIA
X-Proofpoint-GUID: 9W-rLXVrZD-OjkjCfWBDdD3fjxf1xeIA
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,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 09/07/22 10:22, Sven Schnelle wrote:
> Mike Kravetz <mike.kravetz@oracle.com> writes:
> 
> > Would you be willing to try the patch below in your environment?
> > It addresses the stall I can create with a file that has a VERY large hole.
> > In addition, it passes libhugetlbfs tests and has run for a while in my
> > truncate/page fault race stress test.  However, it is very early code.
> > It would be nice to see if it addresses the issue in your environment.
> 
> Yes, that fixes the issue for me. I added some debugging yesterday
> evening after sending the initial report, and the end value in the loop
> was indeed quite large - i didn't record the exact number, but it was
> something like 0xffffffffff800001. Feel free to add my Tested-by.
> 

Thank you!

When thinking about this some more, the new vma_lock introduced by this series
may address truncation/fault races without the need of involving the fault
mutex.

How?

Before truncating or hole punching, we need to unmap all users of that range.
To unmap, we need to acquire the vma_lock for each vma mapping the file.  This
same lock is acquired in the page fault path.  As such, it provides the same
type of synchronization around i_size as provided by the fault mutex in this
patch.  So, I think we can make the code much simpler (and faster) by removing
the code taking the fault mutex for holes in files.  Of course, this can not
happen until the vma_lock is actually put into use which is done in the last
patch of this series.
-- 
Mike Kravetz