Re: 2.6.6 is crashing repeatedly

[Neil Brown]

On Wednesday May 19, akpm@xxxxxxxx wrote:
> linux@xxxxxxxxxxx wrote:
> >
> > I already reported (I thought) this message:
> > 
> >  May 19 02:23:47: Unable to handle kernel paging request at virtual address efd78000

> >  May 19 02:23:47: EIP is at encode_entry+0x4b/0x530
> >  May 19 02:23:47: eax: 00000000   ebx: 00000000   ecx: 00000644   edx: f3532df8
> >  May 19 02:23:47: esi: efd78000   edi: e4a19644   ebp: 00000654   esp: f14b7b98

> >  May 19 02:23:47: 
> >  May 19 02:23:47: Code: 89 06 89 c8 0f c8 89 46 04 81 7c 24 1c 00 01 00 00 b8 ff 00 
> 

cd->offset is 0xefd78000, which is the start of a, presumably unused, page.

Yes... this patch should fix it.

Thanks for the report.

NeilBrown

===============================================================
Fix NFSD oops in readdir.

If a single readdir entry needs to be split over two pages in
the reply, we first encode it into a new page, and then copy the
bits into place.  When we do this relocation, we have to modify
the "offset" pointer to be either in the first or the second page,
as appropriate.

If the pointer should be at the start of the second page, it is currently
put past the end of the first page.

Note that as the offset and whole response is known to be 4byte-aligned,
the offset pointer will never be split over two pages.


 ----------- Diffstat output ------------
 ./fs/nfsd/nfs3xdr.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff ./fs/nfsd/nfs3xdr.c~current~ ./fs/nfsd/nfs3xdr.c
--- ./fs/nfsd/nfs3xdr.c~current~	2004-05-20 15:10:15.000000000 +1000
+++ ./fs/nfsd/nfs3xdr.c	2004-05-20 15:22:23.000000000 +1000
@@ -936,7 +936,7 @@ encode_entry(struct readdir_cd *ccd, con
 			memmove(tmp, (caddr_t)tmp+len1, len2);
 
 			/* update offset */
-			if (((cd->offset - tmp) << 2) <= len1)
+			if (((cd->offset - tmp) << 2) < len1)
 				cd->offset = p + (cd->offset - tmp);
 			else
 				cd->offset -= len1 >> 2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/