Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Mar 2018 14:14:25 -0700
From: Kees Cook <>
To: Thomas Gleixner <>
Cc: LKML <>, 
	Segher Boessenkool <>, 
	Kernel Hardening <>, 
	Andrew Morton <>, 
	Boris Brezillon <>, Richard Weinberger <>, 
	David Woodhouse <>, Alasdair Kergon <>, Mike Snitzer <>, 
	Anton Vorontsov <>, Colin Cross <>, Tony Luck <>
Subject: Re: [patch 8/8] rslib: Allocate decoder buffers to avoid VLAs

On Wed, Mar 28, 2018 at 1:51 PM, Thomas Gleixner <> wrote:
> To get rid of the variable length arrays on stack in the RS decoder it's
> necessary to allocate the decoder buffers per control structure instance.
> All usage sites have been checked for potential parallel decoder usage and
> fixed where necessary. Kees confirmed that the pstore decoding is strictly
> single threaded so there should be no surprises.

For posterity: pstore ecc decode happens during probe and during read.
The read (pstore_get_backend_records()) has an explicit read_mutex.

I was pondering, though, since we have a common control structure now,
maybe we should just add a spinlock too to avoid future surprises?

> Allocate them in the rs control structure sized depending on the number of
> roots for the chosen codec and adapt the decoder code to make use of them.
> Document the fact that decode operations based on a particular rs control
> instance cannot run in parallel and the caller has to ensure that as it's
> not possible to provide a proper locking construct which fits all use
> cases.
> Signed-off-by: Thomas Gleixner <>


Acked-by: Kees Cook <>

Thanks for doing this!


Kees Cook
Pixel Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.