From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53B56C4CEC7 for ; Sun, 15 Sep 2019 18:25:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2AFBF214AF for ; Sun, 15 Sep 2019 18:25:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726289AbfIOSZ0 (ORCPT ); Sun, 15 Sep 2019 14:25:26 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:55844 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725270AbfIOSZZ (ORCPT ); Sun, 15 Sep 2019 14:25:25 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1i9ZD8-0006iw-SU; Sun, 15 Sep 2019 12:25:23 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1i9ZD7-0001f2-TM; Sun, 15 Sep 2019 12:25:22 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: "Paul E. McKenney" Cc: Peter Zijlstra , Oleg Nesterov , Russell King - ARM Linux admin , Chris Metcalf , Christoph Lameter , Kirill Tkhai , Mike Galbraith , Thomas Gleixner , Ingo Molnar , Linux List Kernel Mailing , Davidlohr Bueso , Linus Torvalds References: <20190830160957.GC2634@redhat.com> <87o906wimo.fsf@x220.int.ebiederm.org> <20190902134003.GA14770@redhat.com> <87tv9uiq9r.fsf@x220.int.ebiederm.org> <87k1aqt23r.fsf_-_@x220.int.ebiederm.org> <87muf7f4bf.fsf_-_@x220.int.ebiederm.org> <87ftkzdpjd.fsf_-_@x220.int.ebiederm.org> <20190915144129.GL30224@paulmck-ThinkPad-P72> <87ef0hcufl.fsf@x220.int.ebiederm.org> Date: Sun, 15 Sep 2019 13:25:02 -0500 In-Reply-To: <87ef0hcufl.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Sun, 15 Sep 2019 12:59:10 -0500") Message-ID: <87v9tta03l.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1i9ZD7-0001f2-TM;;;mid=<87v9tta03l.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+M9W4LG1A1wAmEIw0ziB7E2T1GT98bHZ8= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v2 4/4] task: RCUify the assignment of rq->curr X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ebiederm@xmission.com (Eric W. Biederman) writes: > "Paul E. McKenney" writes: > >> So this looks good in and of itself, but I still do not see what prevents >> the unfortunate sequence of events called out in my previous email. >> On the other hand, if ->rcu and ->rcu_users were not allocated on top >> of each other by a union, I would be happy to provide a Reviewed-by. >> >> And I am fundamentally distrusting of a refcount_dec_and_test() that >> is immediately followed by code that clobbers the now-zero value. >> Yes, this does have valid use cases, but it has a lot more invalid >> use cases. The valid use cases have excluded all increments somehow >> else, so that the refcount_dec_and_test() call's only job is to >> synchronize between concurrent calls to put_task_struct_rcu_user(). >> But I am not seeing the "excluded all increments somehow". >> >> So, what am I missing here? > > Probably only that the users of the task_struct in this sense are now > quite mature. > > The two data structures that allow rcu access to the task_struct are > the pid hash and the runqueue. The practical problem is that they > have two very different lifetimes. So we need some kind of logic that > let's us know when they are both done. A recount does that job very > well. > > Placing the recount on the same storage as the unused (at that point) > rcu_head removes the need to be clever in other ways to avoid bloating > the task_struct. > > If you really want a reference to the task_struct from rcu context you > can just use get_task_struct. Because until the grace period completes > it is guaranteed that the task_struct has a positive count. > > Right now I can't imagine a use case for wanting to increase rcu_users > anywhere or to decrease rcu_users except where we do. If there is such > a case most likely it will increase the reference count at > initialization time. > > If anyone validly wants to increment rcu_users from an rcu critical > section we can move it out of the union at that time. Paul were you worrying about incrementing rcu_users because Frederic Weisbecker brought the concept up earlier in the review? It was his confusion that the point of rcu_users was so that it could be incremented from an rcu critical section. That definitely is not the point of rcu_users. If you were wondering about someone messing with rcu_users from an rcu critical region independently that does suggest the code could use a "comment saying don't do that!" Multiple people getting confused about the purpose of a reference count independently does suggest there is a human factor problem in there somewhere. Eric