xfs
[Top] [All Lists]

Re: Bug submission?

To: "linux-xfs@xxxxxxxxxxx" <linux-xfs@xxxxxxxxxxx>
Subject: Re: Bug submission?
From: "Ian S. Nelson" <ian.nelson@xxxxxxxxxxxx>
Date: Tue, 11 Apr 2000 13:20:59 -0600
Organization: Echostar
References: <38F370DE.6B35A30@echostar.com> <14579.30137.543740.87172K@gibble.americas.sgi.com>
Reply-to: ian.nelson@xxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
cattelan@xxxxxxxxxxx wrote:

> At Tue, 11 Apr 2000 12:37:18 -0600,
> Ian S. Nelson <ian.nelson@xxxxxxxxxxxx> wrote:
> >
> >
> > How do I submit bugs?
> just send it to the list at the moment.
>
> > I've been hammering on XFS and it works great until I export it and
> > start hammering on it over NFS. It pretty regularly causes a kernel
> > panic or some distortion of data.   Files aren't read properly, can't
> > remove directories, things like that.  I suspect this may not be a
> > "supported configuration"  yet but I was doing concurrent kernel
> > compiles to stress it out and I wanted to do a few more, only CPU cycles
> > were starting to be the limiting factor (thus NFS and another CPU seemed
> > to make sense)  It seems like something is getting confused, perhaps NFS
> > takes a short cut through the VFS layer that XFS doesn't know about or
> > something like that.
> >
> > pagebuf_get(..) is where the panic occurs, "kernel can't handle
> > NULL pointer exception"
> >
> > I looked at the pagebuf_get source and the first thing that jumped out
> > to me was that the comment says ip can can be NULL but it's never
> > checked to see if it's NULL, it's just dereferenced.  So that kind of
> > looks like a bug,  I'm not familiar enough with the code to tell what
> > the proper fix is though.   Just returning probably isn't the best
> > solution.
> > I put some printk statments  (if (ip==NULL) printk(...); ) in to try and
> > pin down where it was but they never wrote anything out, it just drops
> > into kdb.
> >
> Send the back trace.
> I'm probably chasing the same bug right now.
>
> Where was this comment about ip possibly being null.

Line 775 of fs/page_buf.c

I did an update this morning so it should be pretty close to the newest
code,
if not the newest.

page_buf_t *pagebuf_get( /* allocate a buffer            */
           struct inode * ip,  /* inode for buffer (or NULL)   */     
<----
That sounds like NULL is at least antisipated, if not an acceptable
argument.

[... here are the first few lines of the  function...]
{
 page_buf_registration_t *reg;
 int rval;
 page_buf_t *pb;

 /* Enforce alignment of pagebufs on sector boundaries */
 if ((ioff & (ip->i_sb->s_blocksize - 1))
||                                              
<-------------------this
should cause a kernel exception if NULL is passed in.
     (isize & (ip->i_sb->s_blocksize - 1))) {

  printk("Bad alignment of pagebuf offset %Ld size %d\n",
      ioff, isize);

  BUG();
      return
NULL;
<------------------- It looks like just bailing is Okay, so maybe we
just
need to check if ip is NULL also.
 }





I'll recreate the backtrace,   I don't have all the hex numbers from it
but
the function calls were
pagebuf_Get
xfs_zero_last_block
xfs_zero_eof
xfs_write
linvfs_write
nsfd_write

and that's all I recorded, it had another layer or two down to
"kernel_thread"  but I didn't think they were important since the NFS
code
and code outside it seem to work with other filesystems.

All I did to create it initially was untar a kernel onto an NFS mounted
XFS partition.  It would go about 1/3 of the way and die, I never
counted the
number of files but it looked pretty consistent.


Ian Nelson

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