From: Will Deacon <will@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: catalin.marinas@arm.com, vincenzo.frascino@arm.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/5] arm64: vdso: cleanups
Date: Tue, 14 Apr 2020 16:20:58 +0100 [thread overview]
Message-ID: <20200414152057.GB30288@willie-the-truck> (raw)
In-Reply-To: <20200414104252.16061-1-mark.rutland@arm.com>
On Tue, Apr 14, 2020 at 11:42:47AM +0100, Mark Rutland wrote:
> While attempting to review an arm64 vdso patch, I noticed some of the existing
> code was somewhat baroque, making it harder than necessary to understand and
> extend. These patches attempt to improve this by making the code more
> consistent and avoiding unnecessary duplication.
>
> The first patch in the series fixes a bug in a boot time error path. This bug
> was made obvious during the refactoring but I've moved it to the start so that
> it can be backported more easily.
>
> The series is based on v5.7-rc1 and can be found in my arm64/vdso-cleanup
> branch [1].
Cheers, this looks really good to me. The only thing I'm slightly confused
by is that we still have something like this in __vdso_init():
/* Allocate the vDSO pagelist, plus a page for the data. */
vdso_pagelist = kcalloc(vdso_lookup[arch_index].vdso_pages + 1,
sizeof(struct page *),
GFP_KERNEL);
But I don't see why this needs to be dynamic, and don't we leak the
allocation on failure? Not a big deal, but seems silly if we could just
have a couple of static page * arrays.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-14 15:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 10:42 [PATCH 0/5] arm64: vdso: cleanups Mark Rutland
2020-04-14 10:42 ` [PATCH 1/5] arm64: vdso: don't free unallocated pages Mark Rutland
2020-04-14 12:50 ` Vincenzo Frascino
2020-04-14 13:27 ` Mark Rutland
2020-04-14 14:53 ` Vincenzo Frascino
2020-04-14 15:10 ` Will Deacon
2020-04-15 10:08 ` Catalin Marinas
2020-04-14 15:12 ` Mark Rutland
2020-04-14 15:27 ` Vincenzo Frascino
2020-04-14 15:59 ` Catalin Marinas
2020-04-15 10:13 ` Catalin Marinas
2020-04-15 13:03 ` Mark Rutland
2020-04-14 10:42 ` [PATCH 2/5] arm64: vdso: remove aarch32_vdso_pages[] Mark Rutland
2020-04-14 10:42 ` [PATCH 3/5] arm64: vdso: simplify arch_vdso_type ifdeffery Mark Rutland
2020-04-14 10:42 ` [PATCH 4/5] arm64: vdso: use consistent 'abi' nomenclature Mark Rutland
2020-04-14 10:42 ` [PATCH 5/5] arm64: vdso: use consistent 'map' nomenclature Mark Rutland
2020-04-14 15:20 ` Will Deacon [this message]
2020-04-14 15:43 ` [PATCH 0/5] arm64: vdso: cleanups Mark Rutland
2020-04-14 15:52 ` Will Deacon
2020-04-14 16:27 ` Mark Rutland
2020-04-28 12:49 ` Will Deacon
2020-04-28 12:52 ` Mark Rutland
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=20200414152057.GB30288@willie-the-truck \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=vincenzo.frascino@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox