From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F51F3624A1 for ; Thu, 15 Jan 2026 12:23:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768479830; cv=none; b=LNSgFEYK3ftwPp0zjm3S3Bwdx0mihWC1FsFlXgOE2kddbl/TY4wQdKQRqcYAGfymkcO8gIPzXUz6+bBx9xA/ek52XRFduDSJLJCgaVhK4z5Uo43UGKq66zsTG7TdclxY/lBHYtFLYLlLy8B3Ii66pido4uayj+QPEOwCmW08RJc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768479830; c=relaxed/simple; bh=YFlZi3jstUpTBbnPJHTzHfT6rNDin50tP0aHOiJ210Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NiFBoN81FvdaU+n6qnr+GC/CpWIFpwW2ZphSpfVMDYASuOMEzg9ij5bnhXL01tGV5U3wxTS6SW/xbEVDbqyAGY17ueY8i3IMKNbcqcBkV/VEs0mo5eJopdCWhK1ewttvWbKzykyqShLsp3A8+n/bq3C9P8r6XADP8VxwhMiNO7s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GfaZBxEd; arc=none smtp.client-ip=209.85.208.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GfaZBxEd" Received: by mail-ed1-f67.google.com with SMTP id 4fb4d7f45d1cf-64b9b0b4d5dso1824171a12.1 for ; Thu, 15 Jan 2026 04:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768479826; x=1769084626; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/Jg8Pr84HZTwL4Chvghj+kThuTRFhOG//CjvHWmAwzw=; b=GfaZBxEd/gUuVrW+fp77GklUDJkMIlFzrqKs+kg1gSTs0b1+nI1PWyWzWGPSoEoJmY 9LH0LnGX0p6P8b70F+bOFUIRoywYFp+VQRpIBifQ8iOxTM2coJjlkrgZ/LaBiYQiiNgN jeC9xiXq9irLUd89egEAoK+2ncMVk7MUq4XwvSzlZ5j9dXW+abdZB6Inbf2nbKzH+xFo tu0XAJtq+8USWplZxpvdUWsgeIgHaiM5qcbILRCPS5CUtdJZGxjWSLPS4+LgtrFvzzBl cEpgQ1iJbhqByzkPQnWAf4KPblHHpWpTT+jpnPujr5N31x6codIwR6HIGSfgfmwTV6Ke cVcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768479826; x=1769084626; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/Jg8Pr84HZTwL4Chvghj+kThuTRFhOG//CjvHWmAwzw=; b=IfdzL11r1YSDLDACmS+5TJIvfteGNwLmXQDcWxGM4Wtq8f9M0CRRfW8lkf/hcm6Ase lIavpCltWeka5v+A1Qcui4jWmw3hnCJbNAPhDEl7TKnQIj8gMA5PnKWnrEn6AViN/2Gf oDQlbPZEoie1kZUqYgQSbz2a6c700PtprxK1mVLLC1R4kh4oX0MVnhP7qHbHV9PE70Oj C5GxZV3qVoA5YcFhGGxR7FaCkU/FMdju/KdSQydRl8R552uDLIqBPc3QFYa1w+BzbarJ bo8kxt5wYYlI/3oMQBzVItRVa1OgUEzIeeC2x4t3FTVbMYWtCMMf4IbAKmwQLm+4E0Gp 7DIg== X-Forwarded-Encrypted: i=1; AJvYcCUzlAC2aa5wbFtHwKBfeYtB+RNNyS5vdG3Occ5Y37F5ErmsJgYCQICJxuADaUPpdPm1FSmKGUOrbajxEIg=@vger.kernel.org X-Gm-Message-State: AOJu0Yyn1smO2r0tsLft/kM+ezdY41lcG6JAZCviouhDuhixFCDvxTVl N/ojF0ERWdFn4Ptqhg8xnDw8u0Az2Vad5TT/G4K9SlZ7HSx4kl32OyoG5Uv6ZVNdKzw= X-Gm-Gg: AY/fxX4ir5L889JquhUzrhVlVxOAMZLXUxUiUcAr2pvX+xUyeVsaUsu60YBRMkVWogX Ha+XMvMGVxAKg9BOA25l5QOLtT2wVm9lI01adCJVn3vDx7gWEqRe6FgWjvL/A0YnA3iHuMDRVER XtYuwhC4iK3mnS5sxDuTxf5qnZCDonhjtjRxpN9VyDkoaoLE2bNvkc4gwb/p3UoKmM5ZFqNc4hd SnfbgCyS/ZUWL2A+M8C6NBNMHAX5Jfo9V4EWvFDlB8gfjjA/k8AIeBXOIft6XHYkSE1+WPhSCEb CoHP9jOfqX/Qx1EkbKTezFHKCCabrZbcw6ynT3u9ZMBlCW8TWtJtzxbNfhxEwFPjbJIf5Ie3Ntj SWFJfoQ32eMdomjCIdbBn+wNsLx4DJDcwCqmM5E3Xfab778c2B8xbt3rv0AyVLgp2P+PQQcbl7x uP9R1nJBBgidC11Vhv8prBH3YZD0MsU+wLLnFI9eUyBwRbaA2xqh0mSTDuDHjpmTpyyi0YLrmP5 UCMqaYORYfNIzAj X-Received: by 2002:a05:6402:210d:b0:64c:584c:556c with SMTP id 4fb4d7f45d1cf-653ec46b3e5mr4990788a12.30.1768479826209; Thu, 15 Jan 2026 04:23:46 -0800 (PST) Received: from localhost (2001-1c00-570d-ee00-7a88-ab31-60c0-33c9.cable.dynamic.v6.ziggo.nl. [2001:1c00:570d:ee00:7a88:ab31:60c0:33c9]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6541209ce83sm2328405a12.32.2026.01.15.04.23.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 04:23:45 -0800 (PST) Date: Thu, 15 Jan 2026 13:23:43 +0100 From: Amir Goldstein To: Chunsheng Luo Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 1/2] fuse: add close all in passthrough backing close for crash recovery Message-ID: References: <20260115072032.402-1-luochunsheng@ustc.edu> <20260115072032.402-2-luochunsheng@ustc.edu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260115072032.402-2-luochunsheng@ustc.edu> On Thu, Jan 15, 2026 at 03:20:30PM +0800, Chunsheng Luo wrote: > Simplify FUSE daemon crash recovery by avoiding persistence of > backing_ids, thereby improving availability and reducing performance > overhead. > > Non-persistent backing_ids after crash recovery may lead to resource > leaks if backing file resources are not properly cleaned up during > daemon restart. > > Add a close_all handler to the backing close operation. This ensures > comprehensive cleanup of all backing file resources when the FUSE > daemon restarts, preventing resource leaks while maintaining the > simplified recovery approach. Am I correct to assume that you are referring to FUSE server restart where the /dev/fuse fd is stored in an external fd store and reused by the new FUSE server instance? > > Signed-off-by: Chunsheng Luo > --- > fs/fuse/backing.c | 14 ++++++++++++++ > fs/fuse/dev.c | 5 +++++ > fs/fuse/fuse_i.h | 1 + > 3 files changed, 20 insertions(+) > > diff --git a/fs/fuse/backing.c b/fs/fuse/backing.c > index 4afda419dd14..34d0ea62fb9b 100644 > --- a/fs/fuse/backing.c > +++ b/fs/fuse/backing.c > @@ -166,6 +166,20 @@ int fuse_backing_close(struct fuse_conn *fc, int backing_id) > return err; > } > > +static int fuse_backing_close_one(int id, void *p, void *data) > +{ > + struct fuse_conn *fc = data; > + > + fuse_backing_close(fc, id); > + > + return 0; > +} > + > +void fuse_backing_close_all(struct fuse_conn *fc) > +{ > + idr_for_each(&fc->backing_files_map, fuse_backing_close_one, fc); > +} > + > struct fuse_backing *fuse_backing_lookup(struct fuse_conn *fc, int backing_id) > { > struct fuse_backing *fb; > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c > index 6d59cbc877c6..25f6bb58623d 100644 > --- a/fs/fuse/dev.c > +++ b/fs/fuse/dev.c > @@ -2651,6 +2651,11 @@ static long fuse_dev_ioctl_backing_close(struct file *file, __u32 __user *argp) > if (get_user(backing_id, argp)) > return -EFAULT; > > + if (backing_id == -1) { > + fuse_backing_close_all(fud->fc); > + return 0; > + } > + I think that an explicit new ioctl FUSE_DEV_IOC_BACKING_CLOSE_ALL is called for this very intrusive operation. Sending FUSE_DEV_IOC_BACKING_CLOSE with backing_id -1 could just as well happen by mistake. Thanks, Amir.