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.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 E6A77C43603 for ; Tue, 10 Dec 2019 19:10:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A68D620637 for ; Tue, 10 Dec 2019 19:10:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="u5Y4Sp2r" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727666AbfLJTKX (ORCPT ); Tue, 10 Dec 2019 14:10:23 -0500 Received: from merlin.infradead.org ([205.233.59.134]:44976 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727647AbfLJTKX (ORCPT ); Tue, 10 Dec 2019 14:10:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a35QQIVRZAfUwW6/AE1+O5h1J9PVr+kiDXT0hU/xuAk=; b=u5Y4Sp2rJd5Pz1+Bj6lrdl5xF PQ06SchtmJ7RQjs3rGJMHTxj9dXHoD/8ZRpyGq4dGZgtyY5TueTqrttP69kNFYkpWKPINZpfYufrY YZ8f/h7dRzikcn1LFfFXkmn7zUWjbkAs0HhNRJmV2zDndEmqItPhGAEwAXoZm/6+wwTFHTEBHLKiG 97wqZtBKAhLKnXngCYvueNY6Nv6WFBa07xKvXoNyfstlzJCbD5Ejgmxdf7IQWayLj8jzgmBW7/6tN MdTBGGWBZwgViaJgaZFJc3+PSN45AWuZs7q3WmyCn9yrr9dtxWSNYjLBw0qerEDjx4Iu8LeIUg6iZ 9uc8hrtQg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1iektm-0002Sn-3z; Tue, 10 Dec 2019 19:10:18 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 2C1F3980D21; Tue, 10 Dec 2019 20:10:09 +0100 (CET) Date: Tue, 10 Dec 2019 20:10:09 +0100 From: Peter Zijlstra To: David Howells Cc: linux-afs@lists.infradead.org, Ingo Molnar , Will Deacon , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH] rxrpc: Mutexes are unusable from softirq context, so use rwsem instead Message-ID: <20191210191009.GA11457@worktop.programming.kicks-ass.net> References: <157599917879.6327.69195741890962065.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157599917879.6327.69195741890962065.stgit@warthog.procyon.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Dec 10, 2019 at 05:32:58PM +0000, David Howells wrote: > rxrpc_call::user_mutex is of type struct mutex, but it's required to start > off locked on an incoming call as it is being set up in softirq context to > prevent sendmsg and recvmsg interfering with it until it is ready. It is > then unlocked in rxrpc_input_packet() to make the call live. > > Unfortunately, commit a0855d24fc22d49cdc25664fb224caee16998683 > ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") causes > big warnings to be splashed in dmesg for each a new call that comes in from > the server. > > It *seems* like it should be okay, since the accept path trylocks the mutex > when no one else can see it and drops the mutex before it leaves softirq > context. > > Fix this by switching to using an rw_semaphore instead as that is permitted > to be used in softirq context. This really has the very same problem. It just avoids the WARN. We do PI boosting for rwsem write side identical to what we do for mutexes. I would rather we revert David's patch for now and more carefully consider what to do about this.