Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp477362ybk; Fri, 15 May 2020 05:49:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzP5IiO/xMsJWNumdj4VxkjnoBUqDrv/Cx+mt8XuT8wtkoj1cinI+v/ag9JECEvw7M1UGfx X-Received: by 2002:a17:906:9419:: with SMTP id q25mr2441337ejx.111.1589546964637; Fri, 15 May 2020 05:49:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589546964; cv=none; d=google.com; s=arc-20160816; b=o9BCvBpGd5m7ANGULwNRvhCdBMnPC8qo986675uklD+TIdM6jl4j+SVxCgNyN6jXgT GBU97c/g6cIlSmCa3ddcbBBSLdnhxi/sBDNm1FWEGw8xE/leuEmwHWMCYa66WfYy3wE1 c8JocjQGG3jyDJf9QEh86fN9ODl+/gYMLwRcsjmZaNBocmTRyo5Zd3bsjaVaDd6NlIpf rBaNHPHTbOXZO09Swo7eaxYtDDw1bVebSG5C9WGYyTJlr8nh1+9C5ay47ErnT6ToGLCM lzPPMK9gHs9wEweKG2rYnByIa62R1ZoNCR74N/0M+bdvDekWBb+SLKrr60cjbSl1ob/9 r7Tg== 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:mime-version :message-id:date:subject:cc:to:from; bh=YfhefhCLzeEYEMqWkkX1nt7kB5IkEFBqTA0KyhJa/sg=; b=aE1VM7I1z4Brl19dPMLsr80X6YjB+Ru2fV06UFRe1YEhlV7w+D/yR9P9bf5wsAY3bN J+yGwVXhyI+HMdKWjS35LvctinBpwsIzsEf91i1GsdAJtWdiNnudXpxjuRMLqUUca/nh Tc1kN4Pp5J91ilOIu3AQxlbEuu/Afvpuh0DWi/zLXcsmS0lcLqMx6CaAeHQrs9QeF2/l 4Gv6rcjYDTvzqxloa0BTHBjhNrsQGIED3VD90An/sV/7gzQW7MrjM9mckPPXSZSw1xfP MdkpE5m2cxCzVv4jJFHWyXYkToGtRQIM38/wu6jkgzvz/Q183OOuvipz1OAJ5ixlTNEJ yJ6A== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s16si1133192ejr.170.2020.05.15.05.49.01; Fri, 15 May 2020 05:49:24 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726245AbgEOMrR (ORCPT + 99 others); Fri, 15 May 2020 08:47:17 -0400 Received: from out30-45.freemail.mail.aliyun.com ([115.124.30.45]:37530 "EHLO out30-45.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726140AbgEOMrR (ORCPT ); Fri, 15 May 2020 08:47:17 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R561e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=laijs@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0Tyco77Q_1589546832; Received: from localhost(mailfrom:laijs@linux.alibaba.com fp:SMTPD_---0Tyco77Q_1589546832) by smtp.aliyun-inc.com(127.0.0.1); Fri, 15 May 2020 20:47:13 +0800 From: Lai Jiangshan To: linux-kernel@vger.kernel.org Cc: Lai Jiangshan , Peter Zijlstra , "Paul E . McKenney" , Oleg Nesterov , Michel Lespinasse , Andrea Arcangeli , David Woodhouse , Rik van Riel , Mathieu Desnoyers Subject: [PATCH 1/2] rbtree_latch: quit searching when reaching to maximum depth Date: Fri, 15 May 2020 12:47:06 +0000 Message-Id: <20200515124710.16439-1-laijs@linux.alibaba.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org lib/rbtree.c has ensured that there is not possible to inadvertently cause (temporary) loops in the tree structure as seen in program order of the modifier. But loop is still possible to be seen in searcher due to CPU's reordering. for example: modifier searcher left rotate at parent parent->rb_right is node search to parent parent->rb_right is node +->see node->rb_left changed WRITE_ONCE(parent->rb_right, tmp);-+ | node->rb_left is parennt no smp_wmb(), some arch can | | reorder these two writes | | loop long between WRITE_ONCE(node->rb_left, parent);-+-+ parent and node | +--->finally see parent->rb_right The long loop won't stop until the modifer's CPU flushes its writes. Too avoid it, we should limit the searching depth. There are no more than (1< Cc: Paul E. McKenney Cc: Oleg Nesterov Cc: Michel Lespinasse Cc: Andrea Arcangeli Cc: David Woodhouse Cc: Rik van Riel Cc: Mathieu Desnoyers Signed-off-by: Lai Jiangshan --- include/linux/rbtree_latch.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/rbtree_latch.h b/include/linux/rbtree_latch.h index 7d012faa509a..b012bd95eabf 100644 --- a/include/linux/rbtree_latch.h +++ b/include/linux/rbtree_latch.h @@ -107,10 +107,11 @@ __lt_find(void *key, struct latch_tree_root *ltr, int idx, int (*comp)(void *key, struct latch_tree_node *node)) { struct rb_node *node = rcu_dereference_raw(ltr->tree[idx].rb_node); + int depth = 2 * BITS_PER_LONG; struct latch_tree_node *ltn; int c; - while (node) { + while (node && depth > 0) { ltn = __lt_from_rb(node, idx); c = comp(key, ltn); @@ -120,6 +121,7 @@ __lt_find(void *key, struct latch_tree_root *ltr, int idx, node = rcu_dereference_raw(node->rb_right); else return ltn; + depth--; } return NULL; -- 2.20.1