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.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 1C073CA9EAB for ; Fri, 18 Oct 2019 14:43:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E6100222BD for ; Fri, 18 Oct 2019 14:43:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="OaQk+2++" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408535AbfJROnz (ORCPT ); Fri, 18 Oct 2019 10:43:55 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:35170 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405365AbfJROny (ORCPT ); Fri, 18 Oct 2019 10:43:54 -0400 Received: by mail-pg1-f193.google.com with SMTP id p30so3520454pgl.2 for ; Fri, 18 Oct 2019 07:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qqD13exqVYnsM1ZZfhtle755qkmvhaW0YCe6dhzNVH0=; b=OaQk+2++QPs2Uoczz52BnqNlZLiAERk1PO0sfo9yTqspjGbTmOZF1F2t9PXHOoq3A7 L49GkCrMal0DOv0kLlse2/VWrCTVae77O88o1wkxfP7bwcV56UyE7HeZ2z2BzyUpRbJJ 0znfd8KPTGtTF3V6vm//Vig0GDVFuGsimDdWrxmYizTu3hovvU4sC3+HSR7HUGngBqYp ezqgzD0ozhWGImFiIRzu2AQixMKMMzdJ8w1UmXW03k3i4xejFlyI+/bHWxwU7cIAQYpJ R9vMXN4IFSwMpzDeesAJ63OsC+dthar0Nl+jAUNSzxaxQSsXMrOHiorQkljeqvZJF9lS O1ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qqD13exqVYnsM1ZZfhtle755qkmvhaW0YCe6dhzNVH0=; b=jnfwibKUyWBB9RO4RNOv7QSxjAbfzw+sHxUEgktQ0l9kQv4bynURSgEXZzxeS1uSeT /lhTWfVPa31l4f/g707Ls7hZKh1b8m1pGLbWCb8uHlmIbw54WmeF631t00lob3avnLa/ HGl7SrazimbHm7o/dDKb5W5nqMgN3sL17Z/uUa7xYKlKTvpGx8XqYslg3+XzTXDpH8Y+ Lj5QjZ4Covud5knNzvPNPF9mWSp2Y9EcUfIXDyV+AU0lRjijBWRQCXGIWN0LScc5nTtc nvIzG9QE/gR3M0NiZv+yP7/n9lkl83BVq5GEexH5pUO3pLZS2yfdf7lOxKaykx+Urg85 NbWQ== X-Gm-Message-State: APjAAAXM/8QfYfqW1ZFD1OJQJqRcDlwExEYCNK4ool3fC6DTf0jqzIEy 1F0Nb6FAAT4ckEBF3F7DSX+28zVA7uXtoQ== X-Google-Smtp-Source: APXvYqxhSEUXJ1smjci2IeCyTjfO9xr/dLfImtrg2DgXhTN0iwUMsEz1gpueJMlRel+jnMBX5HZ2/A== X-Received: by 2002:a17:90a:8a89:: with SMTP id x9mr11672031pjn.95.1571409831770; Fri, 18 Oct 2019 07:43:51 -0700 (PDT) Received: from ?IPv6:2620:10d:c081:1131::1120? ([2620:10d:c090:180::e16a]) by smtp.gmail.com with ESMTPSA id g20sm6308189pfo.73.2019.10.18.07.43.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Oct 2019 07:43:50 -0700 (PDT) Subject: Re: [PATCH 1/3] io_uring: add support for async work inheriting files table To: Jann Horn Cc: linux-block@vger.kernel.org, "David S. Miller" , Network Development References: <20191017212858.13230-1-axboe@kernel.dk> <20191017212858.13230-2-axboe@kernel.dk> <0fb9d9a0-6251-c4bd-71b0-6e34c6a1aab8@kernel.dk> From: Jens Axboe Message-ID: Date: Fri, 18 Oct 2019 08:43:48 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 10/18/19 8:40 AM, Jann Horn wrote: > On Fri, Oct 18, 2019 at 4:37 PM Jens Axboe wrote: >> >> On 10/18/19 8:34 AM, Jann Horn wrote: >>> On Fri, Oct 18, 2019 at 4:01 PM Jens Axboe wrote: >>>> On 10/17/19 8:41 PM, Jann Horn wrote: >>>>> On Fri, Oct 18, 2019 at 4:01 AM Jens Axboe wrote: >>>>>> This is in preparation for adding opcodes that need to modify files >>>>>> in a process file table, either adding new ones or closing old ones. >>> [...] >>>> Updated patch1: >>>> >>>> http://git.kernel.dk/cgit/linux-block/commit/?h=for-5.5/io_uring-test&id=df6caac708dae8ee9a74c9016e479b02ad78d436 >>> >>> I don't understand what you're doing with old_files in there. In the >>> "s->files && !old_files" branch, "current->files = s->files" happens >>> without holding task_lock(), but current->files and s->files are also >>> the same already at that point anyway. And what's the intent behind >>> assigning stuff to old_files inside the loop? Isn't that going to >>> cause the workqueue to keep a modified current->files beyond the >>> runtime of the work? >> >> I simply forgot to remove the old block, it should only have this one: >> >> if (s->files && s->files != cur_files) { >> task_lock(current); >> current->files = s->files; >> task_unlock(current); >> if (cur_files) >> put_files_struct(cur_files); >> cur_files = s->files; >> } > > Don't you still need a put_files_struct() in the case where "s->files > == cur_files"? I want to hold on to the files for as long as I can, to avoid unnecessary shuffling of it. But I take it your worry here is that we'll be calling something that manipulates ->files? Nothing should do that, unless s->files is set. We didn't hide the workqueue ->files[] before this change either. -- Jens Axboe