Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp5891450pxb; Tue, 16 Feb 2021 10:02:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJz5TKcfqWMhK0IM/Q/rLrsei6PSUF8uRMa01h7kfl5jQsYncIElQHr6eGnkXT4C5Ag8uRkr X-Received: by 2002:a50:b742:: with SMTP id g60mr21878769ede.113.1613498561760; Tue, 16 Feb 2021 10:02:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613498561; cv=none; d=google.com; s=arc-20160816; b=r1EhWvyr2wIxJ0yzCfQGb6yOGwqRMUM5pC2IA1xXvgXz5IUGZ0WxnHv0hO8zrGa/ri zRL8+FBD69MNlPShZRj+zZ80TybRCA/36ULltN3PqCkB4zPfTNd+BtTZsP/LHbtyksnm aQNW5PT8bihba4hE75Jum1To0V3rTH69It+3t5ZGnvkSrKclnwGqIlVEp1FjH6RLV92f cJ7A2I5QLIPP10qanQCfAVVLeopNVymXA9dBrAeQHLEIaqGQf4Z3YLRjQU+X91RBvRoD qKguxMI4GP23rP00d7Z0GlMQ+6nzFwj6Qv9sXEsIT2M8D4b7L/fWwDr5VR3O5M5qPZCR kiIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=qzDQaGVO7DWWDf5wuEx66tZvD7pSx2zdRIWMflPwd9k=; b=oAKtUfDHGGPXjNvyj/UvkgKN8jMHTle9chCzFrh1X0BCRLZvvm3LZ+ECpIOUNEfz5h y9pG75vHkqqUIu9e2cJFfbFkopvwzYgM+i/qy6OpV8hFvCyEBYscuoHuPaZwYkceEncP B+xApcLYPWhQ+cJ2whHCXrHCDBtAVj/zag2H7Yk3uvAeEJFks1bFhnM0EW9XgWaRJglm 7HAnyHfr3rjtsg7LgDB2xKbGgVKSQLDwh/BiMQxc/MVjK6HC3N3R45kixs69POSMy1mN 1RI/gynA3Sew+x+hmPVIBI+cPl/jS2Ha9vfcpJ7c5MN/uXD571jobD8JC++0LyZr84+d bmKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ho9si14598309ejc.324.2021.02.16.10.02.16; Tue, 16 Feb 2021 10:02:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230026AbhBPSBb (ORCPT + 99 others); Tue, 16 Feb 2021 13:01:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230291AbhBPSBY (ORCPT ); Tue, 16 Feb 2021 13:01:24 -0500 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A519CC061756; Tue, 16 Feb 2021 10:00:43 -0800 (PST) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lC4eI-00EgUW-F0; Tue, 16 Feb 2021 18:00:34 +0000 Date: Tue, 16 Feb 2021 18:00:34 +0000 From: Al Viro To: Denis Kirjanov Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, Jakub Kicinski , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] fs: export kern_path_locked Message-ID: References: <20210125154937.26479-1-kda@linux-powerpc.org> <20210127175742.GA1744861@infradead.org> <20210129082524.GA2282796@infradead.org> <20210129131855.GA2346744@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 16, 2021 at 05:31:33PM +0300, Denis Kirjanov wrote: > We had a change like that: > Author: WANG Cong > Date: Mon Jan 23 11:17:35 2017 -0800 > > af_unix: move unix_mknod() out of bindlock > > Dmitry reported a deadlock scenario: > > unix_bind() path: > u->bindlock ==> sb_writer > > do_splice() path: > sb_writer ==> pipe->mutex ==> u->bindlock > > In the unix_bind() code path, unix_mknod() does not have to > be done with u->bindlock held, since it is a pure fs operation, > so we can just move unix_mknod() out. *cringe* I remember now... Process set: P1: bind() of AF_UNIX socket to /mnt/sock P2: splice() from pipe to /mnt/foo P3: freeze /mnt P4: splice() from pipe to AF_UNIX socket P1 grabs ->bindlock P2 sb_start_write() for what's on /mnt P2 grabs rwsem shared P3 blocks in sb_wait_write() trying to grab the same rwsem exclusive P1 sb_start_write() blocks trying to grab the same rwsem shared P4 calls ->splice_write(), aka generic_splice_sendpage() P4 grabs pipe->mutex P4 calls ->sendpage(), aka sock_no_sendpage() P4 calls ->sendmsg(), aka unix_dgram_sendmsg() P4 calls unix_autobind() P4 blocks trying to grab ->bindlock P2 ->splice_write(), aka iter_file_splice_write() P2 blocks trying to grab pipe->mutex DEADLOCK Sigh... OK, so we want something like user_path_create() vfs_mknod() created = true grab bindlock .... drop bindlock if failed && created vfs_unlink() done_path_create() in unix_bind()... That would push ->bindlock all way down in the hierarchy, so that should be deadlock-free, but it looks like that'll be fucking ugly ;-/ Let me try and play with that a bit, maybe it can be massaged to something relatively sane...