xfs
[Top] [All Lists]

Re: use-after-free in xfs_bawrite()

To: Andrew Morton <akpm@xxxxxxxx>
Subject: Re: use-after-free in xfs_bawrite()
From: Steve Lord <lord@xxxxxxx>
Date: 04 Aug 2003 13:10:56 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20030802013032.7a42a596.akpm@xxxxxxxx>
Organization:
References: <20030802013032.7a42a596.akpm@xxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Sat, 2003-08-02 at 03:30, Andrew Morton wrote:
> Using Linus's current tree plus all the -mm gunk I get a fairly easy oops
> running dbench on XFS on SMP with CONFIG_DEBUG_PAGEALLOC=y:

I can't hit it for some reason, but yes, I see it. As for why xfs
and dbench don't mix so well - its a 2.6 thing, but having looked
at what the other places which wait for I/O in the kernel do, perhaps
if we made some similar changes to the xfs specific spots, things might
improve. Looks like getting into io_schedule would be a good thing
in a few strategic places.

Steve



> 
> Program received signal SIGEMT, Emulation trap.
> 0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at 
> fs/xfs/pagebuf/page_buf.h:397
> 397             if (!pb || atomic_read(&pb->pb_io_remaining))
> (gdb) p pb
> $1 = (page_buf_t *) 0xc98d1004
> (gdb) p *pb
> Cannot access memory at address 0xc98d1004
> (gdb) bt
> #0  0xc0282c9d in xfs_iflush (ip=0xc284a004, flags=2) at 
> fs/xfs/pagebuf/page_buf.h:397
> #1  0xc0283dee in xfs_inode_item_push (iip=0xc2849004) at 
> fs/xfs/xfs_inode_item.c:882
> #2  0xc0294ddf in xfs_trans_push_ail (mp=0xceb87004, 
> threshold_lsn=21474846993) at fs/xfs/xfs_trans_ail.c:170
> #3  0xc0287622 in xlog_grant_push_ail (mp=0xceb87004, need_bytes=492072) at 
> fs/xfs/xfs_log.c:1390
> #4  0xc028652c in xfs_log_reserve (mp=0xceb87004, unit_bytes=157880, cnt=3, 
> ticket=0xc9451038, client=105, 
>     flags=2) at fs/xfs/xfs_log.c:461
> #5  0xc0293afd in xfs_trans_reserve (tp=0xc9451004, blocks=41, 
> logspace=157880, rtextents=0, flags=4, logcount=3)
>     at fs/xfs/xfs_trans.c:275
> #6  0xc029c340 in xfs_mkdir (dir_bdp=0xc0c3e024, dentry=0xca964004, 
> vap=0xc790fec4, vpp=0xc790fec0, credp=0x0)
>     at fs/xfs/xfs_vnodeops.c:2878
> #7  0xc02a687c in linvfs_mknod (dir=0xc0c3f024, dentry=0xca964004, 
> mode=16832, rdev=0)
>     at fs/xfs/linux/xfs_iops.c:136
> #8  0xc02a6a4f in linvfs_mkdir (dir=0xc0c3f024, dentry=0xca964004, mode=448) 
> at fs/xfs/linux/xfs_iops.c:190
> #9  0xc016d838 in vfs_mkdir (dir=0xc0c3f024, dentry=0xca964004, mode=448) at 
> fs/namei.c:1510
> #10 0xc016d901 in sys_mkdir (pathname=0xbffff2e7 
> "CLIENTS/CLIENT16/~DMTMP/SEED", mode=448) at fs/namei.c:1537
> 
> The memory at 0xc98d1004 has been unmapped.
> 
> The oops is on the xfs_iflush() -> xfs_bawrite() -> pagebuf_run_queues() path.
> 
> It looks to me like pagebuf_iostart() has called pagebuf_iorequest() which 
> called
> _pagebuf_iodone() which called pagebuf_iodone() whuich threw away the pagebuf.
> 
> If this is vaguely correct then this part of pagebuf_iostart():
> 
>       /* Wait for I/O if we are not an async request */
>       if ((status == 0) && (flags & PBF_ASYNC) == 0) {
> 
> also needs attention...
> 
> 
> The below quick patch fixes it up.  But it also causes zillions of dentries
> and inodes to be leaked for some reason.  Consider it a technology
> demonstration!
> 
> XFS has waaaaay too much inlining btw ;)
> 
> Seems that dbench is not XFS's favourite benchmark.  How come?  Do I need
> more logbufs?
> 
> 
> 
>  fs/xfs/xfs_buf.h |    2 ++
>  1 files changed, 2 insertions(+)
> 
> diff -puN fs/xfs/xfs_buf.h~a fs/xfs/xfs_buf.h
> --- 25/fs/xfs/xfs_buf.h~a     2003-08-02 00:53:59.000000000 -0700
> +++ 25-akpm/fs/xfs/xfs_buf.h  2003-08-02 00:56:03.000000000 -0700
> @@ -220,8 +220,10 @@ static inline int        xfs_bawrite(void *mp, 
>       bp->pb_fspriv3 = mp;
>       bp->pb_strat = xfs_bdstrat_cb;
>       xfs_buf_undelay(bp);
> +     atomic_inc(&bp->pb_hold);
>       if ((ret = pagebuf_iostart(bp, PBF_WRITE | PBF_ASYNC)) == 0)
>               pagebuf_run_queues(bp);
> +     pagebuf_rele(bp);
>       return ret;
>  }
>  
> 
> _
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


<Prev in Thread] Current Thread [Next in Thread>