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 EBCB4C369AB for ; Thu, 24 Apr 2025 15:22:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD1006B0012; Thu, 24 Apr 2025 11:22:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D556D6B00C7; Thu, 24 Apr 2025 11:22:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA6E76B00C6; Thu, 24 Apr 2025 11:22:32 -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 976BF6B0012 for ; Thu, 24 Apr 2025 11:22:32 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DC5CBBF98E for ; Thu, 24 Apr 2025 15:22:33 +0000 (UTC) X-FDA: 83369304186.15.1747417 Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by imf17.hostedemail.com (Postfix) with ESMTP id 6421E40007 for ; Thu, 24 Apr 2025 15:22:31 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=n4A6KdvM; dmarc=none; spf=pass (imf17.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.181 as permitted sender) smtp.mailfrom=axboe@kernel.dk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745508151; a=rsa-sha256; cv=none; b=z6qqIO/roua0zbTPepQnIIkr2X0t7NZl3FxnrxOQAb6OSsiepWsx8HWJONX6e0HxIG2hnT RdXZ8dNk+2KJmdac5DD2AgJMRrMw0pRBueG7pE8mnbuH7U0KdaBny7KpFMQg7wiNdvAhK8 VqyzGGBqYF6PZ2iPSoH1ORelJ96O9RM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=n4A6KdvM; dmarc=none; spf=pass (imf17.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.181 as permitted sender) smtp.mailfrom=axboe@kernel.dk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745508151; 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=fmCX/oOcvrNdDEnAxMn0eyeoPuQt/o60LQX66Sq9Cq4=; b=gWhlXVGqj/TxNaXpimhoRSHjapKz54CxhCeZTCsKhatOrUknlmnRo1ro3qKdifCkGGl+QI YIr2IrwSsbi9NeZHlH4diVHrNF9S/mUaE/THPwo4AyI523rHoP1ibEFwfMVeN8leRftExn qt5gLRs1xvyzqLaGP6cBR/R2Ba1KO3w= Received: by mail-il1-f181.google.com with SMTP id e9e14a558f8ab-3d9189e9a06so4247985ab.2 for ; Thu, 24 Apr 2025 08:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1745508150; x=1746112950; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=fmCX/oOcvrNdDEnAxMn0eyeoPuQt/o60LQX66Sq9Cq4=; b=n4A6KdvMD4Hy/q7RStVU82t60K0CirMJvT9mKeCrlGDB+BJvzwL12tfOpGNDFrpY9B qhazaAdWrzPeFrUMG2nZ078ZBrEyGwiwYXi6SIiKfEAdEgptc3/+xeD9tLx6weow+Ypl L3zs20dgm5mitzWAbxTNzXakkBU4BAdC6mTUWTgl3JTcWJ4vJh1xdBPvSbODfM6w8ayO VqQKWHo3kEkvuNkvWotSUyzs0KeObBC3jU9wQRuCt1bZvzcUf0HPSNRqEKrZj5hD8BTm Wxl1FofO4BqEPKB1ct4MVHNAEEimVYnNsvx+uaWB7ImsQmk6OgnCrfHS1iu7sEThREbf 6j/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745508150; x=1746112950; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fmCX/oOcvrNdDEnAxMn0eyeoPuQt/o60LQX66Sq9Cq4=; b=IZONcYso3+Frh6lBlZZzQiUM1Arjd7KHRqVBljOv/AUftl4WVjmIXsF4BkHzdMd1zm 3InVwAaJTlhMliEYO9NnPRbqRGaNRyoLcFTrdKm4W9hStWKNRJOPE281+RYxg4VPRDMV ylHYgifFQSGzkbCDUdj6Z32u4lFUlA2C4MaDGS/KJZ+tv49BSr21Uobej+1wr5zhGt+f QJefxrrmtbRbhZQA3YRKXCk0NjpqT0daoqf85fAZz25+8E2Z1BHWJvBoHaVvvCtQnS9p mhDuHsDJ9lxjl+x7ZB8QFXg+LQ0RfB5Bcl/xPXqWlbB68doMBPY409YqB3YqHsCF1ODb sFdA== X-Forwarded-Encrypted: i=1; AJvYcCX0+WL0o5GVm56SLvBa5Dg9tr81MLZUi4L3kv2VIIOVdzAfCg15nylj/xXD3hivonVVqlnN1jNCeg==@kvack.org X-Gm-Message-State: AOJu0YzpcuhwQ2kzXUW6n/hGAzdEynHRCuHde+XINgB8UmAoJ2AzsJjB BuCDuTDLTOR9DYKR9Xy7LgoOkd8BRfYH3PQHynzmIryQ382DvkzL78AyV6axjiA= X-Gm-Gg: ASbGnctiS0IN1AVvi9UggMXxs8fw7isFA2g4qMbuaB0hXPaUMQtX38sPxOnCtxY3IK4 ZJLsKSkRUU7MTsFsfj8cZD/cn4moKJNffLvq3d1Jm0Yob0EG6Xmdrot6DvUehB1yswWAbaJfGqn RvYW4tEn73DV7jcV404gKASH2KPAgtzzQkxbNbvWF2OrC5P60GPQiqEOJUQGrzJ2MFN42ADHwfZ JdczaetAd8cDXc9HKwUMVef4Ii/ZuWQxabDt6ePLNS0T3tmriFa3A91+8444CvMdtDq81R84fqN QDSHjEnHJTkX18ZGnc+92nRYF3h9Tzyv0zqQ+OPc+5ySAzY= X-Google-Smtp-Source: AGHT+IEMJLQ6alo/SeAQVIhLk2MPC52fNge1ln6vSauIlwzfyiVyMfKC2I2QO6XMfahKn9L+ZuL2Sg== X-Received: by 2002:a05:6e02:1a25:b0:3d8:975:b825 with SMTP id e9e14a558f8ab-3d93038f94bmr35105055ab.5.1745508150445; Thu, 24 Apr 2025 08:22:30 -0700 (PDT) Received: from [192.168.1.116] ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d9314f5fabsm2937385ab.36.2025.04.24.08.22.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Apr 2025 08:22:29 -0700 (PDT) Message-ID: <26fa8c43-7e7c-4610-bbf5-031f3e07eb74@kernel.dk> Date: Thu, 24 Apr 2025 09:22:29 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/userfaultfd: prevent busy looping for tasks with signals pending To: Johannes Weiner Cc: Andrew Morton , Peter Xu , "linux-fsdevel@vger.kernel.org" , Linux-MM References: <27c3a7f5-aad8-4f2a-a66e-ff5ae98f31eb@kernel.dk> <20250424140344.GA840@cmpxchg.org> <20250424151113.GB840@cmpxchg.org> Content-Language: en-US From: Jens Axboe In-Reply-To: <20250424151113.GB840@cmpxchg.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 6421E40007 X-Rspamd-Server: rspam04 X-Stat-Signature: mknnrsn873oz54ijkipgqbimt4887fie X-HE-Tag: 1745508151-36935 X-HE-Meta: U2FsdGVkX1+yxydeFuGtW7VlivsrKao/v8JC4lsp8Gu4vEXCIxRSNiAhs34Qg+OUCwZp/AfRey/FGAN9sOckUf2l2cq8U+v4z69V6fBwVe9UYXbV/7FbWLQ4yBj0zsxkzw20WxJ/EIUGr98BW9yR60rut6H9wKJV/Hq4hQB9Kkjk0Tw9Owve1i6VofBWqk1OMbuYyiy3/2KFasIlC4IL8w4RJlxFJJKPkpSsz+hEDDCCAcilvuKYx7M3+ew1xWXHvD2gTXAuTvoORawgN2qs6f6cutIK8QN+DwU8jawrhBMxX/7NGYHczUmnnFdwJoHJgyKx0DeZmEPteJ7qNz0cu0Tpu07e4Fbg5UH7g9/acoxzULDq8+uAKJ+McO0a47abpIycRKX9BemfDcyQMW2+sMva/D2gp8sr90FBNNZKY6O6at+t+NGUnC+tCjiED8Q0WyBDoP7cJWRQcjqvwpcB+JVZZeofIS+aypGvIs7fG8CgvOSii8dR9VdWWJ9iS7pSjPkgQbMXe6lERMA3Gh1GtQLaXMdXL8ixzBwBsk6jAvCX8DjP6m4XtQ962tiM2mC5NXFi9YJ93OSIo3fuc8l2U1zErBZDZjvCTZVpJtUhoPBV8mpjGWQ7YAFQNT8QiPD2kO78ojc2iWvxjEd1mPqKpqjZDFRfrSZ66oZnKhurkSnFyD8YoZnZK3W9N0njA7vZ1fDL1Y5r65lBsooTzIQ539El9fHOQSQL4srdzxNs9jnpxnAiigJiLBP2XEu3H9asRJbT2fLub5LttxwkRhyah3clMj4I/9c710deoD648tmFB8lBArkQR4up3iY3FnmCY6AFdpYMZ/iaXIk/trU/6TTYvhgak06r2gdnt09sr+33WnciEh1daWRXd3fEKWvlOkG2FXRNFT8v7RtLv3iDCayxvn6cY9FpjdlGnEYUR9S0UnQo66PwRHoRHMqyRJhbytqAeP71g7UJuOeNxAA K+iwYg69 gltRqhwlcGbJSEBjQF0Gw/2mIoN/q6YBCL8LsxIyWztXiGEGXwwDosSdgKlFKrjaCAiHgn49DmUbI3FrIcSltJYL0Hvluz9f2O2FY89eicd8UbZM5eL98KdQ0ccfoUcQP4A/suqphfd5o/s6gWDMknXEs21rjZe90prqfq1FMpfhiCQdXkPvdorLBu8EsEf4JV1qOvU3y5iX8Vr5MFARHZQD7K4/qL1wuM66uJuiC4uXkqHJB/MUpPUgX0U2oI8YUQCx3TLUYJJYUtcc71HHWsKs/Z3VwEaxbbxaFTat1e0GSM8WaD7+6KodWLHChTFInfti7iNx7o0l/bQ+B+AIOkoOrgmmXjNzm/izisgdnza+23mpcwluoMrcC/z1fJOm66FdrYn7pjwVHdsU= 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: On 4/24/25 9:11 AM, Johannes Weiner wrote: > On Thu, Apr 24, 2025 at 08:54:40AM -0600, Jens Axboe wrote: >> On 4/24/25 8:03 AM, Johannes Weiner wrote: >>> On Wed, Apr 23, 2025 at 05:37:06PM -0600, Jens Axboe wrote: >>>> userfaultfd may use interruptible sleeps to wait on userspace filling >>>> a page fault, which works fine if the task can be reliably put to >>>> sleeping waiting for that. However, if the task has a normal (ie >>>> non-fatal) signal pending, then TASK_INTERRUPTIBLE sleep will simply >>>> cause schedule() to be a no-op. >>>> >>>> For a task that registers a page with userfaultfd and then proceeds >>>> to do a write from it, if that task also has a signal pending then >>>> it'll essentially busy loop from do_page_fault() -> handle_userfault() >>>> until that fault has been filled. Normally it'd be expected that the >>>> task would sleep until that happens. Here's a trace from an application >>>> doing just that: >>>> >>>> handle_userfault+0x4b8/0xa00 (P) >>>> hugetlb_fault+0xe24/0x1060 >>>> handle_mm_fault+0x2bc/0x318 >>>> do_page_fault+0x1e8/0x6f0 >>> >>> Makes sense. There is a fault_signal_pending() check before retrying: >>> >>> static inline bool fault_signal_pending(vm_fault_t fault_flags, >>> struct pt_regs *regs) >>> { >>> return unlikely((fault_flags & VM_FAULT_RETRY) && >>> (fatal_signal_pending(current) || >>> (user_mode(regs) && signal_pending(current)))); >>> } >>> >>> Since it's an in-kernel fault, and the signal is non-fatal, it won't >>> stop looping until the fault is handled. >>> >>> This in itself seems a bit sketchy. You have to hope there is no >>> dependency between handling the signal -> handling the fault inside >>> the userspace components. >> >> Indeed... But that's generic userfaultfd sketchiness, not really related >> to this patch. > > Definitely, it wasn't meant as an objection to the patch. The bug just > highlights a fairly subtle dependency chain between signals and > userfault handling that users of the feature might not be aware of. > Sorry if I was being unclear. It was more for the clarification for others, I know that you're well aware of that! All good, I'll send out a v2 with the Fixes tag adjusted, just to make it easier on everyone. -- Jens Axboe