On Thu, Nov 29, 2018 at 02:06:39PM -0800, Kees Cook wrote:
> On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes
> > wrote:
> > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> > >> + workspace = kmalloc(unzipped_len +
On Thu, Nov 29, 2018 at 02:06:39PM -0800, Kees Cook wrote:
> On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> > On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes
> > wrote:
> > > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> > >> + workspace = kmalloc(unzipped_len +
On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> + workspace = kmalloc(unzipped_len + record->ecc_notice_size,
> >
> > Should tihs be unzipped_len +
On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> + workspace = kmalloc(unzipped_len + record->ecc_notice_size,
> >
> > Should tihs be unzipped_len +
On Wed, Nov 14, 2018 at 01:56:09AM -0600, Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> static void decompress_record(struct pstore_record *record)
> >> {
> >> + int ret;
> >> int
On Wed, Nov 14, 2018 at 01:56:09AM -0600, Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> static void decompress_record(struct pstore_record *record)
> >> {
> >> + int ret;
> >> int
On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
>> static void decompress_record(struct pstore_record *record)
>> {
>> + int ret;
>> int unzipped_len;
>
> nit: We could get rid of the unzipped_len variable now I think.
On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
>> static void decompress_record(struct pstore_record *record)
>> {
>> + int ret;
>> int unzipped_len;
>
> nit: We could get rid of the unzipped_len variable now I think.
On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> The pre-allocated compression buffer used for crash dumping was also
> being used for decompression. This isn't technically safe, since it's
> possible the kernel may attempt a crashdump while pstore is populating the
> pstore filesystem
On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> The pre-allocated compression buffer used for crash dumping was also
> being used for decompression. This isn't technically safe, since it's
> possible the kernel may attempt a crashdump while pstore is populating the
> pstore filesystem
The pre-allocated compression buffer used for crash dumping was also
being used for decompression. This isn't technically safe, since it's
possible the kernel may attempt a crashdump while pstore is populating the
pstore filesystem (and performing decompression). Instead, just allocate
a separate
The pre-allocated compression buffer used for crash dumping was also
being used for decompression. This isn't technically safe, since it's
possible the kernel may attempt a crashdump while pstore is populating the
pstore filesystem (and performing decompression). Instead, just allocate
a separate
12 matches
Mail list logo