From patchwork Mon Oct 24 11:32:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 8982 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp438784wru; Mon, 24 Oct 2022 06:01:48 -0700 (PDT) X-Google-Smtp-Source: AMsMyM56q0xxqGw1eWJ2B4jy9pGeGfLntcNPHw3ZNYOrd4fc0eYavD0zTIi4B+Yas08pHWv3enEU X-Received: by 2002:a17:902:e9ca:b0:186:8624:9675 with SMTP id 10-20020a170902e9ca00b0018686249675mr14656146plk.76.1666616507748; Mon, 24 Oct 2022 06:01:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666616507; cv=none; d=google.com; s=arc-20160816; b=RwmRQCQ8KXkyoXQJQg6d6ijpa48GYNC/4nz6FrVEYIab+e7CH6z20VmpGjUyK20jT7 kbymwE3GwNZtHJ3rHbG+TGVPQe3gOC0A2mQdNBG4II8T+fGxEdJDRVG2wPLKanoo8Lkw nQctdKc45k43zi311uEnNYJJ6H7ONHIKvjUea2k2KdKRNCEFBJE9ptXyZgPJvnLqOgjr X5egCe/yOW08HyfO7WgU5Aoo33WoLhHVi3lqVYZkKRClrX1BOHkqP6ZpriSfE0kcuF3F rhaGEp8NyhwoB1l7OjAZHJgdILBEqRrDkmkvYwV9f5GeQzNBeKR7gt6Pq9BegamSPc6i c9Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=8QkECf9anx+2gCuF1IU2cRy0SMmszFbrz5rMd1opX7E=; b=dynb6nGiz7YLe54sWSjJSP9TBKZ6hbZ3Nosv5PTHSJCD93nreDvYfEU8HLSkIMUsCx o3OO6srSNl+Z0EHn4QkSGlyidFsy2OK/Wu8A+zQzv83u1GGuEAOOPLsqX/fLSqkFHfnl wv+QiSYursba3soyIIOqVKNTiM880M8KK71+dfFrLkJ4GCUobdxy3Fzf74/qRvETLvLS HDqX4HSlleX4/IPle+wTvui/kxtyXq9sc6bwy5naXm+4f+GRY/7OScis6wrFgEgtTSyp Lwkr1bf3g6r6UtaaZXEyaX+TkyvZ6431Y8mylbtVR1CL35185sb8ykegp/8M4szO0v+M 89xw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HFmcdPaS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q12-20020a65624c000000b0043a107f33ccsi33410667pgv.205.2022.10.24.06.01.24; Mon, 24 Oct 2022 06:01:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HFmcdPaS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234999AbiJXNBA (ORCPT + 99 others); Mon, 24 Oct 2022 09:01:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234927AbiJXM6z (ORCPT ); Mon, 24 Oct 2022 08:58:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36B3B98CBA; Mon, 24 Oct 2022 05:17:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E4ED6612CA; Mon, 24 Oct 2022 12:15:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3431C433C1; Mon, 24 Oct 2022 12:15:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666613729; bh=vphyuMNTpGBaNmQQwhU17mOecsvvOTZxhLXb6ShGydk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HFmcdPaSrHIVU9EKgl/T1HkZG0Du0D7tn9U4deUkrW/OcXlCjpnnhsg0gqcCO7X7T aMtNExlG/xybaCV/P9lDuqCFTUEOei448kuESxszmaAZBecpeNvsxjJum7OXPLZ3Dy Zo93JvpvhOEFp+5hHfPWHwVbbMYSWfL8TIoQS7vM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Pavel Begunkov , Thadeu Lima de Souza Cascardo , Jens Axboe , David Bouman Subject: [PATCH 5.4 247/255] io_uring/af_unix: defer registered files gc to io_uring release Date: Mon, 24 Oct 2022 13:32:37 +0200 Message-Id: <20221024113011.493035765@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113002.471093005@linuxfoundation.org> References: <20221024113002.471093005@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747574070944261348?= X-GMAIL-MSGID: =?utf-8?q?1747574070944261348?= From: Pavel Begunkov [ upstream commit 0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 ] Instead of putting io_uring's registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free(). Cc: stable@vger.kernel.org Fixes: 6b06314c47e1 ("io_uring: add file set registration") Reported-and-tested-by: David Bouman Signed-off-by: Pavel Begunkov Signed-off-by: Thadeu Lima de Souza Cascardo [axboe: add kerneldoc comment to skb, fold in skb leak fix] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- fs/io_uring.c | 1 + include/linux/skbuff.h | 2 ++ net/unix/garbage.c | 20 ++++++++++++++++++++ 3 files changed, 23 insertions(+) --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -3172,6 +3172,7 @@ static int __io_sqe_files_scm(struct io_ } skb->sk = sk; + skb->scm_io_uring = 1; skb->destructor = io_destruct_skb; fpl->user = get_uid(ctx->user); --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -659,6 +659,7 @@ typedef unsigned char *sk_buff_data_t; * @wifi_acked: whether frame was acked on wifi or not * @no_fcs: Request NIC to treat last 4 bytes as Ethernet FCS * @csum_not_inet: use CRC32c to resolve CHECKSUM_PARTIAL + * @scm_io_uring: SKB holds io_uring registered files * @dst_pending_confirm: need to confirm neighbour * @decrypted: Decrypted SKB * @napi_id: id of the NAPI struct this skb came from @@ -824,6 +825,7 @@ struct sk_buff { #ifdef CONFIG_TLS_DEVICE __u8 decrypted:1; #endif + __u8 scm_io_uring:1; #ifdef CONFIG_NET_SCHED __u16 tc_index; /* traffic control index */ --- a/net/unix/garbage.c +++ b/net/unix/garbage.c @@ -204,6 +204,7 @@ void wait_for_unix_gc(void) /* The external entry point: unix_gc() */ void unix_gc(void) { + struct sk_buff *next_skb, *skb; struct unix_sock *u; struct unix_sock *next; struct sk_buff_head hitlist; @@ -297,11 +298,30 @@ void unix_gc(void) spin_unlock(&unix_gc_lock); + /* We need io_uring to clean its registered files, ignore all io_uring + * originated skbs. It's fine as io_uring doesn't keep references to + * other io_uring instances and so killing all other files in the cycle + * will put all io_uring references forcing it to go through normal + * release.path eventually putting registered files. + */ + skb_queue_walk_safe(&hitlist, skb, next_skb) { + if (skb->scm_io_uring) { + __skb_unlink(skb, &hitlist); + skb_queue_tail(&skb->sk->sk_receive_queue, skb); + } + } + /* Here we are. Hitlist is filled. Die. */ __skb_queue_purge(&hitlist); spin_lock(&unix_gc_lock); + /* There could be io_uring registered files, just push them back to + * the inflight list + */ + list_for_each_entry_safe(u, next, &gc_candidates, link) + list_move_tail(&u->link, &gc_inflight_list); + /* All candidates should have been detached by now. */ BUG_ON(!list_empty(&gc_candidates));