xfs: symlinks can be zero length during log recovery
PATCH 1/1 xfs: symlinks can be zero length during log recovery
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through xfs_dinode_verify() during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.
Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
--- fs/xfs/libxfs/xfs_inode_buf.c | 16 +++++++++++++--- fs/xfs/libxfs/xfs_symlink_remote.c | 12 +++++++++--- fs/xfs/xfs_log.c | 11 +++++++++++ fs/xfs/xfs_log.h | 3 ++- 4 files changed, 35 insertions(+), 7 deletions(-)
fs/xfs/libxfs/xfs_inode_buf.c +13 -3
@@ -19,6 +19,7 @@#include "xfs_trans.h" #include "xfs_ialloc.h" #include "xfs_dir2.h" +#include "xfs_log.h" #include <linux/iversion.h>
@@ -411,9 +412,18 @@ xfs_dinode_verify(if (mode &&xfs_mode_to_ftype (mode) ==XFS_DIR3_FT_UNKNOWN )return __this_address; -/* No zero-length symlinks/dirs. */ -if ((S_ISLNK (mode) ||S_ISDIR (mode)) && di_size ==0 ) -return __this_address; +/* +* Normally both symlinks and dirs cannot be zero length. However, if a +* symlink is in the process of being torn down and there's a +* shutdown/crash, the symlink on disk may have a zero size. Hence we +* only allow zero length symlinks during log recovery. +*/ +if (di_size ==0 ) { +if (S_ISDIR (mode)) +return __this_address; +if (S_ISLNK (mode) && !xfs_log_in_recovery (mp)) +return __this_address; + }/* Fork checks carried over from xfs_iformat_fork */ if (mode &&
fs/xfs/libxfs/xfs_symlink_remote.c +9 -3
@@ -215,9 +215,15 @@ xfs_symlink_shortform_verify( size = ifp->if_bytes; endp = sfp + size; -/* Zero length symlinks can exist while we're deleting a remote one. */ -if (size ==0 ) -return NULL ; +/* +* Zero length symlinks can only pass through here during log recovery +* while recovering deletion of a remote symlink. +*/ +if (size ==0 ) { +if (xfs_log_in_recovery (ip->i_mount)) +return NULL ; +return __this_address; + }/* No negative sizes or overly long symlink targets. */ if (size <0 || size >XFS_SYMLINK_MAXLEN )
fs/xfs/xfs_log.c +11 -0
@@ -4083,3 +4083,14 @@ xfs_log_check_lsn(return valid; } + +bool +xfs_log_in_recovery ( +struct xfs_mount *mp) +{ +if (!mp->m_log) +return false; +if (mp->m_log->l_flags &XLOG_ACTIVE_RECOVERY ) +return true; +return false; +}
fs/xfs/xfs_log.h +2 -1
@@ -152,6 +152,7 @@ bool xfs_log_item_in_current_chkpt(struct xfs_log_item *lip);void xfs_log_work_queue (struct xfs_mount *mp);void xfs_log_quiesce (struct xfs_mount *mp); -bool xfs_log_check_lsn (struct xfs_mount *,xfs_lsn_t ); +bool xfs_log_check_lsn (struct xfs_mount *mp,xfs_lsn_t lsn); +bool xfs_log_in_recovery (struct xfs_mount *mp);#endif /* __XFS_LOG_H__ */
Signature · 1 line
2.17.0
Quoted 12 lines · Dave Chinner
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through
xfs_dinode_verify()during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.
Quoted 5 lines
Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
Signed-off-by Dave Chinner <[email protected]>
Looks reasonable.
Quoted 97 lines
--- fs/xfs/libxfs/xfs_inode_buf.c | 16 +++++++++++++--- fs/xfs/libxfs/xfs_symlink_remote.c | 12 +++++++++--- fs/xfs/xfs_log.c | 11 +++++++++++ fs/xfs/xfs_log.h | 3 ++- 4 files changed, 35 insertions(+), 7 deletions(-)fs/xfs/libxfs/xfs_inode_buf.c +13
-3@@ -19,6 +19,7 @@#include "xfs_trans.h" #include "xfs_ialloc.h" #include "xfs_dir2.h" +#include "xfs_log.h" #include <linux/iversion.h> @@ -411,9 +412,18 @@ xfs_dinode_verify(if (mode &&xfs_mode_to_ftype (mode) ==XFS_DIR3_FT_UNKNOWN )return __this_address; -/* No zero-length symlinks/dirs. */ -if ((S_ISLNK (mode) ||S_ISDIR (mode)) && di_size ==0 ) -return __this_address; +/* +* Normally both symlinks and dirs cannot be zero length. However, if a +* symlink is in the process of being torn down and there's a +* shutdown/crash, the symlink on disk may have a zero size. Hence we +* only allow zero length symlinks during log recovery. +*/ +if (di_size ==0 ) { +if (S_ISDIR (mode)) +return __this_address; +if (S_ISLNK (mode) && !xfs_log_in_recovery (mp)) +return __this_address; + }/* Fork checks carried over from xfs_iformat_fork */ if (mode &&fs/xfs/libxfs/xfs_symlink_remote.c +9
-3@@ -215,9 +215,15 @@ xfs_symlink_shortform_verify( size = ifp->if_bytes; endp = sfp + size; -/* Zero length symlinks can exist while we're deleting a remote one. */ -if (size ==0 ) -return NULL ; +/* +* Zero length symlinks can only pass through here during log recovery +* while recovering deletion of a remote symlink. +*/ +if (size ==0 ) { +if (xfs_log_in_recovery (ip->i_mount)) +return NULL ; +return __this_address; + }/* No negative sizes or overly long symlink targets. */ if (size <0 || size >XFS_SYMLINK_MAXLEN )fs/xfs/xfs_log.c +11
-0@@ -4083,3 +4083,14 @@ xfs_log_check_lsn(return valid; } + +bool +xfs_log_in_recovery ( +struct xfs_mount *mp) +{ +if (!mp->m_log) +return false; +if (mp->m_log->l_flags &XLOG_ACTIVE_RECOVERY ) +return true; +return false; +}fs/xfs/xfs_log.h +2
-1@@ -152,6 +152,7 @@ bool xfs_log_item_in_current_chkpt(struct xfs_log_item *lip);void xfs_log_work_queue (struct xfs_mount *mp);void xfs_log_quiesce (struct xfs_mount *mp); -bool xfs_log_check_lsn (struct xfs_mount *,xfs_lsn_t ); +bool xfs_log_check_lsn (struct xfs_mount *mp,xfs_lsn_t lsn); +bool xfs_log_in_recovery (struct xfs_mount *mp);#endif /* __XFS_LOG_H__ */
Quoted 17 lines · Eric Sandeen
Quoted 16 lines · Dave Chinner
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through
xfs_dinode_verify()during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
Quoted 5 lines
Quoted 1 line
Signed-off-by Dave Chinner <[email protected]>Looks reasonable.
Reviewed-by Eric Sandeen <[email protected]>
Also probably worth tagging with
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200063
Quoted 22 lines · Eric Sandeen
Quoted 19 lines · Eric Sandeen
Quoted 17 lines · Dave Chinner
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through
xfs_dinode_verify()during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
Signed-off-by Dave Chinner <[email protected]>
Quoted 7 lines
Quoted 3 lines
Looks reasonable.
Reviewed-by Eric Sandeen <[email protected]>Also probably worth tagging with
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200063
Why? I didn't know that existed until you pointed it out, and I still haven't looked at it as I write this....
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 12 lines · Dave Chinner
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through
xfs_dinode_verify()during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.
Quoted 6 lines
Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
Signed-off-by Dave Chinner <[email protected]>---
Seems Ok to me, but before we restrict some of the existing checks to log recovery I am curious about one thing. xfs_inactive_symlink() has this:
/*
* Zero length symlinks _can_ exist.
*/
pathlen = (int)ip->i_d.di_size;
if (!pathlen) {
xfs_iunlock(ip, XFS_ILOCK_EXCL);
return 0;
}I'm not quite sure what case that covers, but it seems slightly inconsistent with the fork verifer change (simply because that path is not exclusive to the read from disk case), at least. Any idea?
Brian
Quoted 102 lines
fs/xfs/libxfs/xfs_inode_buf.c | 16 +++++++++++++--- fs/xfs/libxfs/xfs_symlink_remote.c | 12 +++++++++--- fs/xfs/xfs_log.c | 11 +++++++++++ fs/xfs/xfs_log.h | 3 ++- 4 files changed, 35 insertions(+), 7 deletions(-)fs/xfs/libxfs/xfs_inode_buf.c +13
-3@@ -19,6 +19,7 @@#include "xfs_trans.h" #include "xfs_ialloc.h" #include "xfs_dir2.h" +#include "xfs_log.h" #include <linux/iversion.h> @@ -411,9 +412,18 @@ xfs_dinode_verify(if (mode &&xfs_mode_to_ftype (mode) ==XFS_DIR3_FT_UNKNOWN )return __this_address; -/* No zero-length symlinks/dirs. */ -if ((S_ISLNK (mode) ||S_ISDIR (mode)) && di_size ==0 ) -return __this_address; +/* +* Normally both symlinks and dirs cannot be zero length. However, if a +* symlink is in the process of being torn down and there's a +* shutdown/crash, the symlink on disk may have a zero size. Hence we +* only allow zero length symlinks during log recovery. +*/ +if (di_size ==0 ) { +if (S_ISDIR (mode)) +return __this_address; +if (S_ISLNK (mode) && !xfs_log_in_recovery (mp)) +return __this_address; + }/* Fork checks carried over from xfs_iformat_fork */ if (mode &&fs/xfs/libxfs/xfs_symlink_remote.c +9
-3@@ -215,9 +215,15 @@ xfs_symlink_shortform_verify( size = ifp->if_bytes; endp = sfp + size; -/* Zero length symlinks can exist while we're deleting a remote one. */ -if (size ==0 ) -return NULL ; +/* +* Zero length symlinks can only pass through here during log recovery +* while recovering deletion of a remote symlink. +*/ +if (size ==0 ) { +if (xfs_log_in_recovery (ip->i_mount)) +return NULL ; +return __this_address; + }/* No negative sizes or overly long symlink targets. */ if (size <0 || size >XFS_SYMLINK_MAXLEN )fs/xfs/xfs_log.c +11
-0@@ -4083,3 +4083,14 @@ xfs_log_check_lsn(return valid; } + +bool +xfs_log_in_recovery ( +struct xfs_mount *mp) +{ +if (!mp->m_log) +return false; +if (mp->m_log->l_flags &XLOG_ACTIVE_RECOVERY ) +return true; +return false; +}fs/xfs/xfs_log.h +2
-1@@ -152,6 +152,7 @@ bool xfs_log_item_in_current_chkpt(struct xfs_log_item *lip);void xfs_log_work_queue (struct xfs_mount *mp);void xfs_log_quiesce (struct xfs_mount *mp); -bool xfs_log_check_lsn (struct xfs_mount *,xfs_lsn_t ); +bool xfs_log_check_lsn (struct xfs_mount *mp,xfs_lsn_t lsn); +bool xfs_log_in_recovery (struct xfs_mount *mp);#endif /* __XFS_LOG_H__ */ Signature · 6 lines
2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 33 lines · Brian Foster
Quoted 12 lines · Dave Chinner
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through
xfs_dinode_verify()during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.Quoted 6 lines
Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
Signed-off-by Dave Chinner <[email protected]>---
Seems Ok to me, but before we restrict some of the existing checks to log recovery I am curious about one thing.
xfs_inactive_symlink()has this:/* * Zero length symlinks _can_ exist. */ pathlen = (int)ip->i_d.di_size; if (!pathlen) { xfs_iunlock(ip, XFS_ILOCK_EXCL); return 0; }
Quoted 3 lines
I'm not quite sure what case that covers, but it seems slightly inconsistent with the fork verifer change (simply because that path is not exclusive to the read from disk case), at least. Any idea?
Yeah, that's what I'm trying to chase down right now. I had the verifier fire on inode writeback during generic/269. I don't know yet where these zero length symlinks are coming from, and none of the comments (there's a couple that say the above) actually give any hint to their source.
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 38 lines · Dave Chinner
Quoted 33 lines · Brian Foster
Quoted 12 lines · Dave Chinner
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through
xfs_dinode_verify()during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.Quoted 6 lines
Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
Signed-off-by Dave Chinner <[email protected]>---
Seems Ok to me, but before we restrict some of the existing checks to log recovery I am curious about one thing.
xfs_inactive_symlink()has this:/* * Zero length symlinks _can_ exist. */ pathlen = (int)ip->i_d.di_size; if (!pathlen) { xfs_iunlock(ip, XFS_ILOCK_EXCL); return 0; }Quoted 3 lines
I'm not quite sure what case that covers, but it seems slightly inconsistent with the fork verifer change (simply because that path is not exclusive to the read from disk case), at least. Any idea?
Quoted 5 lines
Yeah, that's what I'm trying to chase down right now. I had the verifier fire on inode writeback during generic/269. I don't know yet where these zero length symlinks are coming from, and none of the comments (there's a couple that say the above) actually give any hint to their source.
Ok, so there is this comment in fs/namei.c w.r.t. symlink handling before getname_flags():
* POSIX.1 2.4: an empty pathname is invalid (ENOENT).
So the call chain is
sys_symlink(oldname ....)
do_symlinkat(oldname ...)
getname(oldname)
getname_flags(oldname, 0, NULL)
len = strncpy_from_user(... oldname ....)
....
if (!len) {
if (!(flags & LOOKUP_EMPTY))
return -ENOENT;
}So we should never see a zero length symlink from userspace as flags is always zero. Hence if we are seeing zero length symlinks on disk, then that's an XFS implementation issue, not a user API requirement.
There's two issues in the symlink code that can lead to zero length symlinks firing the verifiers. They are symptoms of the same core issue in xfs_inactive_symlink(): the inode is unlocked between the symlink inactivation/truncation and the inode being freed. This opens a window for the inode to be written to disk before it xfs_ifree() removes it from the unlinked list, marks it free in the inobt and zeros the mode.
The first, and simplest to solve issue is the shortform verifier. This verifier doesn't actually verify on disk state - it verifies *in memory inode fork state*. Specifically, it checks for a zero length inode fork (ifp->if_bytes) and says specifically "this can happen". The only place it can happen in in the window between xfs_inactive_symlink() and xfs_ifree() because xfs_inactive_symlink() tears down the data fork. It doesn't, however, change the inode size, so if the inode is written back to disk in this window, it's written with a non-zero size, leaving the data fork in the inode untouched. i.e. the inode on disk is still a valid symlink.
To fix this is easy. xfs_ifree() actually cleans up the in-memory data and attr fork structures, and so there is absolutely no need to do it in xfs_inactive_symlink(). With that change, the symlink verifier error goes away.
Which leaves remote symlink inactivation. This runs a transaction that truncates away the symlink extent and sets the inode size to zero. IOWs, it creates an actual path for zero length symlinks on disk. However, the symlink inode at this point is unreferenced by userspace and is on the unlinked list, and hence userspace can never see a zero length symlink inode. This does, however, create a problem - we can get zero length symlinks on disk in log recovery because the inode size is set to zero at the same time the EFI intents are recorded. hence if log recovery then reads the inode off disk to replay EFIs or other non-completed intents, it can see a symlink inode with zero length.
So we have a choice here: either special case log recovery for symlink inode verification, or prevent zero length extent for symlink inodes from existing on disk. The former is essentially the patch I posted, the latter requires discussion.
If we want to avoid zero length extent form symlinks on disk we either need to make the inactivation and freeing atomic, or we can make symlink inactivation change the type of inode to something that allows zero length. The former is complex and a major undertaking (new deferred op, a bunch of new intents, log recovery work, etc) while the latter is one line of code. i.e. we simply change the mode of the inode to a regular file at the same time we set the size to zero.
If the transaction with the EFIs and zero size goes to disk, we don't really care what the inode type is. it's on the unlinked list, can't be seen from userspace, and we just need to run extent removal and freeing on it in log recovery. Hence if we change it to be a regular file inode, then we maintain the "no zero length symlinks on disk" rule, and we get cleanup occurring without any new code or concerns being created.
Thoughts?
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 12 lines · Dave Chinner
From: Dave Chinner <[email protected]>
A log recovery failure has been reproduced where a symlink inode has a zero length in extent form. It was caused by a shutdown during a combined fstress+fsmark workload.
To fix it, we have to allow zero length symlink inodes through
xfs_dinode_verify()during log recovery. We already specifically check and allow this case in the shortform symlink fork verifier, but in this case we don't get that far, and the inode is not in shortform format.
Quoted 5 lines
Update the dinode verifier to handle this case, and change the symlink fork verifier to only allow this case to exist during log recovery.
Signed-off-by Dave Chinner <[email protected]>
Self-NAK on this - I've got a patch that prevents zero length symlinks from going to disk, so allowing them through log recovery is not necessary - they are always invalid.....
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]