From: Christoph Hellwig <hch@infradead.org>
To: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Dave Chinner <dchinner@redhat.com>,
Allison Henderson <allison.henderson@oracle.com>,
Zhang Tianci <zhangtianci.1997@bytedance.com>,
Brian Foster <bfoster@redhat.com>, Ben Myers <bpm@sgi.com>,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
xieyongji@bytedance.com, me@jcix.top
Subject: Re: [PATCH 1/2] xfs: ensure tmp_logflags is initialized in xfs_bmap_del_extent_real
Date: Tue, 28 Nov 2023 00:19:23 -0800 [thread overview]
Message-ID: <ZWWii6HhlfkWXSq8@infradead.org> (raw)
In-Reply-To: <20231128053202.29007-2-zhangjiachen.jaycee@bytedance.com>
On Tue, Nov 28, 2023 at 01:32:01PM +0800, Jiachen Zhang wrote:
> In the case of returning -ENOSPC, ensure tmp_logflags is initialized by 0.
> Otherwise the caller __xfs_bunmapi will set uninitialized illegal
> tmp_logflags value into xfs log, which might cause unpredictable error
> in the log recovery procedure.
This looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
But I wonder if removing the local flags variable and always directly
assigning to *logflagsp might be more robust in the long run.
next prev parent reply other threads:[~2023-11-28 8:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 5:32 [PATCH 0/2] Fixes for ENOSPC xfs_remove Jiachen Zhang
2023-11-28 5:32 ` [PATCH 1/2] xfs: ensure tmp_logflags is initialized in xfs_bmap_del_extent_real Jiachen Zhang
2023-11-28 8:19 ` Christoph Hellwig [this message]
2023-11-28 16:19 ` Darrick J. Wong
2023-11-28 5:32 ` [PATCH 2/2] xfs: update dir3 leaf block metadata after swap Jiachen Zhang
2023-11-28 8:39 ` Christoph Hellwig
2023-11-28 9:39 ` Jiachen Zhang
2023-11-28 16:29 ` Darrick J. Wong
2023-11-28 11:18 ` kernel test robot
2023-11-28 12:08 ` kernel test robot
2023-11-28 23:15 ` Dave Chinner
2023-11-29 6:34 ` Christoph Hellwig
2023-11-29 8:46 ` Dave Chinner
2023-11-29 6:34 ` Darrick J. Wong
2023-11-29 7:28 ` [External] " Zhang Tianci
2023-11-29 8:50 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZWWii6HhlfkWXSq8@infradead.org \
--to=hch@infradead.org \
--cc=allison.henderson@oracle.com \
--cc=bfoster@redhat.com \
--cc=bpm@sgi.com \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=me@jcix.top \
--cc=xieyongji@bytedance.com \
--cc=zhangjiachen.jaycee@bytedance.com \
--cc=zhangtianci.1997@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.