Re: [GIT PULL] Squashfs fixes for 2.6.29?

[Woody Suwalski]

Geert Uytterhoeven wrote:
> On Tue, 10 Mar 2009, Phillip Lougher wrote:
>   
> > Stefan Lippers-Hollmann wrote:
> >     
> > > This patch seems to break squashfs for me on i386 and amd64. 
> > > Test environment is a squashed filesystem image (live CD image, but also
> > > tested manually with a loop mounted iso9660 and loop mounted squashfs;
> > > kernel 2.6.29-rc7-git2). The squashfs image has been created with
> > > squashfs-tools CVS[1] as of today (latest commit 2009-03-03).
> > >
> > >       
> > Can you send me a filesystem (or link to one) which exhibits this?  Zlib is
> > obviously showing unexpected behaviour...
> >     
>
> I see the same thing here. I'll send you a test file system by private email.
>
> The patch below fixes it. It seems zlib sometimes does need an additional
> loop ;-)
>
> Note that I expect it may now loop forever in case of file system corruption.
>
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
>
> diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
> index 321728f..46358dd 100644
> --- a/fs/squashfs/block.c
> +++ b/fs/squashfs/block.c
> @@ -184,15 +184,7 @@ int squashfs_read_data(struct super_block *sb, void **buffer, u64 index,
>  				offset = 0;
>  			}
>  
> -			if (msblk->stream.avail_out == 0) {
> -				if (page == pages) {
> -					ERROR("zlib_inflate tried to "
> -						"decompress too much data, "
> -						"expected %d bytes.  Zlib "
> -						"data probably corrupt\n",
> -						srclength);
> -					goto release_mutex;
> -				}
> +			if (msblk->stream.avail_out == 0 && page < pages) {
>  				msblk->stream.next_out = buffer[page++];
>  				msblk->stream.avail_out = PAGE_CACHE_SIZE;
>  			}
>
> With kind regards,
>
> Geert Uytterhoeven
> Software Architect
>
>   
Same here. I have experimentally commented out the "goto release_mutex" 
and I see that the error message is printed once or twice during boot.
(and we are banging on it heavily - no real file system problems seen).
In my case squash4 is a 600M+ all the system partition to be aufs'd with 
a read-write portion.
Leaving the patch as it is renders the system unbootable - weird errors 
resulting from aborted reads....

Woody

--
Woody Suwalski, Xandros, Ottawa, Canada, 1-613-842-3498 x414

--
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/