From: Igor Stoppa <igor.stoppa@huawei.com>
To: Kees Cook <keescook@chromium.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
Michal Hocko <mhocko@kernel.org>,
Laura Abbott <labbott@redhat.com>,
Jerome Glisse <jglisse@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Christoph Lameter <cl@linux.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH 2/6] genalloc: selftest
Date: Tue, 20 Feb 2018 18:59:05 +0200 [thread overview]
Message-ID: <f33112e4-608f-ae8c-bf88-80ef83b61398@huawei.com> (raw)
In-Reply-To: <CAGXu5jJNERp-yni1jdqJRYJ82xrP7=_O1vkxG1sJ-b8CxudP9g@mail.gmail.com>
On 13/02/18 01:50, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa <igor.stoppa@huawei.com> wrote:
[...]
>> lib/genalloc-selftest.c | 400 ++++++++++++++++++++++++++++++++++++++
>
> Nit: make this test_genalloc.c instead.
ok
[...]
>> + genalloc_selftest();
>
> I wonder if it's possible to make this module-loadable instead? That
> way it could be built and tested separately.
In my case modules are not an option.
Of course it could be still built in, but what is the real gain?
[...]
>> +config GENERIC_ALLOCATOR_SELFTEST
>
> Like the other lib/test_*.c targets, I'd call this TEST_GENERIC_ALLOCATOR.
ok
[...]
>> + BUG_ON(compare_bitmaps(pool, action->pattern));
>
> There's been a lot recently on BUG vs WARN. It does seem crazy to not
> BUG for an allocator selftest, but if we can avoid it, we should.
If this fails, I would expect that memory corruption is almost guaranteed.
Do we really want to allow the boot to continue, possibly mounting a
filesystem, only to corrupt it? It seems very dangerous.
> Also, I wonder if it might make sense to split this series up a little
> more, as in:
>
> 1/n: add genalloc selftest
> 2/n: update bitmaps
> 3/n: add/change bitmap tests to selftest
>
> Maybe I'm over-thinking it, but the great thing about this self test
> is that it's checking much more than just the bitmap changes you're
> making, and that can be used to "prove" that genalloc continues to
> work after the changes (i.e. the selftest passes before the changes,
> and after, rather than just after).
If I really have to ... but to me the evidence that the changes to the
bitmaps do really work is already provided by the bitmap patch itself.
Since the patch doesn't remove the parameter indicating the space to be
freed, it can actually compare what the kernel passes to it vs. what it
thinks the space should be.
If the values were different, it would complain, but it doesn't ...
Isn't that even stronger evidence that the bitmap changes work as expected?
(eventually the parameter can be removed, but I intentionally left it,
for facilitating the merge)
--
igor
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-02-20 16:59 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 16:52 [RFC PATCH v16 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-12 16:52 ` [PATCH 1/6] genalloc: track beginning of allocations Igor Stoppa
2018-02-12 23:52 ` Kees Cook
2018-02-20 17:07 ` Igor Stoppa
2018-02-21 22:29 ` Kees Cook
2018-02-21 22:35 ` Jonathan Corbet
2018-02-12 16:52 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-02-12 23:50 ` Kees Cook
2018-02-20 16:59 ` Igor Stoppa [this message]
2018-02-21 22:28 ` Kees Cook
2018-02-22 9:14 ` Igor Stoppa
2018-02-22 18:28 ` Igor Stoppa
2018-02-12 16:52 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-02-12 16:52 ` [PATCH 4/6] Protectable Memory Igor Stoppa
2018-02-12 16:53 ` [PATCH 5/6] Pmalloc: self-test Igor Stoppa
2018-02-12 23:43 ` Kees Cook
2018-02-20 16:40 ` Igor Stoppa
2018-02-21 22:24 ` Kees Cook
2018-02-22 9:01 ` Igor Stoppa
2018-02-12 16:53 ` [PATCH 6/6] Documentation for Pmalloc Igor Stoppa
2018-02-12 23:32 ` [RFC PATCH v16 0/6] mm: security: ro protection for dynamic data Kees Cook
2018-02-20 1:21 ` Dave Chinner
2018-02-20 18:03 ` Igor Stoppa
2018-02-20 21:36 ` Dave Chinner
2018-02-20 23:56 ` Matthew Wilcox
2018-02-21 1:36 ` Dave Chinner
2018-02-21 9:56 ` Igor Stoppa
2018-02-21 21:36 ` Dave Chinner
2018-02-22 8:58 ` Igor Stoppa
-- strict thread matches above, loose matches on Subject: below --
2018-02-11 3:19 [RFC PATCH v15 " Igor Stoppa
2018-02-11 3:19 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-02-11 20:22 ` Philippe Ombredanne
2018-02-11 20:27 ` Randy Dunlap
2018-02-11 21:01 ` Matthew Wilcox
2018-02-04 16:47 [RFC PATCH v14 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-04 16:47 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-02-04 22:19 ` Randy Dunlap
2018-02-04 23:03 ` Matthew Wilcox
2018-02-05 0:14 ` Randy Dunlap
2018-02-09 14:30 ` Igor Stoppa
2018-02-10 22:59 ` Igor Stoppa
2018-02-07 20:25 ` kbuild test robot
2018-02-11 2:01 ` Igor Stoppa
2018-02-03 19:42 [RFC PATCH v13 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-03 19:42 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-01-30 15:14 [RFC PATCH v12 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-01-30 15:14 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-01-24 17:56 [RFC PATCH v11 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-01-24 17:56 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
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=f33112e4-608f-ae8c-bf88-80ef83b61398@huawei.com \
--to=igor.stoppa@huawei.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=hch@infradead.org \
--cc=jglisse@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=rdunlap@infradead.org \
--cc=willy@infradead.org \
/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