Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp170345pxb; Wed, 11 Nov 2020 00:07:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJybaNOypOD3CP3FP7xJABNucH8nDYSzL6/bI3c7F31dkdLUf+/KE0gHDjoWlaTmOCuXWnnx X-Received: by 2002:aa7:c7cf:: with SMTP id o15mr24154965eds.15.1605082079670; Wed, 11 Nov 2020 00:07:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605082079; cv=none; d=google.com; s=arc-20160816; b=kiLtjaBJrDfIwRPnVRrGvUIgBV9IXFEf//1lQh608ao4sB4JT6QhxupmkAVddNDAlC XXMnssRquOK734+l85/MTRZtGSy2BOJbSyfZzUZcY0a+LULP5M3mJE1SjidY6Zdp+9EW hHcxoRI00jbvG9JVPKaFbXGtdWsf/JbdCDLUUsblPnsNl25zh6YkN55jM8DUZgM8RkSh s9uYo8QlauM4SE12mzBE5Q6U1r4GCC0vY9EweSoao8Jfq2dp02kt9mybAsINs5e8Us55 ySqxTnwn+a4IGxc/KxjH4JFCifdSElpaqgjFstyWdNR80OMxvsTY5VHwGPVcMDjdkDFF yxZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=T52zolihXR5yVqpLPyKqfWvMWU33QxIhE3DUTqobAyk=; b=udQaGXpg5hzOMLph3ruS8GXEZLmIPpNePcSJ74Ro3TnzBgk69w1zChXM9O3KyLAwAE Qlk5qrj1FHEjqX2eXyrxRhOFTiqutl+SmegVCskWFgWrJHu+6s2sKWnvNHTQSn0GFLf3 /grzboKj2BBTtDIjs3zFNZnxcz9SzpL+nGsA/DN8OWU4KK6mrQW7nveFT0kzaKEx2MCW KpTau8fVE2IIS6DJ+IpLs1G4DlwWSrxu6FQtfnwNYt5Ltay2R13Fu1zZ9YS005EBg9At uR1o0uOiVbqlFmUPE1+MHJGiTd7x9i5/Q/fDrYJHpT+InvyvdyJ9NsFluEXGmKnPcrur iHlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=KdW1JirN; 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 t1si808406ejy.446.2020.11.11.00.07.34; Wed, 11 Nov 2020 00:07:59 -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; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=KdW1JirN; 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 S1726237AbgKKIFi (ORCPT + 99 others); Wed, 11 Nov 2020 03:05:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbgKKIFh (ORCPT ); Wed, 11 Nov 2020 03:05:37 -0500 Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9DC0C0613D4 for ; Wed, 11 Nov 2020 00:05:36 -0800 (PST) Received: by mail-ua1-x941.google.com with SMTP id 91so454530uar.5 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=CKAHQOfkqft5Uhoewn2v0HYqhuSl/JjAxeb1uy/mx10RikXRmLtudN3dmL3ZiIRVdV 5AygRZ2+Q6TXeG545LuAhoshdwJtxkHBnCmsk7Lnn9gk/w8DzkjcGECp6behNEvzNo20 XZ408ggoxT0CI1XD7ug7lyI1B+chDPxE32KODRWWWjxuvqJ66B75kD9yqZKWDCiY79te v/ehc8BRF+3IInggOb78AuBv9XRqaRWC4zrt1rcrkOos18IcZwrsJCP9LRiSj6gBn9TF AZ1h9eZuG19UsZQSGWY7vFDz33JBkSUuJr8ZDzp67TTRSW6I5KCqVUZcLVZLtcj4c25l OwIA== X-Gm-Message-State: AOAM532eNgbT5v9aWPTRE04qMKOnw8+YBUG5uZornwoKurDhsLnmwpCk d2Nj0r/f0WJGBlIo9usX5ULDD7H02YqLYKUH952ZEw== 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-kernel@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