From patchwork Thu Feb 28 13:49:42 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: 1049496 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 449DSs0rrXz9s5R; Fri, 1 Mar 2019 00:50:05 +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 1gzM4V-0006OS-4b; Thu, 28 Feb 2019 13:49:59 +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 1gzM4T-0006Nq-LL for kernel-team@lists.ubuntu.com; Thu, 28 Feb 2019 13:49:57 +0000 Received: from mail-qk1-f197.google.com ([209.85.222.197]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1gzM4T-0006Z7-7d for kernel-team@lists.ubuntu.com; Thu, 28 Feb 2019 13:49:57 +0000 Received: by mail-qk1-f197.google.com with SMTP id z123so1944053qka.20 for ; Thu, 28 Feb 2019 05:49:57 -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=EZ0tzOalxg8MXlG716IO1mL1hF1aqTHRFXKUDCQJXt8=; b=n70WU98V1Lh0ouJuJ6MtUrt2kj7corVSY+YfAfOoKommRckj4OrsxiekWqRAygjdxQ jAZbcaoVaHeM9lU7fj1bQyrcbvWTVCX7+8jnpM9Gop14t86IFFCN/jcuwhy11MPztZlK UAOd90bT6qk07ibWQV33gPIbO4RJhu4T+BPWznzTRJ5wG3jVSb2UKLebIuD9puXKqVgP 3V4Jb3VgoDZG16EHYco9D+ULGEzHjhEYbQZk7FKVJQmNog0uYjM6Pf1FrZ4iaZA1NKkC iUu+0ZPZeW+sUWqgQF5w6Apv99eeQeShtsQWBALnwLjybv4vLhlIZHmiqsl8ht4i1GjV IhZg== X-Gm-Message-State: APjAAAUHi/ofNtuk8Z8knT0Ih6g+t1xJYWnD/CYdqR9UxFTN/iHaqAJb jkhe+aywDFPcpQqL2vNopcdVNnMYfxkxmte+01x0ri/3KcIxYx+5SKFr61BDS3OS5bqqGln1FwZ ZdvhVj5Ve6WctVtRTX5tszgYKg4iDym3d/BgK6/sB X-Received: by 2002:a0c:98c8:: with SMTP id g8mr6517126qvd.161.1551361795300; Thu, 28 Feb 2019 05:49:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwOsR06qecyt4xsotmxX/bECw4vlqrmZ4S8dRKsHcXATQvt3FV7ziiucnHJTzDKBKwRNpiUkw== X-Received: by 2002:a0c:98c8:: with SMTP id g8mr6517105qvd.161.1551361795037; Thu, 28 Feb 2019 05:49:55 -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.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 05:49:53 -0800 (PST) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [cosmic][PATCH v2] srcu: Lock srcu_data structure in srcu_gp_start() Date: Thu, 28 Feb 2019 10:49:42 -0300 Message-Id: <20190228134942.5084-4-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 b4123d7a2cec..bd0fad13e6a9 100644 --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -445,10 +445,12 @@ static void srcu_gp_start(struct srcu_struct *sp) lockdep_assert_held(&ACCESS_PRIVATE(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));