From patchwork Thu Feb 28 13:49:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 1049495 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 449DSn37Tlz9s47; Fri, 1 Mar 2019 00:50:01 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1gzM4R-0006Mo-US; Thu, 28 Feb 2019 13:49:55 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1gzM4Q-0006Lq-3V for kernel-team@lists.ubuntu.com; Thu, 28 Feb 2019 13:49:54 +0000 Received: from mail-qt1-f200.google.com ([209.85.160.200]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1gzM4P-0006Ys-Le for kernel-team@lists.ubuntu.com; Thu, 28 Feb 2019 13:49:53 +0000 Received: by mail-qt1-f200.google.com with SMTP id e1so18260718qth.23 for ; Thu, 28 Feb 2019 05:49:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=l2mu3mQ9o4eWmNeYDau9tn/CPPFbyr+bQ3LwUJ2z9z0=; b=neIYw4IQNevf9rqFLC46pHJRwDzw8kIONeGo1p4mp6DFstAgoZlZoqTQZTwyAQPiyp 6FYPhTmlTwdZjyDwrVveJclcdFlzCuw2TifGL9uQdeuL4h9oCxDOgc2yj6zWvcaxbXIL pxLmusNJt1CZTFZx90pprvK+cy/hySi7YTFeUrvzybt+i2AhnoizOCdx1fCDXgAYDiI6 dfiOrj4o7Bk3laq78OnSJ8NToBPMj0Yh+yxf6x3c5F2J1XXSlwtc62V7zT4u0bS2sjPP VB/mC1VGRDzff5vNK0CnRJfT1/79zJhuuOv2ev63pFd+k9ePVr6goV3sM4iGJF5ZqCfq DThA== X-Gm-Message-State: APjAAAWXZgJuBlTpWnzUT21VgogCfuzr4TrOnKQMGtmB/1jEfnTIxsB8 jqgrZr+vMM9aAAXMJ4j2UfZt5AggD/Y3/XZr2kH2RrsTq92WDsiKF/Ne2Bq6XN+qPovGjVLYAbJ +jJKdVMIXfeDMWh89Cnq/3WJesP4KoQbQ/n8Js6vh X-Received: by 2002:a05:620a:123b:: with SMTP id v27mr6105782qkj.29.1551361792127; Thu, 28 Feb 2019 05:49:52 -0800 (PST) X-Google-Smtp-Source: APXvYqyrUbxLxnksaa2XT703CK4ufB5EVg7d2SFmJK7z5WLW27hn+Cx0zelOplpTbPJhoV9pw9+5Og== X-Received: by 2002:a05:620a:123b:: with SMTP id v27mr6105759qkj.29.1551361791837; Thu, 28 Feb 2019 05:49:51 -0800 (PST) Received: from gallifrey.lan ([2804:14c:4e3:4a76:8437:8a5d:504f:a207]) by smtp.gmail.com with ESMTPSA id m43sm13337092qtk.64.2019.02.28.05.49.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 05:49:50 -0800 (PST) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [bionic][PATCH v2 2/2] srcu: Lock srcu_data structure in srcu_gp_start() Date: Thu, 28 Feb 2019 10:49:41 -0300 Message-Id: <20190228134942.5084-3-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190228134942.5084-1-marcelo.cerri@canonical.com> References: <20190228134942.5084-1-marcelo.cerri@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Dennis Krein BugLink: http://bugs.launchpad.net/bugs/1802021 The srcu_gp_start() function is called with the srcu_struct structure's ->lock held, but not with the srcu_data structure's ->lock. This is problematic because this function accesses and updates the srcu_data structure's ->srcu_cblist, which is protected by that lock. Failing to hold this lock can result in corruption of the SRCU callback lists, which in turn can result in arbitrarily bad results. This commit therefore makes srcu_gp_start() acquire the srcu_data structure's ->lock across the calls to rcu_segcblist_advance() and rcu_segcblist_accelerate(), thus preventing this corruption. Reported-by: Bart Van Assche Reported-by: Christoph Hellwig Reported-by: Sebastian Kuzminsky Signed-off-by: Dennis Krein Signed-off-by: Paul E. McKenney Tested-by: Dennis Krein Cc: # 4.16.x (cherry picked from commit eb4c2382272ae7ae5d81fdfa5b7a6c86146eaaa4) Signed-off-by: Marcelo Henrique Cerri --- kernel/rcu/srcutree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c index d5cea81378cc..b3e5e9873582 100644 --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -441,10 +441,12 @@ static void srcu_gp_start(struct srcu_struct *sp) lockdep_assert_held(&sp->lock); WARN_ON_ONCE(ULONG_CMP_GE(sp->srcu_gp_seq, sp->srcu_gp_seq_needed)); + spin_lock_rcu_node(sdp); /* Interrupts already disabled. */ rcu_segcblist_advance(&sdp->srcu_cblist, rcu_seq_current(&sp->srcu_gp_seq)); (void)rcu_segcblist_accelerate(&sdp->srcu_cblist, rcu_seq_snap(&sp->srcu_gp_seq)); + spin_unlock_rcu_node(sdp); /* Interrupts remain disabled. */ smp_mb(); /* Order prior store to ->srcu_gp_seq_needed vs. GP start. */ rcu_seq_start(&sp->srcu_gp_seq); state = rcu_seq_state(READ_ONCE(sp->srcu_gp_seq));