From patchwork Wed Oct 19 08:21:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 4500 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp202294wrs; Wed, 19 Oct 2022 01:40:19 -0700 (PDT) X-Google-Smtp-Source: AMsMyM52lu80xXALCnvGvsETROXnO+YhgHDOXSXxKK7DOuNNCs35/pWfgyhMGDOnJbwWgO+eHV+d X-Received: by 2002:a17:907:7250:b0:791:9093:47f7 with SMTP id ds16-20020a170907725000b00791909347f7mr5769763ejc.278.1666168819291; Wed, 19 Oct 2022 01:40:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666168819; cv=none; d=google.com; s=arc-20160816; b=cB250zpCsrf1brC7FbQl5C9unMQXgQDwE6b2r58YvgxswoLht7CaGQrkMENP7bOCRV tf2wydglBbsOO4ZGHY9Kbn9wNqmwfRvyu3PZ1XYbrYGIfM2we2pA00Kr0gmScjeW7qPT +pT9mdLw0PPe/igzGj23viScWAYL8qJeDDewtJozMizHR6Aen6ImomLyxpu2D6M+K8x1 /WD9tHtfLpo43fD+WdEOcK6MQOr4afYBWJxix7K7dwxKIz6CFEXvHg66EA8Pyd/7YxKa 5GpGalffxc/rsC4T6GUqNSMEgnfTjGRVQkbg8V+3uqDFKjlwL61kGzRDHnDvKrI/bSXE L00A== 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=di7bIyz8mZqTg7DrvpQ5DLeKfcAqXXOvBq9ew3jNYt4=; b=sr53hy2ZdPlKTVyuD2Qg+BwZw+QaLhBlnxV8jNJRcUc7Zw0TaRTqPd+llKYFsh7GOa pYzRO5uenFuKxKO/dtLzcMEBOW3RykE8gqj9KbRjG22Zigj8/k9eQ/jIh1M7B6s9Cr2N Y6/SMFJCsVGguGrOHZtIr4STU7aWSC50iP5kboZQjrdLeLbJQ78eOs5D6XEDzGKNA/lR GuBk28o2V9gGtYru1jCkU/e6Kkmyumsovz3AtnYweqS5mK+m0C8yz3Utf3Ew/Ooxne8B 09Z2I9PehmO/gmH4dmlvBibD0az5ylU3jI+duazWlLOcnUmnThT6v8RIvUfqRfriAu6d B1LA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=At8c1W+o; 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 sz15-20020a1709078b0f00b007803449809esi10395349ejc.355.2022.10.19.01.39.54; Wed, 19 Oct 2022 01:40:19 -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=At8c1W+o; 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 S230362AbiJSIjW (ORCPT + 99 others); Wed, 19 Oct 2022 04:39:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230073AbiJSIiv (ORCPT ); Wed, 19 Oct 2022 04:38:51 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7829E7E800; Wed, 19 Oct 2022 01:38:23 -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 BAC5F617E8; Wed, 19 Oct 2022 08:37:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE86EC433D7; Wed, 19 Oct 2022 08:37:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666168679; bh=1aSnAgEIxoUXRJjkP+ugGfCVPi0FykL8XuZGEY3ono4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=At8c1W+oRhwnBJUueo9CScyrJSuIilfX+gTZTbmG/bjV0tog7++hdqIV1ucXXph7Y MloS5sr4lGhkwEfLy868s00ImwUl/YW6DDuFg4QspUOFib7KW/HevOjozKmQYV50HF H7ReVvfMU1Xpp2BypID5LFgjfD0AwhFYIK8N1F28= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Begunkov , Thadeu Lima de Souza Cascardo , Jens Axboe , David Bouman Subject: [PATCH 6.0 019/862] io_uring/af_unix: defer registered files gc to io_uring release Date: Wed, 19 Oct 2022 10:21:46 +0200 Message-Id: <20221019083250.847689386@linuxfoundation.org> X-Mailer: git-send-email 2.38.0 In-Reply-To: <20221019083249.951566199@linuxfoundation.org> References: <20221019083249.951566199@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.4 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?1747104636092929711?= X-GMAIL-MSGID: =?utf-8?q?1747104636092929711?= From: Pavel Begunkov commit 0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 upstream. 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 --- include/linux/skbuff.h | 2 ++ io_uring/rsrc.c | 1 + net/unix/garbage.c | 20 ++++++++++++++++++++ 3 files changed, 23 insertions(+) --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -796,6 +796,7 @@ typedef unsigned char *sk_buff_data_t; * @csum_level: indicates the number of consecutive checksums found in * the packet minus one that have been verified as * CHECKSUM_UNNECESSARY (max 3) + * @scm_io_uring: SKB holds io_uring registered files * @dst_pending_confirm: need to confirm neighbour * @decrypted: Decrypted SKB * @slow_gro: state present at GRO time, slower prepare step required @@ -975,6 +976,7 @@ struct sk_buff { #endif __u8 slow_gro:1; __u8 csum_not_inet:1; + __u8 scm_io_uring:1; #ifdef CONFIG_NET_SCHED __u16 tc_index; /* traffic control index */ --- a/io_uring/rsrc.c +++ b/io_uring/rsrc.c @@ -855,6 +855,7 @@ int __io_scm_file_account(struct io_ring UNIXCB(skb).fp = fpl; skb->sk = sk; + skb->scm_io_uring = 1; skb->destructor = unix_destruct_scm; refcount_add(skb->truesize, &sk->sk_wmem_alloc); } --- 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));