From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 ADE2934B194 for ; Fri, 12 Jun 2026 01:28:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781227683; cv=none; b=H9CH+WyY6s776wGxeMSKrn71qgftWWdJbqYtn2S/hyv2LYGiMcquvVHnPL/2msnqRfJzfEB56UFvmLcZr13blUJXIC7L7bCPqzjO/OLTOx2RkSvHu/WmnuX+tMifFXjmvsySDkt+4A89rWLjqVmMHa/VzkJ8gdUl1lYYPNN0TAo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781227683; c=relaxed/simple; bh=FXrj/w7ZXv0Gok+tAroH0Pb6+LOUFgOiV6HqDg/TiRc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pWtgTqeBAwYu64L5ME7IdzcYjPcla1yB1BWPydKloezeJllfxn5frqlGf9Ei/p9mq7VrkrLQpj/N4wrJbHxXx+aLhKz6NmCd6PZuaE0qaZ7MksaRZSMQTtvhq1RW4IgidnFZVG1n3WHpevcs2rb2Hsg7pRZgXEgx9c8mTq3guGU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=LPUkjS8Z; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="LPUkjS8Z" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-45ef42b6399so44522f8f.0 for ; Thu, 11 Jun 2026 18:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1781227679; x=1781832479; 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=tzaqJwTHaFZzTp92//qArkg/N8YcxfHMHejrUhtyGSY=; b=LPUkjS8ZFOlFgRcxRBP0vk+JoNw1zKW42T9TABnCxUKnIIxtxxPWNUFFrDVMsCDy/w qT2sAQf1FeUCILHrWlh2LY7DxZ23a/ZM6lHFR6h88t6hK6SMdwdPN3tUzsACFdIYsOmd ZfRqIzErDoPk7VMqiw/eNWSPz1zU0Y2l0xdGZlLeMKTJoEg8dYJsKQsECgroYc4Vd0dm 9rSZcZmswI5UB2KJSwSME3sOFGeKkmvunBM11A8IObfGMjViesrp2QZFW3FOCD/8IolY ormfOPI5I7tUB4SsjDoNmo2UyDf4oDy1KOI6ySqsfyl+T3GWGw2/cR+zsn24p3glKDyN QWiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781227679; x=1781832479; 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=tzaqJwTHaFZzTp92//qArkg/N8YcxfHMHejrUhtyGSY=; b=E4l3KEGhntE1dYUBJ3FLh51vdKFzlII3cahKqqd3E1yh9Wzy7c7xxnwNWhm0jmLaS0 wwC1SzYIk+vB8oPb5xXUwki6k7hGEfUdQrzQTi+4yQK5XsfiWsCyqYuSgBSizeXIfAVr AYNIIaX5gfe9rtLpKcdUBm689FsmcuwjeDvSkM24skX1gcX4YaqnAE+yGuRSltul6mMz 9m+HKHlAjUMSGU02pw4rsWmCBsgwZRPmuJOv81pWTg4CySxCMh1TFJVTgPePD56CzC4m k+rqnmkfN0YimwvoSYNeOudvPkCjQj5R231nrRetXAsyPmMMxjZvF/ClxX0/tSgQHr6p +r6w== X-Forwarded-Encrypted: i=1; AFNElJ/EWWXoHHf5aYoALzHxRTxVeUMBOVKNcC+KiR7og4KPTdvsD3sgmnY+f5yRcfsY6JlMVwCSZK2IQjuZ2fw=@vger.kernel.org X-Gm-Message-State: AOJu0Yx43lf469xhDzm1ybXOjzlpASQbJ3CbK+sIKWPu3OPY6i5e11Jk ytT5b0CLjIkl/WDI6UPj1AGwaZeLt4nhRFRk2ipQtoPLz08Pxs+OWslHrERGaB9FDAQ= X-Gm-Gg: Acq92OH/pJeAP56YVE9E9lDZqgKe/XO4gcKnZtc9FR0gxNYY+XC4UImtW88vIztl9eq aoH6NccjOa44CIxnxMc0h36WtiL6H2JzAaUtp0G732FdV0f0bHqfIc4dYrXdTqvE4PJ3GHqjPYB dd5+12ka/LrgIs4vzR2Lj77wUBY6KoDQy0dZvXQn3tbD5S2oP4AeuWX7jdniJeBK7KPx9KO2mus eClFB2DFxyITVAYFpjyr0pO4oNgFb/w8JXyzPbU6lKqYMan2iXPBCbO34JBZemfgi7Yipd+SzYI tkFronF4nq2iBbKlXt1VbK3YrvggiZ5NmXko+QeK5ChJnMll5U7eZ0384xoJjm/E84+mPT+mXSU q80zwPBrNwSNlTYZnsK8EeAYWsoCAx56iDr9HcodPRq5ajKPehWIIi7hEXQWs6gcLWw9IK2GC9F gmjHwnJf2mFgq69xeTPIY7JA== X-Received: by 2002:a5d:5e09:0:b0:45e:91ec:d4c4 with SMTP id ffacd0b85a97d-4606dbb1cc8mr456888f8f.7.1781227678960; Thu, 11 Jun 2026 18:27:58 -0700 (PDT) Received: from localhost ([202.127.77.110]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1384b91a4c7sm612658c88.8.2026.06.11.18.27.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 18:27:58 -0700 (PDT) Date: Fri, 12 Jun 2026 09:27:55 +0800 From: Heming Zhao To: Marco Elver Cc: Mark Fasheh , Joel Becker , Joseph Qi , ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Subject: Re: [PATCH] ocfs2: fix orphan inode disk leak in ocfs2_dio_end_io() on I/O error Message-ID: References: <20260611150341.3964327-1-elver@google.com> 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: <20260611150341.3964327-1-elver@google.com> On Thu, Jun 11, 2026 at 05:01:50PM +0200, Marco Elver wrote: > When an extending direct I/O write or a direct I/O write racing with an > unlink is initiated, ocfs2_direct_IO() places the user inode into the > system orphan directory and sets the OCFS2_DIO_ORPHANED_FL flag to > ensure defined behavior and crash consistency. > > However, if the direct I/O request encounters an error or gets > asynchronous cancellation (bytes <= 0), the VFS completion hook > ocfs2_dio_end_io() bypasses ocfs2_dio_end_io_write() entirely and > executes ocfs2_dio_free_write_ctx(). This completely omits the teardown > of the orphan entry, leaking the user inode in the orphan directory and > leaving the OCFS2_DIO_ORPHANED_FL disk flag set. > > Because the OCFS2_DIO_ORPHANED_FL flag remains active, subsequent VFS > final inode eviction (ocfs2_delete_inode) observes the flag, assumes a > direct I/O write is actively in progress, and refuses to wipe the inode. > This results in an irrecoverable disk storage and resource leak that can > only be reclaimed if the cluster unmounts or crashes. > > Fix this by ensuring that ocfs2_dio_end_io() inspects dw_orphaned even > when an I/O error occurs, and executes ocfs2_del_inode_from_orphan() to > liberate the inode before destroying the in-memory write context. > > Fixes: 5040f8df56fb ("ocfs2: free up write context when direct IO failed") > Assisted-by: Antigravity:Gemini > Signed-off-by: Marco Elver > --- > fs/ocfs2/aops.c | 17 +++++++++++++++-- > 1 file changed, 15 insertions(+), 2 deletions(-) > > diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c > index 4acdbb70882c..ad3f2057e26e 100644 > --- a/fs/ocfs2/aops.c > +++ b/fs/ocfs2/aops.c > @@ -2419,11 +2419,24 @@ static int ocfs2_dio_end_io(struct kiocb *iocb, > mlog_ratelimited(ML_ERROR, "Direct IO failed, bytes = %lld", > (long long)bytes); > if (private) { > - if (bytes > 0) > + if (bytes > 0) { > ret = ocfs2_dio_end_io_write(inode, private, offset, > bytes); > - else > + } else { > + struct ocfs2_dio_write_ctxt *dwc = private; > + > + if (dwc->dw_orphaned) { > + struct buffer_head *di_bh = NULL; > + > + if (ocfs2_inode_lock(inode, &di_bh, 1) == 0) { > + ocfs2_del_inode_from_orphan(OCFS2_SB(inode->i_sb), > + inode, di_bh, 0, 0); > + ocfs2_inode_unlock(inode, 1); > + brelse(di_bh); > + } Calling only ocfs2_del_inode_from_orphan() without ocfs2_truncate_file() will leave stale blocks beyond the EOF. I think the existing OCFS2 code already handles error/crash cases for orphaned inodes, and this "leaking" behavior is by design. please refer to ocfs2_recover_orphans() and ocfs2_add_inode_to_orphan(). Thanks, Heming > + } > ocfs2_dio_free_write_ctx(inode, private); > + } > } > > ocfs2_iocb_clear_rw_locked(iocb); > -- > 2.54.0.1099.g489fc7bff1-goog > >