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=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 6FDECC2D0A3 for ; Tue, 3 Nov 2020 14:47:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36C7022447 for ; Tue, 3 Nov 2020 14:47:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728080AbgKCOrT (ORCPT ); Tue, 3 Nov 2020 09:47:19 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:46146 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728103AbgKCOpZ (ORCPT ); Tue, 3 Nov 2020 09:45:25 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kZxYp-002xC6-Om; Tue, 03 Nov 2020 07:45:23 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kZxYo-009i9o-Gg; Tue, 03 Nov 2020 07:45:23 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Jens Axboe Cc: Al Viro , Qian Cai , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20201030152407.43598-1-cai@redhat.com> <20201030184255.GP3576660@ZenIV.linux.org.uk> <20201030184918.GQ3576660@ZenIV.linux.org.uk> <20201030222213.GR3576660@ZenIV.linux.org.uk> <87eelba7ai.fsf@x220.int.ebiederm.org> <87k0v38qlw.fsf@x220.int.ebiederm.org> <3abc1742-733e-c682-5476-c6337a630e05@kernel.dk> Date: Tue, 03 Nov 2020 08:45:21 -0600 In-Reply-To: <3abc1742-733e-c682-5476-c6337a630e05@kernel.dk> (Jens Axboe's message of "Mon, 2 Nov 2020 14:39:32 -0700") Message-ID: <87mtzy7b3y.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1kZxYo-009i9o-Gg;;;mid=<87mtzy7b3y.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18vnl8MzKekN9Gx+3u0DKOS0AFAE+He3Vg= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH -next] fs: Fix memory leaks in do_renameat2() error paths X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jens Axboe writes: > On 11/2/20 1:31 PM, Jens Axboe wrote: >> On 11/2/20 1:12 PM, Eric W. Biederman wrote: >>> Jens Axboe writes: >>> >>>> On 11/2/20 12:27 PM, Eric W. Biederman wrote: >>>>> Jens Axboe writes: >>>>> >>>>>> On 10/30/20 4:22 PM, Al Viro wrote: >>>>>>> On Fri, Oct 30, 2020 at 02:33:11PM -0600, Jens Axboe wrote: >>>>>>>> On 10/30/20 12:49 PM, Al Viro wrote: >>>>>>>>> On Fri, Oct 30, 2020 at 12:46:26PM -0600, Jens Axboe wrote: >>>>>>>>> >>>>>>>>>> See other reply, it's being posted soon, just haven't gotten there yet >>>>>>>>>> and it wasn't ready. >>>>>>>>>> >>>>>>>>>> It's a prep patch so we can call do_renameat2 and pass in a filename >>>>>>>>>> instead. The intent is not to have any functional changes in that prep >>>>>>>>>> patch. But once we can pass in filenames instead of user pointers, it's >>>>>>>>>> usable from io_uring. >>>>>>>>> >>>>>>>>> You do realize that pathname resolution is *NOT* offloadable to helper >>>>>>>>> threads, I hope... >>>>>>>> >>>>>>>> How so? If we have all the necessary context assigned, what's preventing >>>>>>>> it from working? >>>>>>> >>>>>>> Semantics of /proc/self/..., for starters (and things like /proc/mounts, etc. >>>>>>> *do* pass through that, /dev/stdin included) >>>>>> >>>>>> Don't we just need ->thread_pid for that to work? >>>>> >>>>> No. You need ->signal. >>>>> >>>>> You need ->signal->pids[PIDTYPE_TGID]. It is only for /proc/thread-self >>>>> that ->thread_pid is needed. >>>>> >>>>> Even more so than ->thread_pid, it is a kernel invariant that ->signal >>>>> does not change. >>>> >>>> I don't care about the pid itself, my suggestion was to assign ->thread_pid >>>> over the lookup operation to ensure that /proc/self/ worked the way that >>>> you'd expect. >>> >>> I understand that. >>> >>> However /proc/self/ refers to the current process not to the current >>> thread. So ->thread_pid is not what you need to assign to make that >>> happen. What the code looks at is: ->signal->pids[PIDTYPE_TGID]. >>> >>> It will definitely break invariants to assign to ->signal. >>> >>> Currently only exchange_tids assigns ->thread_pid and it is nasty. It >>> results in code that potentially results in infinite loops in >>> kernel/signal.c >>> >>> To my knowledge nothing assigns ->signal->pids[PIDTYPE_TGID]. At best >>> it might work but I expect the it would completely confuse something in >>> the pid to task or pid to process mappings. Which is to say even if it >>> does work it would be an extremely fragile solution. >> >> Thanks Eric, that's useful. Sounds to me like we're better off, at least >> for now, to just expressly forbid async lookup of /proc/self/. Which >> isn't really the end of the world as far as I'm concerned. > > Alternatively, we just teach task_pid_ptr() where to look for an > alternate, if current->flags & PF_IO_WORKER is true. Then we don't have > to assign anything that's visible in task_struct, and in fact the async > worker can retain this stuff on the stack. As all requests are killed > before a task is allowed to exit, that should be safe. That seems assumes task_pid_ptr is always called on current. When you are looking at the task through the proc filesystem you want things like /proc//stat and /proc//status to be able to display the pids without problem. More than that it is desirable that readdir does not get the view for the PF_IO_WORKER. > diff --git a/kernel/pid.c b/kernel/pid.c > index 74ddbff1a6ba..5fd421a4864c 100644 > --- a/kernel/pid.c > +++ b/kernel/pid.c > @@ -42,6 +42,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -320,6 +321,12 @@ EXPORT_SYMBOL_GPL(find_vpid); > > static struct pid **task_pid_ptr(struct task_struct *task, enum pid_type type) > { > + if ((task->flags & PF_IO_WORKER) && task->io_uring) { > + return (type == PIDTYPE_PID) ? > + &task->io_uring->thread_pid : > + &task->io_uring->pids[type]; > + } > + > return (type == PIDTYPE_PID) ? > &task->thread_pid : > &task->signal->pids[type]; The only thing I can think of that might work convincingly is to split get_current() into two functions get_context() and get_task(). Maybe accessed as current_context and current_task. With get_context() returning just a pointer to the fields that are safe to use in io_uring, and get_task returning the other fields. With exit and exec invaliding the pending work on the contexts it should be safe to just return a pointer to the context that invoked io_uring. Data in the context would either need to be read-only or be modified and read in a multi-thread safe way. The rest of the data in the task_struct by default could be assume it is only modified by the task. That would give type-safety and something avoids playing whack-a-mole with every new piece of context that userspace accesses. Eric