AW: [PATCH][MTD-UTILS][compr_lzo.c] Fix calls to liblzo library

Carsten Schlote c.schlote at konzeptpark.de
Wed Jan 7 05:48:07 EST 2009


Hi Josh,

> > ...
> >+	lzo_compress_buf = malloc(2*page_size);
> 
> Don't leave comments in the code about why things are dangerous and
> then
> leave the code itself commented out.  A comment about why you need to
> allocate a certain size is fine, but this is pretty ugly.  For a
minute
> I thought you were doing two mallocs and ignoring the first one
because
> I didn't see the multi-line /* comment.
> 
> Did you poke around with gdb at all to determine why it segfaults?

Not yet due to lack of time problem (HW series ramp-up right now). The
comment was left to trigger questions like yours :-)  

I came across this problem, when I compiled my ptxdist projects on
Ubuntu64 at home. Suddently mkfs.jffs2 segfaulted - it always worked
fine on IA32.

So I spent some time to fix this problem, as they are:
- Wrong usage of LZO API calls for decompression. Caused -t to fail,
also
  on IA32. This is now fixed correctly by setting the destlen to the
  allowed maximum before calling the 'safe' decompression function.
- Crash on AMD64 with the currently supplied work buffer - just
increased the buffer
  until it worked again - that's a hack, but a working one.
  Possible suspects: 
    - Compiler uses different value and structure alignments on 64bit
hosts
      increasing size of structures and arrays.

I agree that it is undesireable to 'guess' workbuffer sizes. I had no
time to check and figure out, if there is an appropriate LZO API call to
derive a safe size for a workbuffer for a given algorythm and
compression parameters.

Frankly spoken, the previous formula is no solution either. The comments
says: 'Taken from their FAQs'. Beside the note, just some hardcoded
numbers are used to get some size. There is no explanation, what these
values mean or from what and where these constants are taken.

The correct solution is to query the size from the LZO library itself -
should the estimate be wrong, just fix the library and all applications
will work again.

If somebody knows how to get the correct information from LZO library -
just fix and post a patch, or tell me where to find this information and
I will fix and post a patch. 

Carsten




More information about the linux-mtd mailing list