[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180419134647.GA9817@redhat.com>
Date: Thu, 19 Apr 2018 09:46:47 -0400
From: Mike Snitzer <snitzer@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>, NeilBrown <neilb@...e.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Kees Cook <keescook@...omium.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>,
Anton Vorontsov <anton@...msg.org>,
Colin Cross <ccross@...roid.com>, Tony Luck <tony.luck@...el.com>
Subject: Re: [patch V2 7/8] dm verity fec: Check result of init_rs()
On Thu, Apr 19 2018 at 6:04am -0400,
Thomas Gleixner <tglx@...utronix.de> wrote:
> From: Thomas Gleixner <tglx@...utronix.de>
>
> The allocation of the reed solomon control structure can fail, but
> fec_alloc_bufs() ignores that and subsequent operations in dm verity use
> the potential NULL pointer unconditionally.
>
> Add a proper check and abort if init_rs() fails.
This changelog makes little sense: init_rs() isn't in play relative to
this patch.
And it runs counter to this commit's changelog:
commit 34c96507e8f6be497c15497be05f489fb34c5880
Author: NeilBrown <neilb@...e.com>
Date: Mon Apr 10 12:13:00 2017 +1000
dm verity fec: fix GFP flags used with mempool_alloc()
mempool_alloc() cannot fail for GFP_NOIO allocation, so there is no
point testing for failure.
One place the code tested for failure was passing "0" as the GFP
flags. This is most unusual and is probably meant to be GFP_NOIO,
so that is changed.
Also, allocation from ->extra_pool and ->prealloc_pool are repeated
before releasing the previous allocation. This can deadlock if the code
is servicing a write under high memory pressure. To avoid deadlocks,
change these to use GFP_NOWAIT and leave the error handling in place.
Signed-off-by: NeilBrown <neilb@...e.com>
Signed-off-by: Mike Snitzer <snitzer@...hat.com>
Seems there is no real need for this patch. Neil, what do you think?
Thanks,
Mike
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Cc: Boris Brezillon <boris.brezillon@...e-electrons.com>
> Cc: Tony Luck <tony.luck@...el.com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Segher Boessenkool <segher@...nel.crashing.org>
> Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>
> Cc: Richard Weinberger <richard@....at>
> Cc: Mike Snitzer <snitzer@...hat.com>
> Cc: Anton Vorontsov <anton@...msg.org>
> Cc: Colin Cross <ccross@...roid.com>
> Cc: Andrew Morton <akpm@...uxfoundation.org>
> Cc: David Woodhouse <dwmw2@...radead.org>
> Cc: Alasdair Kergon <agk@...hat.com>
>
> ---
> drivers/md/dm-verity-fec.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> --- a/drivers/md/dm-verity-fec.c
> +++ b/drivers/md/dm-verity-fec.c
> @@ -308,8 +308,13 @@ static int fec_alloc_bufs(struct dm_veri
> {
> unsigned n;
>
> - if (!fio->rs)
> + if (!fio->rs) {
> fio->rs = mempool_alloc(v->fec->rs_pool, GFP_NOIO);
> + if (!fio->rs) {
> + DMERR("failed to allocate RS control structure");
> + return -ENOMEM;
> + }
> + }
>
> fec_for_each_prealloc_buffer(n) {
> if (fio->bufs[n])
>
>
>
>
>
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.
