From: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
To: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: "jkenisto@linux.vnet.ibm.com" <jkenisto@linux.vnet.ibm.com>,
"Luck, Tony" <tony.luck@intel.com>,
"keescook@chromium.org" <keescook@chromium.org>,
"mahesh@linux.vnet.ibm.com" <mahesh@linux.vnet.ibm.com>,
"cbouatmailru@gmail.com" <cbouatmailru@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
"ccross@android.com" <ccross@android.com>
Subject: Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
Date: Wed, 04 Sep 2013 11:31:01 +0530 [thread overview]
Message-ID: <5226CC9D.30904@linux.vnet.ibm.com> (raw)
In-Reply-To: <A5ED84D3BB3A384992CBB9C77DEDA4D443E9E24D@USINDEM103.corp.hds.com>
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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
WARNING: multiple messages have this Message-ID (diff)
From: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
To: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
"jkenisto@linux.vnet.ibm.com" <jkenisto@linux.vnet.ibm.com>,
"keescook@chromium.org" <keescook@chromium.org>,
"mahesh@linux.vnet.ibm.com" <mahesh@linux.vnet.ibm.com>,
"ccross@android.com" <ccross@android.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
"cbouatmailru@gmail.com" <cbouatmailru@gmail.com>
Subject: Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
Date: Wed, 04 Sep 2013 11:31:01 +0530 [thread overview]
Message-ID: <5226CC9D.30904@linux.vnet.ibm.com> (raw)
In-Reply-To: <A5ED84D3BB3A384992CBB9C77DEDA4D443E9E24D@USINDEM103.corp.hds.com>
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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
next prev parent reply other threads:[~2013-09-04 6:01 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 13:17 [RFC PATCH v2 00/11] Add (de)compression support to pstore Aruna Balakrishnaiah
2013-08-16 13:17 ` Aruna Balakrishnaiah
2013-08-16 13:17 ` [RFC PATCH v2 01/11] powerpc/pseries: Remove (de)compression in nvram with pstore enabled Aruna Balakrishnaiah
2013-08-16 13:17 ` Aruna Balakrishnaiah
2013-08-16 13:17 ` [RFC PATCH v2 02/11] pstore: Add new argument 'compressed' in pstore write callback Aruna Balakrishnaiah
2013-08-16 13:17 ` Aruna Balakrishnaiah
2013-08-16 13:17 ` [RFC PATCH v2 03/11] pstore/Kconfig: Select ZLIB_DEFLATE and ZLIB_INFLATE when PSTORE is selected Aruna Balakrishnaiah
2013-08-16 13:17 ` Aruna Balakrishnaiah
2013-08-16 13:18 ` [RFC PATCH v2 04/11] pstore: Add compression support to pstore Aruna Balakrishnaiah
2013-08-16 13:18 ` Aruna Balakrishnaiah
2013-08-22 23:07 ` Seiji Aguchi
2013-08-22 23:07 ` Seiji Aguchi
2013-08-22 23:17 ` Luck, Tony
2013-08-22 23:17 ` Luck, Tony
2013-08-22 23:47 ` Seiji Aguchi
2013-08-22 23:47 ` Seiji Aguchi
2013-08-27 5:19 ` Aruna Balakrishnaiah
2013-08-27 5:19 ` Aruna Balakrishnaiah
2013-09-04 1:44 ` Seiji Aguchi
2013-09-04 1:44 ` Seiji Aguchi
2013-09-04 6:01 ` Aruna Balakrishnaiah [this message]
2013-09-04 6:01 ` Aruna Balakrishnaiah
2013-09-04 16:11 ` Luck, Tony
2013-09-04 16:11 ` Luck, Tony
2013-09-04 16:39 ` Seiji Aguchi
2013-09-04 16:39 ` Seiji Aguchi
2013-08-16 13:18 ` [RFC PATCH v2 05/11] pstore: Introduce new argument 'compressed' in the read callback Aruna Balakrishnaiah
2013-08-16 13:18 ` Aruna Balakrishnaiah
2013-08-16 13:18 ` [RFC PATCH v2 06/11] pstore: Add decompression support to pstore Aruna Balakrishnaiah
2013-08-16 13:18 ` Aruna Balakrishnaiah
2013-08-22 23:04 ` Seiji Aguchi
2013-08-22 23:04 ` Seiji Aguchi
2013-08-27 9:39 ` Aruna Balakrishnaiah
2013-08-27 9:39 ` Aruna Balakrishnaiah
2013-08-16 13:18 ` [RFC PATCH v2 07/11] pstore: Add file extension to pstore file if compressed Aruna Balakrishnaiah
2013-08-16 13:18 ` Aruna Balakrishnaiah
2013-08-16 13:18 ` [RFC PATCH v2 08/11] powerpc/pseries: Read and write to the 'compressed' flag of pstore Aruna Balakrishnaiah
2013-08-16 13:18 ` Aruna Balakrishnaiah
2013-08-16 13:18 ` [RFC PATCH v2 09/11] erst: " Aruna Balakrishnaiah
2013-08-16 13:18 ` Aruna Balakrishnaiah
2013-08-16 13:18 ` [RFC PATCH v2 10/11] efi-pstore: " Aruna Balakrishnaiah
2013-08-16 13:18 ` Aruna Balakrishnaiah
2013-08-16 13:19 ` [RFC PATCH v2 11/11] pstore/ram: " Aruna Balakrishnaiah
2013-08-16 13:19 ` Aruna Balakrishnaiah
2013-08-17 18:26 ` Kees Cook
2013-08-17 18:26 ` Kees Cook
2013-08-16 22:15 ` [RFC PATCH v2 00/11] Add (de)compression support to pstore Luck, Tony
2013-08-16 22:15 ` Luck, Tony
2013-08-17 18:32 ` Kees Cook
2013-08-17 18:32 ` Kees Cook
2013-08-19 17:29 ` Tony Luck
2013-08-19 17:29 ` Tony Luck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5226CC9D.30904@linux.vnet.ibm.com \
--to=aruna@linux.vnet.ibm.com \
--cc=cbouatmailru@gmail.com \
--cc=ccross@android.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mahesh@linux.vnet.ibm.com \
--cc=seiji.aguchi@hds.com \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.