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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 7597AC388F9 for ; Wed, 11 Nov 2020 08:05:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0A148206B5 for ; Wed, 11 Nov 2020 08:05:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="KdW1JirN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726229AbgKKIFi (ORCPT ); Wed, 11 Nov 2020 03:05:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725929AbgKKIFg (ORCPT ); Wed, 11 Nov 2020 03:05:36 -0500 Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B278CC0613D1 for ; Wed, 11 Nov 2020 00:05:36 -0800 (PST) Received: by mail-ua1-x942.google.com with SMTP id a10so445511uan.12 for ; Wed, 11 Nov 2020 00:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T52zolihXR5yVqpLPyKqfWvMWU33QxIhE3DUTqobAyk=; b=KdW1JirNzZixAW0y6k03W4n0oUx1mwgYHoRio7qxTLAW1sQch9eFg3FdNoi1F44WGb 4AkF+mvvdOPJ70KxK4PyyiX26OuZGXP9KqvLg7dG2TAWats96jew/pbpzo7MCLUbTZPq 1xzv974+79AmgYpqdDxT/LcxLdiwKZL43xtFw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T52zolihXR5yVqpLPyKqfWvMWU33QxIhE3DUTqobAyk=; b=Xg234m7UPejbSBOVRkfJvGJp+/GolSIFRiPqH2yrL0uJqE09GmA5pCOkZgiOCqhHhg aVigN+Uo1V9olB29EfsaOCmSmwptcKD70ZAipjDB+dlk8eTeHQ2yU74hDtP/Oeso/PqF AlROgD4JwPCzHnPvvZZj464bFS1V5winkh6qZROokEyCRdxlQ2XfKecUK33IzELw9GUo mTXixjl4ynDuEYPd/wiuULodWGyRf8O0/524kZaDuHd/c+cFTrmxCRndElx68wKv/gaw bnohOJ2FUtHPYBH44nEUcaRQJQTYzZdby0CGqIxDuqHS7Bb0suDqVNHSP37AietOqgBX vYCA== X-Gm-Message-State: AOAM532WFWSKHz+PHvOQfVT9gGOA8cUw87itG7BXaJyIlTpbwreIf5AT lT1SgdIm3sbKd8hBSq/gNSUeWCSyDJpWR35uwow/gw== X-Google-Smtp-Source: ABdhPJyVOGS5SgFT01Xc25kGbuYM8gjuJNx097W3WndVTFEeW06YEX0O0gClxTuu7GxCB3YblpehRMUpXUIJCHBBoc0= X-Received: by 2002:ab0:6f54:: with SMTP id r20mr9470960uat.9.1605081935843; Wed, 11 Nov 2020 00:05:35 -0800 (PST) MIME-Version: 1.0 References: <1e796f9e008fb78fb96358ff74f39bd4865a7c88.1604926010.git.gladkov.alexey@gmail.com> <87v9ee2wer.fsf@x220.int.ebiederm.org> <87d00ks5jg.fsf@x220.int.ebiederm.org> In-Reply-To: <87d00ks5jg.fsf@x220.int.ebiederm.org> From: Miklos Szeredi Date: Wed, 11 Nov 2020 09:05:24 +0100 Message-ID: Subject: Re: [RESEND PATCH v3] fuse: Abort waiting for a response if the daemon receives a fatal signal To: "Eric W. Biederman" Cc: Alexey Gladkov , LKML , linux-fsdevel@vger.kernel.org, Alexey Gladkov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Nov 11, 2020 at 8:42 AM Eric W. Biederman wrote: > > Miklos Szeredi writes: > > Okay, so the problem with making the wait_event() at the end of > > request_wait_answer() killable is that it would allow compromising the > > server's integrity by unlocking the VFS level lock (which protects the > > fs) while the server hasn't yet finished the request. > > > > The way this would be solvable is to add a fuse level lock for each > > VFS level lock. That lock would be taken before the request is sent > > to userspace and would be released when the answer is received. > > Normally there would be zero contention on these shadow locks, but if > > a request is forcibly killed, then the VFS lock is released and the > > shadow lock now protects the filesystem. > > > > This wouldn't solve the case where a fuse fs is deadlocked on a VFS > > lock (e.g. task B), but would allow tasks blocked directly on a fuse > > filesystem to be killed (e.g. task A or C, both of which would unwind > > the deadlock). > > Are we just talking the inode lock here? > > I am trying to figure out if this is a straight forward change. > Or if it will take a fair amount of work. Inode lock and cross directory rename lock should suffice, I think. One issue is that we are losing normal ref on dentry+mount, so in case the process is killed we need to take a ref on the inode. Since multiple inode locks can be held for one op, we need to take care of ordering the shadow locks as well. It's not a trivial change, but I'd be much happier if we would take this instead of the hackish one. Thanks, Miklos