Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1261223ybj; Thu, 7 May 2020 19:31:51 -0700 (PDT) X-Google-Smtp-Source: APiQypIAiSmCnQAjf76+f0RLBre0YI4/2O5GtjLXfqCTEuxLZ3ih7g5sOuapkWrSpMnfkMSoKttR X-Received: by 2002:a05:6402:b4e:: with SMTP id bx14mr345209edb.1.1588905111322; Thu, 07 May 2020 19:31:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588905111; cv=none; d=google.com; s=arc-20160816; b=E7B3fV+KVIBQbdnCkGlHsYoQUhYtnO36VCDCpLv/VwqPFtOw6zKveVjJrRfYfFY17d zCScpGUYSM+7YdgrBx6X/9T1MqTgs0GgZUPj7Vag1a/3aWvvfb39RlmMg5e9xOjuhbTp Z7ZGChx7fy2R/+SZpJd1qrFM7xSmT+Cyx0NQOiVyx2KpDX7UFfMiACMXDRQ7z6piKbBN iQGQwPMXfL9uyTIgPw4R1i4A4f/qqKW7Jzz0uFRcGsstn+FkgQXKrqnFxcs5C9wi5mNq ybMRimPHhoV+o36fmKYYJp6Gh5lPUo3ENIUrHpos0h2dc77JbWRmQWuVxqraDL78I6RO erdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=4doDNbNltxqhzk3lbUMRdt2VtGJH3KG9nbYr5hl5TwM=; b=U3f7IFEih3vCC3pczlkrbkra2cqR40TxGWpC6bTqyQ9GKVwxBpbUpGjBAqBc1tP6Ak DonY2ogWd+n7IkM+7jqzwlhBOT6Q4yzvT9E6lykR+jKi/qoA8Mu9CvMD6y4ekgY/wxq7 PvmYPoNTilQI3OhkbJd8a+KQiCjgFlu8uRUXSkcTwKg0L1s6UGAgZXDtijwwnXl9HsTN By9h8nbUBBerMD1PhyLa8Tpxi0rgaxlrd0GYLrBNpAgAX8EFyTH8ZROWXHQ1iuFP4Kow euegA04ScDk9hMM3Nt3Kn8a8gIj6RtR1Pi6Rolf0+zaQCBTmyNt+a3ajjxJdWpkBkJKu g3gQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=c2Crkcf6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y21si129884eju.232.2020.05.07.19.31.29; Thu, 07 May 2020 19:31:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=c2Crkcf6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726767AbgEHC2N (ORCPT + 99 others); Thu, 7 May 2020 22:28:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726538AbgEHC2N (ORCPT ); Thu, 7 May 2020 22:28:13 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25E41C05BD09 for ; Thu, 7 May 2020 19:28:13 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id mq3so3560472pjb.1 for ; Thu, 07 May 2020 19:28:13 -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=4doDNbNltxqhzk3lbUMRdt2VtGJH3KG9nbYr5hl5TwM=; b=c2Crkcf6BJm8XAZyqLRzdnU4JOCE829O8iRcxXkD/9CKtW3LEaEaLGuyCPLtor9Bix RfWLwfBv2sS2BEwdqVB94vlzTC5GAWuVsSGG+i8QX/Yc9NiLfcptAiOXcwVE7xujlLmH uemX7rPR2YK3DWe68N81Tp+2/rib9T7x2UlJViuqZkFl72wlZ1W9wPKXgncSd6SSEjm8 c+YyGJFgnFWsD5x0jsWj+4o2LTxk8YPpFQzZmHdrPf6NZvk10Ohsu66BtCILWc+iFtfa BQHDhY8N3vKd7ZhB5tvVl1NbotQubgeHLVBOKgir96oMvryb0eZDAOFAEOkT1QRET2ly lZvA== 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=4doDNbNltxqhzk3lbUMRdt2VtGJH3KG9nbYr5hl5TwM=; b=YU2KJUlX8fChbDsfiD96ZLXB6uTnE+cLdQzeqcKfwXKAcfqcB8cGnoWgMFdh7hqHAA Rjy8Uusg7boXYmcZeaXZylVl5Veg7BMDBbynDETdyq4kzD+XVXQiu0tgofuFifJ4ToLx JYm1SO7d4Y4dNVWhP5sHeoOtc+GXiIMhq+CZbIkfO2ZXuE3WTKc0n/i7RSm0VdBSavPf MWwCPToI8ezeM1iH9CfKFVsj7ObL0bVsSiXzcX7mMoDmUHMeQp8WRJicrEICmyw6MFgb ItTiQE20gQMdiDNWzerpilFvRcme7H7h30RBBoylpJCtOhpmqAqz6bD8uQDZgcBtr1oN 8+xQ== X-Gm-Message-State: AGi0PuYFxxLuTepBqXizWhbnkgoAheNo0HI83paxMQbCLRo1Ty0sLl+u Z0RoNAR1AffpmR5E1SVh57L1aZZEudM= X-Received: by 2002:a17:902:c194:: with SMTP id d20mr197709pld.256.1588904892424; Thu, 07 May 2020 19:28:12 -0700 (PDT) Received: from [192.168.1.188] ([66.219.217.145]) by smtp.gmail.com with ESMTPSA id cp22sm1040611pjb.28.2020.05.07.19.28.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 19:28:11 -0700 (PDT) Subject: Re: [PATCH] fs/io_uring: fix O_PATH fds in openat, openat2, statx To: Al Viro Cc: Max Kellermann , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20200507185725.15840-1-mk@cm4all.com> <20200507190131.GF23230@ZenIV.linux.org.uk> <4cac0e53-656c-50f0-3766-ae3cc6c0310a@kernel.dk> <20200507192903.GG23230@ZenIV.linux.org.uk> <8e3c88cc-027b-4f90-b4f8-a20d11d35c4b@kernel.dk> <20200507220637.GH23230@ZenIV.linux.org.uk> <283c8edb-fea2-5192-f1d6-3cc57815b1e2@kernel.dk> <20200507224447.GI23230@ZenIV.linux.org.uk> <20200507233132.GJ23230@ZenIV.linux.org.uk> From: Jens Axboe Message-ID: <629de3b6-cf80-fe37-1dde-7f0464da0a04@kernel.dk> Date: Thu, 7 May 2020 20:28:10 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200507233132.GJ23230@ZenIV.linux.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/7/20 5:31 PM, Al Viro wrote: > On Thu, May 07, 2020 at 05:03:17PM -0600, Jens Axboe wrote: >> On 5/7/20 4:44 PM, Al Viro wrote: >>> On Thu, May 07, 2020 at 04:25:24PM -0600, Jens Axboe wrote: >>> >>>> static int io_close(struct io_kiocb *req, bool force_nonblock) >>>> { >>>> + struct files_struct *files = current->files; >>>> int ret; >>>> >>>> req->close.put_file = NULL; >>>> - ret = __close_fd_get_file(req->close.fd, &req->close.put_file); >>>> + spin_lock(&files->file_lock); >>>> + if (req->file->f_op == &io_uring_fops || >>>> + req->close.fd == req->ctx->ring_fd) { >>>> + spin_unlock(&files->file_lock); >>>> + return -EBADF; >>>> + } >>>> + >>>> + ret = __close_fd_get_file_locked(files, req->close.fd, >>>> + &req->close.put_file); >>> >>> Pointless. By that point req->file might have nothing in common with >>> anything in any descriptor table. >> >> How about the below then? Stop using req->file, defer the lookup until >> we're in the handler instead. Not sure the 'fd' check makes sense >> at this point, but at least we should be consistent in terms of >> once we lookup the file and check the f_op. > > Actually, what _is_ the reason for that check? Note, BTW, that if the > file in question happens to be an AF_UNIX socket, closing it will > close all references held in SCM_RIGHTS datagrams sitting in its queue, > which might very well include io_uring files. > > IOW, if tries to avoid something really unpleasant, it's not enough. > And if it doesn't, then what is it for? Maybe there is no issue at all, the point was obviously to not have io_uring close itself. But we might just need an ordering of the fput vs put_request to make that just fine. Let me experiment a bit and see what's going on. -- Jens Axboe