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 X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D355C11F6A for ; Fri, 2 Jul 2021 06:25:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D04016141C for ; Fri, 2 Jul 2021 06:25:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D04016141C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1E6166B0011; Fri, 2 Jul 2021 02:25:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 170266B0036; Fri, 2 Jul 2021 02:25:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F03886B005D; Fri, 2 Jul 2021 02:25:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id C48256B0011 for ; Fri, 2 Jul 2021 02:25:50 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6CB941803281F for ; Fri, 2 Jul 2021 06:25:50 +0000 (UTC) X-FDA: 78316662060.02.4E7E929 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf21.hostedemail.com (Postfix) with ESMTP id 2DA82D00017F for ; Fri, 2 Jul 2021 06:25:50 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id pf4-20020a17090b1d84b029016f6699c3f2so8501972pjb.0 for ; Thu, 01 Jul 2021 23:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6gR7+oJ7XUI6MhB8zU2feJZoMeVNHRmve9e7TtBVXiM=; b=lut5GHGzEENqE8c4bauh/TlTusHss46DVGXnM+uHrZNQa2tVs3OSIJno9FEvBX0IEE DRd0IxZVKcqShqReCftvCxc27vVee57OdWf8It8CqNa6zWmIFhfx7PWIJKDW6UttNeFP SR0aLs6JXUA7vWA9nCRK2R0GWaHK7Jt+UD4CtLFXDbj3lj9ZpHcgQzgbomiWONF2ySwc BxX6qpyhqDIhg5Ks56kIlMaIX77/IH8xAwOaEMBtpkltVPWvlreaGyagGNX/3R+XR77y DhCOij3wubI5Ai80m2VhgBv/HS/RUGw5JKna45VYuleIvU3tZzfdQWmHN2gEJIyt5Bek rKEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6gR7+oJ7XUI6MhB8zU2feJZoMeVNHRmve9e7TtBVXiM=; b=dcMLFaRbNqO1xf2Oc9DLZTITo4dUn6nHJ6TQKYbcinFOY3bADdWOIHK/vMPEMMjZF0 IWrAjYGfAVEDyzqj2M8fmdRuSl4Fx2iEedTjKCNEcfuTtb/xxRwyiFP0T0OQIdWpFwWE vv4WeB/DmZDPKVX+zXrcvbTM6d4uO1XtIa4a/d7G4UJEL7vq/B3M0jLkxZ0JumGNTiu2 THnCZEScaMPtu7mEjhg9/SsxEKTgzimF7jdy94I450h6Lzy2Sh3dTwL5Gb54izeeeceK pzkwzb7pQq41amMNXC8ue9OAziPN+MDCKISYdh5rxfrDZfoYUOwbxSOm9v5vXeUtctxc 1zQw== X-Gm-Message-State: AOAM531PXH940WVKaS8IsCBGfhoixcTKiprqvS32MxJ4OfLtgNMxapBU 5VxVtT553AHPhRkt+gW5DKk= X-Google-Smtp-Source: ABdhPJwNyKqnFsz6sUSx1d/aGhENQ2XeF1+TR5MNvyjlOl72Tstx0VP9NRESCGyA5ledv+bxfbqarg== X-Received: by 2002:a17:90a:4091:: with SMTP id l17mr3384594pjg.12.1625207148980; Thu, 01 Jul 2021 23:25:48 -0700 (PDT) Received: from gmail.com ([2601:600:8500:5f14:d627:c51e:516e:a105]) by smtp.gmail.com with ESMTPSA id b19sm1499251pjh.29.2021.07.01.23.25.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Jul 2021 23:25:48 -0700 (PDT) Date: Thu, 1 Jul 2021 23:22:15 -0700 From: Andrei Vagin To: Jann Horn Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-um@lists.infradead.org, criu@openvz.org, avagin@google.com, Andrew Morton , Andy Lutomirski , Anton Ivanov , Christian Brauner , Dmitry Safonov <0x7f454c46@gmail.com>, Ingo Molnar , Jeff Dike , Mike Rapoport , Michael Kerrisk , Oleg Nesterov , Peter Zijlstra , Richard Weinberger , Thomas Gleixner , linux-mm@kvack.org Subject: Re: [PATCH 2/4] arch/x86: implement the process_vm_exec syscall Message-ID: References: <20210414055217.543246-1-avagin@gmail.com> <20210414055217.543246-3-avagin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2DA82D00017F X-Stat-Signature: w4fs7q9ffncmxidyzo8o1c6w6uai7qaw Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=lut5GHGz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of avagin@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=avagin@gmail.com X-HE-Tag: 1625207150-102429 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 Mon, Jun 28, 2021 at 06:13:29PM +0200, Jann Horn wrote: > On Wed, Apr 14, 2021 at 7:59 AM Andrei Vagin wrote: > > This change introduces the new system call: > > process_vm_exec(pid_t pid, struct sigcontext *uctx, unsigned long flags, > > siginfo_t * uinfo, sigset_t *sigmask, size_t sizemask) > > > > process_vm_exec allows to execute the current process in an address > > space of another process. > [...] > > I still think that this whole API is fundamentally the wrong approach > because it tries to shoehorn multiple usecases with different > requirements into a single API. But that aside: Here, I can't agree with you, but this is discussed in the parallel thread. > > > +static void swap_mm(struct mm_struct *prev_mm, struct mm_struct *target_mm) > > +{ > > + struct task_struct *tsk = current; > > + struct mm_struct *active_mm; > > + > > + task_lock(tsk); > > + /* Hold off tlb flush IPIs while switching mm's */ > > + local_irq_disable(); > > + > > + sync_mm_rss(prev_mm); > > + > > + vmacache_flush(tsk); > > + > > + active_mm = tsk->active_mm; > > + if (active_mm != target_mm) { > > + mmgrab(target_mm); > > + tsk->active_mm = target_mm; > > + } > > + tsk->mm = target_mm; > > I'm pretty sure you're not currently allowed to overwrite the ->mm > pointer of a userspace thread. For example, zap_threads() assumes that > all threads running under a process have the same ->mm. (And if you're > fiddling with ->mm stuff, you should probably CC linux-mm@.) > > As far as I understand, only kthreads are allowed to do this (as > implemented in kthread_use_mm()). kthread_use_mm() was renamed from use_mm in the v5.8 kernel. Before that, it wasn't used for user processes in the kernel, but it was exported for modules, and we used it without any visible problems. We understood that there could be some issues like zap_threads and it was one of reasons why we decided to introduce this system call. I understand that there are no places in the kernel where we change mm of user threads back and forth, but are there any real concerns why we should not do that? I agree that zap_threads should be fixed, but it will the easy one. > > > + switch_mm_irqs_off(active_mm, target_mm, tsk); > > + local_irq_enable(); > > + task_unlock(tsk); > > +#ifdef finish_arch_post_lock_switch > > + finish_arch_post_lock_switch(); > > +#endif > > + > > + if (active_mm != target_mm) > > + mmdrop(active_mm); > > +}