lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 04 Sep 2013 11:31:01 +0530
From:	Aruna Balakrishnaiah <aruna@...ux.vnet.ibm.com>
To:	Seiji Aguchi <seiji.aguchi@....com>
CC:	"Luck, Tony" <tony.luck@...el.com>,
	"jkenisto@...ux.vnet.ibm.com" <jkenisto@...ux.vnet.ibm.com>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"mahesh@...ux.vnet.ibm.com" <mahesh@...ux.vnet.ibm.com>,
	"ccross@...roid.com" <ccross@...roid.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linuxppc-dev@...abs.org" <linuxppc-dev@...abs.org>,
	"cbouatmailru@...il.com" <cbouatmailru@...il.com>
Subject: Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore

On Wednesday 04 September 2013 07:14 AM, Seiji Aguchi wrote:
> Aruna,
>
> Sorry for the late response.
>
>> Seiji,
>>
>> Could you let us know the efivars buffer size with which the pstore is
>> registered when
>> the failure occurred.
> I looked into the issue today.
>
> I added some debug message just before pstore_compress().
> As you can see below, the buffer size is a fixed value(1024).
> Therefore, the size doesn't seem to be related to the failure directly.
>
> Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out is zero.
> So, I thought big_oops_buf_sz is too big in my environment.
> And then, I tuned  big_oops_buf_sz to (psinfo->bufsize * 100) / 53.
Seiji,

Thank you for the analysis.

The reason behind compression failure is the size of big_oops_buf which is too
big for efivars case. I will do some experiments with different kind of texts
for buffer size 1024 to check if 100/53 suits for all the cases.

>
> At the same time, while looking into this issue, I had two concerns about current cording.
>
> 1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_inflateInit()?
>       If you use zlib_deflateInit2()  for specifying window_bit at compressing time,
>       zlib_inflateInit2() seems to be appropriate for decompressing.
>       (Please see a comment about inflateInit2() in include/linux/zlib.h and source code of crypto/deflate.c)

Yes this can be changed to zlib_inflateInit2().

> 2) As looking at crypto/deflate.c, stream->workspace is kzalloced at the beginning of
>     compressing/decompressing time.
>      So, in pstore case,  stream.workspace must be initialized to 0 with memset() in pstore_compress()/decompress().

Hmm.. I don't think this is a issue. If you see fs/logfs/compr.c from which I 
derived the compression
algorithms for pstore as well, they have not initialized stream.workspace. Since 
the space will be overwritten
during the calculation, I dont think it will matter.

The above 2 things you have suggested are good to have. But the reason behind 
compression failure is
the big_oops_buf_sz which is too big for efivars.

> I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2() and initializing stream.workspace , in my environment.
> As a result, compressions/decmpressions of all entries succeeded with efivars driver.
>
> <snip>
> Panic#2 Part1
> <4>[   75.665020]  [<ffffffff811af59c>] SyS_write+0x4c/0xa0
> <4>[   75.665020]  [<ffffffff8168be82>] system_call_fastpath+0x16/0x1b
> <4>[   75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e
> <1>[   75.665020] RIP  [<ffffffff813d3946>] sysrq_handle_crash+0x16/0x20
> <4>[   75.665020]  RSP <ffff88007852de80>
> <4>[   75.665020] CR2: 0000000000000000
> <4>[   75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]---
> <3>[   75.665020] pstore_dump hsize=13 len=2155 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=13 len=2246 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore: compression failed for Part 2 returned -5
> <3>[   75.665020] pstore: Capture uncompressed oops/panic report of Part 2
> <3>[   75.665020] pstore_dump hsize=13 len=2239 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=13 len=2231 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=13 len=2185 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore: compression failed for Part 5 returned -5
> <3>[   75.665020] pstore: Capture uncompressed oops/panic report of Part 5
> <3>[   75.665020] pstore_dump hsize=13 len=2234 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=13 len=2208 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=13 len=2218 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=13 len=2222 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore: compression failed for Part 9 returned -5
> <3>[   75.665020] pstore: Capture uncompressed oops/panic report of Part 9
> <3>[   75.665020] pstore_dump hsize=14 len=2256 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=14 len=2219 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <3>[   75.665020] pstore_dump hsize=14 len=2226 big_oops_buf_sz=2275 psinfo->bufsize=1024
> <0>[   75.665020] Kernel panic - not syncing: Fatal exception
> <3>[   75.665020] drm_kms_helper: panic occurred, switching back to text console
> <snip>
>
> Seiji
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@...ts.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists