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=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,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 24311C4361B for ; Tue, 8 Dec 2020 15:36:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D901523A9B for ; Tue, 8 Dec 2020 15:36:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730138AbgLHPgm (ORCPT ); Tue, 8 Dec 2020 10:36:42 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:31000 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729878AbgLHPgm (ORCPT ); Tue, 8 Dec 2020 10:36:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607441715; 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=8Eo0sHqe9BY+2nbzE/RtTw8rBsTU9VMe8ppwwiLSYbs=; b=RJmpE0mGAf6+ZMt4HZY/4LExrumk6Kudftsq04/rOJMJhYvFPHUqLzPES8T3ejUmfv5Unn ajDKhD9sacMkVP+IMpnm2JECD5yBkjXMMmJjaWjP8M3He5MqVVriuWbo6H4fBrrg5MZTP1 mOV3enPSL11JANJWSjTFElmv6OBtIoY= 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-524-liKTAhfkPOOUjIXzoLjPJw-1; Tue, 08 Dec 2020 10:35:12 -0500 X-MC-Unique: liKTAhfkPOOUjIXzoLjPJw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 94CB8104ED3D; Tue, 8 Dec 2020 15:34:44 +0000 (UTC) Received: from llong.remote.csb (ovpn-119-227.rdu2.redhat.com [10.10.119.227]) by smtp.corp.redhat.com (Postfix) with ESMTP id 91B4F1042AA9; Tue, 8 Dec 2020 15:34:27 +0000 (UTC) Subject: Re: [PATCH 2/3] rwsem: Implement down_read_interruptible To: David Laight , Peter Zijlstra Cc: "Eric W. Biederman" , "linux-kernel@vger.kernel.org" , Linus Torvalds , Ingo Molnar , Will Deacon , Jann Horn , Vasiliy Kulikov , Al Viro , Bernd Edlinger , Oleg Nesterov , Christopher Yeoh , Cyrill Gorcunov , Sargun Dhillon , Christian Brauner , Arnd Bergmann , Arnaldo Carvalho de Melo References: <87tut2bqik.fsf@x220.int.ebiederm.org> <87k0tybqfy.fsf@x220.int.ebiederm.org> <620f0908-c70a-9e54-e1b5-71d086b20756@redhat.com> <20201207090243.GE3040@hirez.programming.kicks-ass.net> <7be81903-14e3-7485-83e7-02e65e80e8c3@redhat.com> <71db845efc7d44b5a7d23b0e55b3a496@AcuMS.aculab.com> From: Waiman Long Organization: Red Hat Message-ID: Date: Tue, 8 Dec 2020 10:34:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <71db845efc7d44b5a7d23b0e55b3a496@AcuMS.aculab.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/8/20 4:12 AM, David Laight wrote: > From: Waiman Long >> Sent: 07 December 2020 19:02 > ... >>> How much more difficult would it be to also add a timeout option? >>> I looked at adding one to the mutex code - and fell into a big pile >>> of replicated code. >>> >>> ISTM that one the initial locked exchange (and spin) fails a few >>> extra instructions when heading for the sleep don't really matter >>> >> Actually, I had tried that before. See >> >> https://lore.kernel.org/lkml/20190911150537.19527-1-longman@redhat.com/ >> >> That is for rwsem, but the same can be done for mutex. However, Peter >> didn't seem to like the idea of a timeout parameter. Anyway, it is >> certainly doable if there is a good use case for it. > 'Unfortunately' my use-case if for an out-of-tree driver. > > The problem I was solving is a status call blocking because > some other code is 'stuck' (probably an oops) with a mutex held. > > The code used to use down_timeout() (it was written for 2.4). > When I changed to mutex_(to get optimistic spinning) I lost > the ability to do the timeouts. The primary reason for sending out that patchset was to work around some circular locking problem in existing code even though these circular locking scenarios are not likely to happen. Your case is certainly another potential circular locking problem as well. Cheers, Longman