From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933136AbcE0Jkz (ORCPT ); Fri, 27 May 2016 05:40:55 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:32863 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932546AbcE0Jky (ORCPT ); Fri, 27 May 2016 05:40:54 -0400 To: "Paul E. McKenney" Cc: Mathieu Desnoyers , "Linux-Kernel@Vger. Kernel. Org" From: Nikolay Borisov Subject: Rcu synchronization of a list Message-ID: <57481623.9060003@gmail.com> Date: Fri, 27 May 2016 12:40:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, I'm currently dealing with a synchronization scheme which utilizes RCU but I'm observing a race condition. So I have an rcu-enabled list, which contains various entries. The add/delete paths of the list are protected by a single spin_lock. I'm observing the following thing happening: T1 T2 1. init_count 2. delete_group 3.incr_count So 'init_count' checks the list for a particular entry under rcu_read_lock and will either return the existing one if it finds it, or create a new entry and insert it in the list with the modification spin_lock held. incr_count essentially checks the list again and should return the entry which init_count returned (either the newly created one or the existing entry). However, what I'm observing is an assertion which fires in incr_count because it can't find the entry. The only place where the list is being deleted from is from delete_group. Having such a scheme what is the correct way to provide synchronization, it seems that op. 1 and 3 need to be atomic w.r.t to op2? Does this fall outside of the scope of the RCU protection scheme? Regards, Nikolay