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 DF824C761A6 for ; Tue, 28 Mar 2023 21:43:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67D556B0074; Tue, 28 Mar 2023 17:43:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62D876B0075; Tue, 28 Mar 2023 17:43:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 544A6900002; Tue, 28 Mar 2023 17:43:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 456826B0074 for ; Tue, 28 Mar 2023 17:43:04 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0F70D160C2B for ; Tue, 28 Mar 2023 21:43:04 +0000 (UTC) X-FDA: 80619632688.13.2931F5D Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by imf18.hostedemail.com (Postfix) with ESMTP id 418BB1C0017 for ; Tue, 28 Mar 2023 21:43:02 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=CIzmU5iq; spf=pass (imf18.hostedemail.com: domain of beaub@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=beaub@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680039782; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+850YOqLoGdgtDg3iL3aEjBqFLOqMf5TEeXHkCzL97I=; b=kwHrbolgQFdX6CIKXc3TAv1+sNkVhmHCLUJngoI8/jjYjVS0skHdhaP+afQw/mG2P4IBdo 7oiLFwSnalOnsz72mqhVhNIXdCcZk/NHT1ZrSti4hFW9D0onTC3l6Rs+1ITtEJOWbVFna5 /DspaHTCql3VO87aeaY9uj2Qwoqmn1c= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=CIzmU5iq; spf=pass (imf18.hostedemail.com: domain of beaub@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=beaub@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680039782; a=rsa-sha256; cv=none; b=DnyeH05oXpIAflKB+W1LpOE5sGtFnkjCtZt2ViQcvm8kOVa8pXhV9/6Wp1OKG3w5LzOnJG ig0/ezj9lZkNnDfeQEApSNc/rpX7eh4HcZEdl+gj1B48cJZp2ch2gUA4//KsTsy9/in3qt yo6LpQGlylriLiOZ/nt1jh32PD7HaXs= Received: from W11-BEAU-MD.localdomain (unknown [76.135.27.212]) by linux.microsoft.com (Postfix) with ESMTPSA id 6DCE820FD93E; Tue, 28 Mar 2023 14:43:00 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6DCE820FD93E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1680039780; bh=+850YOqLoGdgtDg3iL3aEjBqFLOqMf5TEeXHkCzL97I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CIzmU5iqR8HdDZffizvvLtEB9Wt/Y9BX4SAEK9yQsNcE5JwqCzAAISeFlMKvopgqf 5ZJ1LAhKvoQcXr7t2fWrqz+LzhBlsVmr5fiXIDugexcb1rcK9hUjEh1P4dU6mJdcAI kk+orsVZCV/HMwHKo9yJQGM/4+cBivYqwU9GU9lE= Date: Tue, 28 Mar 2023 14:42:54 -0700 From: Beau Belgrave To: Steven Rostedt Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com, dcook@linux.microsoft.com, alanau@linux.microsoft.com, brauner@kernel.org, akpm@linux-foundation.org, ebiederm@xmission.com, keescook@chromium.org, tglx@linutronix.de, linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v8 04/11] tracing/user_events: Fixup enable faults asyncly Message-ID: <20230328214254.GA85@W11-BEAU-MD.localdomain> References: <20230221211143.574-1-beaub@linux.microsoft.com> <20230221211143.574-5-beaub@linux.microsoft.com> <20230328172049.10061257@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230328172049.10061257@gandalf.local.home> X-Stat-Signature: rox4oox4wetsyccpzyfustu674gw816r X-Rspam-User: X-Rspamd-Queue-Id: 418BB1C0017 X-Rspamd-Server: rspam06 X-HE-Tag: 1680039782-789224 X-HE-Meta: U2FsdGVkX1/UOyqWDnA9AnZlRqose8BFpeb3FTo8IMdYXK5DKwfWgJwjXLo0bIxopVCnzG8x/wxIpE2jC+42dGJ99BVO8W7eNQroRV95qyrLkJdKcJWHVEkWfu1VA9EIi4T4FGOB92H8V554UwPE8pndnbXpystuqHtaoXfYj9ZfLX2EzNGZV/1OofZkdBHcNOlY7wl8GPh9n4bvGqhmDUqjYzp2XZZEsK2twF7fEpal28jx7owxITprsf1QyIf9RlWjYcd3/bIIudMI+PJcml3cfDESIz3OrNVlOkSdp+KwBV6RsgUpZizO6qSUUCJTRNmnUCuIdkcV6gwSy/JGdAdxcejPQqMioWwJXNq1mrMPwcq9uA5kyhrxUoa9UytuOya60aHaywKYfSwhYJQam5D3fKOgheQLEz5L737toUju0zMdongWsQa3ikssOfKovlSRlwW/o4+JREIrdFkypOgUU+eqQUxrtQPbx83S/1MDVFUhGv0e4S8o25MRXwOBpnbcsE04p+4Qsy12Eeoq6SGi8BC/2b8aI5aM7O29rk6YoWEVwfzBLiHcfSdqBtzsyq752lkwzua5Jv8CWKaGpFNlK95IEOhTNcOe3TG69y5V/r4tmy0WyX3gEZ+DJK/tc/o7TNv6DzqW0nzIi0MMZkR/U0fXu9PNaup4eXaGItMz+CQCmWb0RSZ7BqKpjqxacJBYnFIboKBPtZNsyA7M4ziMrc601HVcPSYebC4YoocBHDc5nETlYevJ+rbvyZ9te3XzzX1heEEFlVgUsGK7wghuQ4vHtkfY37gq8gsyX+zYCbee7nJ2YqLo7xBt9vEIScEYnG/h/a9PfcgacP5+TdVFS4GJH+RL8DJfX7SvLKQtWZ9pSSlgBRuzXbEmdSAA4ZRkKTmBaELKjnj/7Cycak2+T2kTeqHzWiBanTq1I/U+9dY8akNdpZ4Zqj3rl06fOpmKYUAMWlmgSYhjgMb bNgUJGiW qGIU+r4Z7JzTnhJdm8j4V4lSgxFDhZdX48ev+3a7RYKAfSrdrtlq5HQ7AqA9z13MuZD6PFiW1t3IEIU1026JN1Kghdisrn2v1MMxJitlTGegoW2GFplxaSgwI1n+56C8WhxjLuNyY0pkxZS32iCbT24djCgI1B9+xaPkgT2TG4chbfFdE8cNZfN+r9KrWnzc7mp5s4s2Pq9jvnDIvrNbyMVVTPrT7tdm6uX/HDqtAs3twAvnulZEy/w+C85YQcYB33bGskPTlUc60zkjp80zgD9VyzWon6MvA83tDoeiTh64wehBw/gKZw57iWg== 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: On Tue, Mar 28, 2023 at 05:20:49PM -0400, Steven Rostedt wrote: > On Tue, 21 Feb 2023 13:11:36 -0800 > Beau Belgrave wrote: > > > @@ -263,7 +277,85 @@ static int user_event_mm_fault_in(struct user_event_mm *mm, unsigned long uaddr) > > } > > > > static int user_event_enabler_write(struct user_event_mm *mm, > > - struct user_event_enabler *enabler) > > + struct user_event_enabler *enabler, > > + bool fixup_fault); > > + > > +static void user_event_enabler_fault_fixup(struct work_struct *work) > > +{ > > + struct user_event_enabler_fault *fault = container_of( > > + work, struct user_event_enabler_fault, work); > > + struct user_event_enabler *enabler = fault->enabler; > > + struct user_event_mm *mm = fault->mm; > > + unsigned long uaddr = enabler->addr; > > + int ret; > > + > > + ret = user_event_mm_fault_in(mm, uaddr); > > + > > + if (ret && ret != -ENOENT) { > > + struct user_event *user = enabler->event; > > + > > + pr_warn("user_events: Fault for mm: 0x%pK @ 0x%llx event: %s\n", > > + mm->mm, (unsigned long long)uaddr, EVENT_NAME(user)); > > + } > > + > > + /* Prevent state changes from racing */ > > + mutex_lock(&event_mutex); > > + > > + /* > > + * If we managed to get the page, re-issue the write. We do not > > + * want to get into a possible infinite loop, which is why we only > > + * attempt again directly if the page came in. If we couldn't get > > + * the page here, then we will try again the next time the event is > > + * enabled/disabled. > > + */ > > What case would we not get the page? A bad page mapping? User space doing > something silly? > A user space program unmapping the page is the most common I can think of. A silly action would be unmapping the page while forgetting to call the unregister IOCTL. We would then possibly see this if the event was enabled in perf/ftrace before the process exited (and the mm getting cleaned up). > Or something else, for which how can it go into an infinite loop? Can that > only happen if userspace is doing something mischievous? > I'm not sure if changing page permissions on the user side would prevent write permitted mapping in the kernel, but I wanted to ensure if that type of thing did occur, we wouldn't loop forever. The code lets the mm decide if a page is ever coming in via fixup_user_fault() with FAULT_FLAG_WRITE | FAULT_FLAG_REMOTE set. My understanding is that fixup_user_fault() will retry to get the page up until it's decided it's either capable of coming in or not. It will do this since we pass the unlocked bool as a parameter. I used fixup_user_fault() since it was created for the futex code to handle this scenario better. >From what I gather, the fault in should only fail for these reasons: #define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS | \ VM_FAULT_SIGSEGV | VM_FAULT_HWPOISON | \ VM_FAULT_HWPOISON_LARGE | VM_FAULT_FALLBACK) If these are hit, I don't believe we want to retry as they aren't likely to ever get corrected. Thanks, -Beau > -- Steve > > > > + clear_bit(ENABLE_VAL_FAULTING_BIT, ENABLE_BITOPS(enabler)); > > + > > + if (!ret) { > > + mmap_read_lock(mm->mm); > > + user_event_enabler_write(mm, enabler, true); > > + mmap_read_unlock(mm->mm); > > + } > > + > > + mutex_unlock(&event_mutex); > > + > > + /* In all cases we no longer need the mm or fault */ > > + user_event_mm_put(mm); > > + kmem_cache_free(fault_cache, fault); > > +} > > + > > +static bool user_event_enabler_queue_fault(struct user_event_mm *mm, > > + struct user_event_enabler *enabler) > > +{ > > + struct user_event_enabler_fault *fault; > > + > > + fault = kmem_cache_zalloc(fault_cache, GFP_NOWAIT | __GFP_NOWARN); > > + > > + if (!fault) > > + return false; > > + > > + INIT_WORK(&fault->work, user_event_enabler_fault_fixup); > > + fault->mm = user_event_mm_get(mm); > > + fault->enabler = enabler; > > + > > + /* Don't try to queue in again while we have a pending fault */ > > + set_bit(ENABLE_VAL_FAULTING_BIT, ENABLE_BITOPS(enabler)); > > + > > + if (!schedule_work(&fault->work)) { > > + /* Allow another attempt later */ > > + clear_bit(ENABLE_VAL_FAULTING_BIT, ENABLE_BITOPS(enabler)); > > + > > + user_event_mm_put(mm); > > + kmem_cache_free(fault_cache, fault); > > + > > + return false; > > + } > > + > > + return true; > > +} > > +