[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+rckvb94YhdqUhRhuG=RtjN+S9QArAhwVWPj8mbPom+w@mail.gmail.com>
Date: Wed, 18 Apr 2018 10:03:44 -0700
From: Kees Cook <keescook@...omium.org>
To: Boris Brezillon <boris.brezillon@...tlin.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>,
Segher Boessenkool <segher@...nel.crashing.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Andrew Morton <akpm@...uxfoundation.org>,
Boris Brezillon <boris.brezillon@...e-electrons.com>, Richard Weinberger <richard@....at>,
David Woodhouse <dwmw2@...radead.org>, Alasdair Kergon <agk@...hat.com>, Mike Snitzer <snitzer@...hat.com>,
Anton Vorontsov <anton@...msg.org>, Colin Cross <ccross@...roid.com>, Tony Luck <tony.luck@...el.com>
Subject: Re: [patch 5/8] rslib: Split rs control struct
On Wed, Apr 4, 2018 at 12:40 PM, Boris Brezillon
<boris.brezillon@...tlin.com> wrote:
> Hi Thomas,
>
> On Wed, 28 Mar 2018 22:51:43 +0200
> Thomas Gleixner <tglx@...utronix.de> wrote:
>
>> The decoder library uses variable length arrays on stack. To get rid of
>> them it's it would be simple to allocate fixed length arrays on stack, but
>
> ^ s/it's//
>
>> those might become rather large. The other solution is to allocate the
>> buffers in the rs control structure, but this cannot be done as long as the
>> structure can be shared by several users. Sharing is desired because the RS
>> polynom tables are large and initialization is time consuming.
>>
>> To solve this split the codec information out of the control structure and
>> have a pointer to a shared codec in it. Instantiate the control structure
>> for each user, create a new codec if no shareable is avaiable yet. Adjust
>> all affected usage sites to the new scheme.
>>
>> This allows to add per instance decoder buffers to the control structure
>> later on.
>>
>> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>> ---
>> drivers/mtd/nand/cafe_nand.c | 7 +
>> drivers/mtd/nand/diskonchip.c | 7 +
>
> Don't know how you want to get these patches merged, but the NAND
> related changes will conflict with my nand/for-4.17 changes (NAND
> code base has been moved to drivers/mtd/nand/raw).
>
> The rest looks good,
>
> Acked-by: Boris Brezillon <boris.brezillon@...tlin.com>
Hi, just checking in on this series. Thomas, what's your plan for
merging this? I don't see it in -next yet.
-Kees
--
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.
