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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 F1034C43331 for ; Fri, 3 Apr 2020 23:16:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BFED820737 for ; Fri, 3 Apr 2020 23:16:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="h3yp+8yp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728456AbgDCXQK (ORCPT ); Fri, 3 Apr 2020 19:16:10 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:24678 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727829AbgDCXQK (ORCPT ); Fri, 3 Apr 2020 19:16:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585955768; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3ow5jrQXb9as/47skj64mJ5864/J/UjNZWzuptpAdFI=; b=h3yp+8ypf7w3ojVRxrSykWYOq7ZXjxf8jMs6kQ2aeAFpOlIVI0RkYjQz+IM0P28ZeZr6C8 1jdNzeWr/njSoHb8zWmU/cYS68uKz9fk5A7eyzdUAXuAtiO60Cc+y13rlU+UkWqEjKXsrT TgT3hpoSxyNdiGoJDAIV+/sJRcpLD+U= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-NvbznsXuNlq4LNHMrMkIUg-1; Fri, 03 Apr 2020 19:16:06 -0400 X-MC-Unique: NvbznsXuNlq4LNHMrMkIUg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2D3DB1084431; Fri, 3 Apr 2020 23:16:05 +0000 (UTC) Received: from llong.remote.csb (ovpn-118-94.rdu2.redhat.com [10.10.118.94]) by smtp.corp.redhat.com (Postfix) with ESMTP id 49B369A257; Fri, 3 Apr 2020 23:16:04 +0000 (UTC) Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 To: Linus Torvalds Cc: "Eric W. Biederman" , Ingo Molnar , Will Deacon , Bernd Edlinger , Linux Kernel Mailing List , Alexey Gladkov References: <87blobnq02.fsf@x220.int.ebiederm.org> <87lfnda3w3.fsf@x220.int.ebiederm.org> <328f5ad3-f8b3-09b9-f2f7-b6dae0137542@redhat.com> From: Waiman Long Organization: Red Hat Message-ID: Date: Fri, 3 Apr 2020 19:16:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/3/20 4:59 PM, Linus Torvalds wrote: > On Fri, Apr 3, 2020 at 1:41 PM Waiman Long wrote: >> Another alternative is to add new functions like down_read_unfair() that >> perform unfair read locking for its callers. That will require less code >> change, but the calling functions have to make the right choice. > I'd prefer the static choice model - and I'd hide this in some > "task_cred_read_lock()" function anyway rather than have the users do > "mutex_lock_killable(&task->signal->cred_guard_mutex)" like they do > now. > > How nasty would it be to add the "upgrade" op? I took a quick look, > but that just made me go "Waiman would know" ;) > > Linus > With static choice, you mean defined at init time. Right? In that case, you don't really need a special encapsulation function. With upgrade, if there is only one reader, it is pretty straight forward. With more than one readers, it gets more complicated as we have to wait for other readers to unlock. We can spin for a certain period of time. After that, that reader can use the handoff mechanism by queuing itself in front the wait queue before releasing the read lock and go to sleep. That will make sure that it will get the lock once all the other readers exits. For an unfair rwsem, the writer cannot assert the handoff bit and so it shouldn't interfere with this upgrade process. If there are multiple upgrade readers, only one can win the race. The others have to release the read lock and queue themselves as writers. Will that be acceptable? Cheers, Longman Cheers, Longman