xfs
[Top] [All Lists]

Re: [xfs-masters] Re: fs/xfs/xfs_vnodeops.c:xfs_readdir(): NULL variable

To: Adrian Bunk <bunk@xxxxxxxxx>
Subject: Re: [xfs-masters] Re: fs/xfs/xfs_vnodeops.c:xfs_readdir(): NULL variable dereferenced
From: Nathan Scott <nathans@xxxxxxx>
Date: Sun, 9 Jul 2006 11:04:59 +1000
Cc: David Chinner <dgc@xxxxxxx>, xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
In-reply-to: <20060708194609.GB5020@stusta.de>; from bunk@stusta.de on Sat, Jul 08, 2006 at 09:46:09PM +0200
References: <20060706211320.GW26941@stusta.de> <20060706233246.GB15160733@melbourne.sgi.com> <20060708194609.GB5020@stusta.de>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Sat, Jul 08, 2006 at 09:46:09PM +0200, Adrian Bunk wrote:
> On Fri, Jul 07, 2006 at 09:32:46AM +1000, David Chinner wrote:
> > > Coverity checker found a way how tp might be dereferenced four function 
> > > calls later).

Keyword being "might". ;)

> > Then the bug is probably in the function call that uses tp without
> > first checking whether it's null. Can you tell us where that dereference
> > occurs?
> 
> xfs_readdir()
>   xfs_dir_getdents()
>     xfs_dir2_leaf_getdents()
>       xfs_bmapi()
>         xfs_trans_log_inode()
>           tp->t_flags |= XFS_TRANS_DIRTY;

This actually cant happen due to the flags passed into xfs_bmapi (ie.
request for a extent map _read_, which wont result in the inode being
logged, which means no transaction dirtying).

That suggestion to remove the local "tp" variable was valid though,
we may as well do that (will do).

cheers.

-- 
Nathan


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