[PATCH] xfs: superblock buffers need to be sector sized

[PATCH] xfs: superblock buffers need to be sector sized

[Dave Chinner]

From: Dave Chinner <dchinner@redhat.com>

In secondary_sb_wack() we zero the unused portion of both the
on-disk superblock and the in-memory copy that we have. When
the device sector size is 4k, this causes xfs_repair to crash like
so:

# xfs_repair /dev/ram1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
bad magic number
bad on-disk superblock 3 - bad magic number
primary/secondary superblock 3 conflict - AG superblock geometry info conflicts with filesystem geometry
zeroing unused portion of secondary superblock (AG #3)
#

The stack trace is indicative:

#0  memset ()
#1  0x000000000040404b in secondary_sb_wack
#2  verify_set_agheader
#3  0x0000000000427b4b in scan_ag
#4  0x000000000042a2ca in worker_thread
#5  0x00007ffff77ba0a4 in start_thread
#6  0x00007ffff74efc2d in clone

Which points at memset overrunning the in memory buffer, as it is
only 512 bytes in length.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
 repair/scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/repair/scan.c b/repair/scan.c
index ce8d7f5..12aa782 100644
--- a/repair/scan.c
+++ b/repair/scan.c
@@ -1485,7 +1485,7 @@ scan_ag(
 	int		status;
 	char		*objname = NULL;
 
-	sb = (struct xfs_sb *)calloc(BBSIZE, 1);
+	sb = (struct xfs_sb *)calloc(BBTOB(XFS_FSS_TO_BB(mp, 1)), 1);
 	if (!sb) {
 		do_error(_("can't allocate memory for superblock\n"));
 		return;
-- 
2.0.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfs: superblock buffers need to be sector sized

[Brian Foster]

On Tue, Feb 24, 2015 at 06:12:24PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> In secondary_sb_wack() we zero the unused portion of both the
> on-disk superblock and the in-memory copy that we have. When
> the device sector size is 4k, this causes xfs_repair to crash like
> so:
> 
> # xfs_repair /dev/ram1
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - zero log...
>         - scan filesystem freespace and inode maps...
> bad magic number
> bad on-disk superblock 3 - bad magic number
> primary/secondary superblock 3 conflict - AG superblock geometry info conflicts with filesystem geometry
> zeroing unused portion of secondary superblock (AG #3)
> #
> 
> The stack trace is indicative:
> 
> #0  memset ()
> #1  0x000000000040404b in secondary_sb_wack
> #2  verify_set_agheader
> #3  0x0000000000427b4b in scan_ag
> #4  0x000000000042a2ca in worker_thread
> #5  0x00007ffff77ba0a4 in start_thread
> #6  0x00007ffff74efc2d in clone
> 
> Which points at memset overrunning the in memory buffer, as it is
> only 512 bytes in length.
> 
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---

The patch subject line should probably say 'xfsprogs:' or 'repair:,'
otherwise this looks good to me:

Reviewed-by: Brian Foster <bfoster@redhat.com>

>  repair/scan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/repair/scan.c b/repair/scan.c
> index ce8d7f5..12aa782 100644
> --- a/repair/scan.c
> +++ b/repair/scan.c
> @@ -1485,7 +1485,7 @@ scan_ag(
>  	int		status;
>  	char		*objname = NULL;
>  
> -	sb = (struct xfs_sb *)calloc(BBSIZE, 1);
> +	sb = (struct xfs_sb *)calloc(BBTOB(XFS_FSS_TO_BB(mp, 1)), 1);
>  	if (!sb) {
>  		do_error(_("can't allocate memory for superblock\n"));
>  		return;
> -- 
> 2.0.0
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfs: superblock buffers need to be sector sized

[Dave Chinner]

On Tue, Feb 24, 2015 at 08:36:52AM -0500, Brian Foster wrote:
> On Tue, Feb 24, 2015 at 06:12:24PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > In secondary_sb_wack() we zero the unused portion of both the
> > on-disk superblock and the in-memory copy that we have. When
> > the device sector size is 4k, this causes xfs_repair to crash like
> > so:
> > 
> > # xfs_repair /dev/ram1
> > Phase 1 - find and verify superblock...
> > Phase 2 - using internal log
> >         - zero log...
> >         - scan filesystem freespace and inode maps...
> > bad magic number
> > bad on-disk superblock 3 - bad magic number
> > primary/secondary superblock 3 conflict - AG superblock geometry info conflicts with filesystem geometry
> > zeroing unused portion of secondary superblock (AG #3)
> > #
> > 
> > The stack trace is indicative:
> > 
> > #0  memset ()
> > #1  0x000000000040404b in secondary_sb_wack
> > #2  verify_set_agheader
> > #3  0x0000000000427b4b in scan_ag
> > #4  0x000000000042a2ca in worker_thread
> > #5  0x00007ffff77ba0a4 in start_thread
> > #6  0x00007ffff74efc2d in clone
> > 
> > Which points at memset overrunning the in memory buffer, as it is
> > only 512 bytes in length.
> > 
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
> 
> The patch subject line should probably say 'xfsprogs:' or 'repair:,'
> otherwise this looks good to me:

Right, my mistake.

> Reviewed-by: Brian Foster <bfoster@redhat.com>

Thanks,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs