From: Igor Stoppa <igor.stoppa@huawei.com>
To: Randy Dunlap <rdunlap@infradead.org>,
jglisse@redhat.com, keescook@chromium.org, mhocko@kernel.org,
labbott@redhat.com, hch@infradead.org, willy@infradead.org
Cc: cl@linux.com, linux-security-module@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 1/6] genalloc: track beginning of allocations
Date: Fri, 9 Feb 2018 18:18:06 +0200 [thread overview]
Message-ID: <947ea9c3-b045-17d3-51e5-df80b4fb27e6@huawei.com> (raw)
In-Reply-To: <60e66c5a-c1de-246f-4be8-b02cb0275da6@infradead.org>
On 05/02/18 00:34, Randy Dunlap wrote:
> On 02/04/2018 08:47 AM, Igor Stoppa wrote:
[...]
> It would be good for a lot of this to be in a source file or the
> pmalloc.rst documentation file instead of living only in the git repository.
This is actually about genalloc. The genalloc documentation is high
level and mostly about the API, while this talks about the guts of the
library. The part modified by the patch. This text doesn't seem to
belong to the generic genalloc documentation.
I will move it to the .c file, but isn't it too much text in a source file?
[...]
>> + * @order: pow of 2 represented by each entry in the bitmap
>
> power
ok
[...]
>> + * chunk_size - dimension of a chunk of memory
>
> can this be more explicit about which dimension?
I'll put "size in bytes of a chunk of memory"
[...]
>> + * cleart_bits_ll - according to the mask, clears the bits specified by
>
> clear_bits_ll
yes :-(
[...]
>> - * bitmap_clear_ll - clear the specified number of bits at the specified position
>> + * alter_bitmap_ll - set or clear the entries associated to an allocation
>
> with an allocation
ok
>> + * @alteration: selection if the bits selected should be set or cleared
>
> indicates if
ok
[...]
>> + /* Prepare for writing the initial part of the allocation, from
>> + * starting entry, to the end of the UL bitmap element which
>> + * contains it. It might be larger than the actual allocation.
>> + */
>
> Use kernel multi-line comment style.
ok, also for further occurrences
[...]
>> + index = BITS_DIV_LONGS(start_bit);
>
> index = BITS_DIV_LONGS
> (only 1 space after '=')
oops, yes
--
thank you, 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-09 16:18 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
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 1/6] genalloc: track beginning of allocations Igor Stoppa
2018-02-04 22:34 ` Randy Dunlap
2018-02-05 3:45 ` Matthew Wilcox
2018-02-09 14:28 ` Igor Stoppa
2018-02-09 16:18 ` Igor Stoppa [this message]
2018-02-09 17:15 ` Randy Dunlap
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-04 16:47 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-02-04 16:47 ` [PATCH 4/6] Protectable Memory Igor Stoppa
2018-02-04 22:06 ` Randy Dunlap
2018-02-11 1:04 ` Igor Stoppa
2018-02-07 10:03 ` kbuild test robot
2018-02-07 22:21 ` kbuild test robot
2018-02-04 17:00 ` [PATCH 5/6] Pmalloc: self-test Igor Stoppa
2018-02-04 17:00 ` [PATCH 6/6] Documentation for Pmalloc Igor Stoppa
2018-02-04 21:37 ` Randy Dunlap
2018-02-09 16:41 ` Igor Stoppa
2018-02-07 17:18 ` [PATCH 5/6] Pmalloc: self-test kbuild test robot
2018-02-11 1:28 ` Igor Stoppa
-- strict thread matches above, loose matches on Subject: below --
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-11 3:19 [RFC PATCH v15 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-11 3:19 ` [PATCH 1/6] genalloc: track beginning of allocations Igor Stoppa
2018-02-11 12:24 ` Mike Rapoport
2018-02-12 11:17 ` Igor Stoppa
2018-02-12 11:36 ` Mike Rapoport
2018-02-13 0:43 ` kbuild test robot
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 1/6] genalloc: track beginning of allocations 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 1/6] genalloc: track beginning of allocations 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 1/6] genalloc: track beginning of allocations 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=947ea9c3-b045-17d3-51e5-df80b4fb27e6@huawei.com \
--to=igor.stoppa@huawei.com \
--cc=cl@linux.com \
--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