Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1273226ybj; Thu, 7 May 2020 19:56:23 -0700 (PDT) X-Google-Smtp-Source: APiQypLFKU4c3iv+Ad8LSd1fX13Xl0cVG0fBc51Z9JWfjACQK/ytKucPJh6nZZNnK3ofwMkpHCQR X-Received: by 2002:aa7:d2cd:: with SMTP id k13mr430000edr.116.1588906583143; Thu, 07 May 2020 19:56:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588906583; cv=none; d=google.com; s=arc-20160816; b=KPcrRt1nSynFCIhY3dCPI8E2P/R7biBvQZ2pTYnfWzdpfJ3fPzND3Sy7qF8fTLuEDd kwvvYrogpq8ORd4MfPpZ1/LKP+nSZ1Ir08YDilVFxmMeuOMZuxCgb228BLPkqpxv2c6Y F3k0DtrLe/jwr8SZrEi7WjtW1GesGpBUsgkoDtB+4q0uuadyU8KRJGqzVVI/IZTaN/Qo 9mcMBAf4jP1Qqq30LNdCggjPEjQ3yftAHsxY3R1UlQOYVp302wvLhDDm/mq9K90Mh95u OA+nivDkelaVwoKSLnRwMHVS/tITXoMTiuUvqz0NAzlEG2/OVtbfOJdvGMvt2XTt9KDU I/SQ== 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:references:cc:to:from:subject:dkim-signature; bh=um3mI9LmYrUvelmN4ru3INCNryFm6dnCjlmdCTLr9ao=; b=qV9VbkA045NEREAh1OdI35lkmAl+HJqsW4PJpYe5EZD/uc+r1dJHBD87eNWAKMV5TY HGsxveBaGkHhXFYa9ZjkmO77N/es6zdZiMQPup3Et11mQdiTag1htqlPUU4i1gqMT2Ku gfV9/tECSiBjGF2k0Fg7M9EvjxpUrGdevTXDe2UiNbx2ZKnmMWxnAjy/W+MxfnKUudlV 5beEJkA3ZnLpYUgi3DALZO6G6Cx5LnLwopI9YpOkcDmQXfsJ8K4V2EUctz2ZHISHjmX6 f8b0yzoQgZZf4O1aUhs6/G01NnJ6tpyeX9fF9ksdK1scCfsTF04LgfIh/Wj6ZH536lKY 2GFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=TVVEgyyq; 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 x6si224590edj.56.2020.05.07.19.56.00; Thu, 07 May 2020 19:56:23 -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=TVVEgyyq; 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 S1726942AbgEHCx3 (ORCPT + 99 others); Thu, 7 May 2020 22:53:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726598AbgEHCx3 (ORCPT ); Thu, 7 May 2020 22:53:29 -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 10E5FC05BD43 for ; Thu, 7 May 2020 19:53:29 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id js4so1538000pjb.5 for ; Thu, 07 May 2020 19:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=um3mI9LmYrUvelmN4ru3INCNryFm6dnCjlmdCTLr9ao=; b=TVVEgyyqm/kK9/OemwN+zgXn3on4bbRKhx3Cy38nRns+DTL5BXOau4BfM1OMRb4hmi U64R4g5JdBSU6iz4WjA+sXyDG+orAwaPmDyNvDbOmzqvbcRjk0p1P23HP5GFKEzR9tWw fyLGOswEQM1RTh/RdnE8asYdThCIRO3gihQL2WI3TdpExiz5thCBkXoo1x1jV/8E61MC toEHulgivJUVJtpG50zDFpv+GKuZgFCtDpk0Tqrwwkz4XW595+BpJfWvJLQfvT9siHyJ Kkmv7lmFKVWV+hdW5fjTnB9bSxaGfCtewe1W40/1EZvvFD91KjXjiSFyW7z/k1cvVB/v BRpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=um3mI9LmYrUvelmN4ru3INCNryFm6dnCjlmdCTLr9ao=; b=AOiOo4YvKNl3pxM/OvAP9/zbWDHe3aEU4pTeJiX+i6nR+6uo1TXtx1lU+GHYmlTFeF PgM0bvTtvbnCsi5qNxGdnKBphtm/oWuV8JxsfrucM9wrJe44dNZMhlaXRYVp2bJn2qGh 2QCn3PP7Xtaso5cmZwyul7SzZaBOvxi9aopzVKwaXhWAauShN14XGhZt0VNCgKGYhQ4e G+A6Ys7PmdqOrA2gBz5tt4ru/Xr8pysxafV+3sMxBXRW+aRjBY3xrXLN9h9UQPSctWa5 MiFs0l7XiJgzae211kdSwzoGbnS5RH3FLi8Wi+/Z194pdWcc+01/pBRJlKU9VB2loKTZ p76g== X-Gm-Message-State: AGi0PuZPPNwFd9e2Q+Jct2156jl/QkPH/qAszKgvUo0E9Blq/xLP47tw sUi+D/zHbZQ12ylN5pCNCLiDZD/MdRA= X-Received: by 2002:a17:90a:2843:: with SMTP id p3mr3333214pjf.204.1588906408379; Thu, 07 May 2020 19:53:28 -0700 (PDT) Received: from [192.168.1.188] ([66.219.217.145]) by smtp.gmail.com with ESMTPSA id d12sm179788pfq.36.2020.05.07.19.53.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 19:53:27 -0700 (PDT) Subject: Re: [PATCH] fs/io_uring: fix O_PATH fds in openat, openat2, statx From: Jens Axboe 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> <629de3b6-cf80-fe37-1dde-7f0464da0a04@kernel.dk> Message-ID: <672e9220-2634-95f1-95a1-62c35bcf7341@kernel.dk> Date: Thu, 7 May 2020 20:53:24 -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: <629de3b6-cf80-fe37-1dde-7f0464da0a04@kernel.dk> 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 8:28 PM, Jens Axboe wrote: > 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. Ran various bits of testing and tracing with just the below, and I don't see anything wrong. Even verified the same cases with pending poll requests and an async read (punted to thread), and it works and doesn't complain with KASAN either. And I did think this would work after looking at it. The ctx referencing should handle this just fine. Hence it seems to me that my initial attempts at blocking the ring closing itself were not needed at all. diff --git a/fs/io_uring.c b/fs/io_uring.c index 979d9f977409..9099a9362ad4 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -786,7 +786,6 @@ static const struct io_op_def io_op_defs[] = { .needs_fs = 1, }, [IORING_OP_CLOSE] = { - .needs_file = 1, .file_table = 1, }, [IORING_OP_FILES_UPDATE] = { @@ -3399,10 +3398,6 @@ static int io_close_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe) return -EBADF; req->close.fd = READ_ONCE(sqe->fd); - if (req->file->f_op == &io_uring_fops || - req->close.fd == req->ctx->ring_fd) - return -EBADF; - return 0; } -- Jens Axboe