From: Paul Moore <paul@paul-moore.com>
To: "Christian Göttsche" <cgzones@googlemail.com>, selinux@vger.kernel.org
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>,
Eric Paris <eparis@parisplace.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/9] selinux: use u32 as bit type in ebitmap code
Date: Thu, 03 Aug 2023 22:20:17 -0400 [thread overview]
Message-ID: <c8f7b16afb26b2357fdc2b590a8cdcba.paul@paul-moore.com> (raw)
In-Reply-To: <20230728155501.39632-1-cgzones@googlemail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5227 bytes --]
On Jul 28, 2023 =?UTF-8?q?Christian=20G=C3=B6ttsche?= <cgzones@googlemail.com> wrote:
>
> The extensible bitmap supports bit positions up to U32_MAX due to the
> type of the member highbit being u32. Use u32 consistently as the type
> for bit positions to announce to callers what range of values is
> supported.
>
> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> ---
> v2: avoid declarations in init-clauses of for loops
> ---
> security/selinux/ss/ebitmap.c | 32 ++++++++++++++++----------------
> security/selinux/ss/ebitmap.h | 32 ++++++++++++++++----------------
> 2 files changed, 32 insertions(+), 32 deletions(-)
>
> diff --git a/security/selinux/ss/ebitmap.c b/security/selinux/ss/ebitmap.c
> index 77875ad355f7..6ab2baf4cfb5 100644
> --- a/security/selinux/ss/ebitmap.c
> +++ b/security/selinux/ss/ebitmap.c
> @@ -24,7 +24,7 @@
> #include "ebitmap.h"
> #include "policydb.h"
>
> -#define BITS_PER_U64 (sizeof(u64) * 8)
> +#define BITS_PER_U64 ((u32)(sizeof(u64) * 8))
>
> static struct kmem_cache *ebitmap_node_cachep __ro_after_init;
>
> @@ -82,7 +82,8 @@ int ebitmap_cpy(struct ebitmap *dst, const struct ebitmap *src)
> int ebitmap_and(struct ebitmap *dst, const struct ebitmap *e1, const struct ebitmap *e2)
> {
> struct ebitmap_node *n;
> - int bit, rc;
> + u32 bit;
> + int rc;
>
> ebitmap_init(dst);
>
> @@ -113,8 +114,7 @@ int ebitmap_netlbl_export(struct ebitmap *ebmap,
> {
> struct ebitmap_node *e_iter = ebmap->node;
> unsigned long e_map;
> - u32 offset;
> - unsigned int iter;
> + u32 offset, iter;
> int rc;
In this function 'iter' is used to iterate through ebitmap_node::maps
and it thus only indirectly related to an ebitmap spot/offset.
I don't think this change harms anything, but it isn't strictly
necessary.
> if (e_iter == NULL) {
> @@ -259,7 +259,7 @@ int ebitmap_contains(const struct ebitmap *e1, const struct ebitmap *e2, u32 las
> return 1;
> }
>
> -int ebitmap_get_bit(const struct ebitmap *e, unsigned long bit)
> +int ebitmap_get_bit(const struct ebitmap *e, u32 bit)
> {
> const struct ebitmap_node *n;
>
> @@ -276,7 +276,7 @@ int ebitmap_get_bit(const struct ebitmap *e, unsigned long bit)
> return 0;
> }
>
> -int ebitmap_set_bit(struct ebitmap *e, unsigned long bit, int value)
> +int ebitmap_set_bit(struct ebitmap *e, u32 bit, int value)
> {
> struct ebitmap_node *n, *prev, *new;
>
> @@ -287,7 +287,7 @@ int ebitmap_set_bit(struct ebitmap *e, unsigned long bit, int value)
> if (value) {
> ebitmap_node_set_bit(n, bit);
> } else {
> - unsigned int s;
> + u32 s;
>
> ebitmap_node_clr_bit(n, bit);
>
> @@ -365,12 +365,12 @@ void ebitmap_destroy(struct ebitmap *e)
> int ebitmap_read(struct ebitmap *e, void *fp)
> {
> struct ebitmap_node *n = NULL;
> - u32 mapunit, count, startbit, index;
> + u32 mapunit, count, startbit, index, i;
> __le32 ebitmap_start;
> u64 map;
> __le64 mapbits;
> __le32 buf[3];
> - int rc, i;
> + int rc;
>
> ebitmap_init(e);
>
> @@ -384,7 +384,7 @@ int ebitmap_read(struct ebitmap *e, void *fp)
>
> if (mapunit != BITS_PER_U64) {
> pr_err("SELinux: ebitmap: map size %u does not "
> - "match my size %zd (high bit was %d)\n",
> + "match my size %d (high bit was %d)\n",
> mapunit, BITS_PER_U64, e->highbit);
> goto bad;
> }
> @@ -471,18 +471,18 @@ int ebitmap_read(struct ebitmap *e, void *fp)
> int ebitmap_write(const struct ebitmap *e, void *fp)
> {
> struct ebitmap_node *n;
> - u32 count;
> + u32 bit, count, last_bit, last_startbit;
> __le32 buf[3];
> u64 map;
> - int bit, last_bit, last_startbit, rc;
> + int rc;
>
> buf[0] = cpu_to_le32(BITS_PER_U64);
>
> count = 0;
> last_bit = 0;
> - last_startbit = -1;
> + last_startbit = (u32)-1;
I can't say I'm as current on all of the C standards and compilier
oddities as some other in the Linux kernel space, but my
understanding is that on assignment the right value is always
implicitly type cast to the type of the left variable, is that not
true? Assuming it is true, I think this explicit cast isn't
necessary and could actually be harmful if we need to change the
ebitmap types in the future.
> ebitmap_for_each_positive_bit(e, n, bit) {
> - if (rounddown(bit, (int)BITS_PER_U64) > last_startbit) {
> + if (last_startbit == (u32)-1 || rounddown(bit, BITS_PER_U64) > last_startbit) {
This is a little more challenging as I know the rules for integer
comparisons are not quite as simple as assignments, but I do question
if the above change is an improvement.
One possibility would be to explicitly match the types, for example:
x == (typeof(x))-1
> count++;
> last_startbit = rounddown(bit, BITS_PER_U64);
> }
> @@ -496,9 +496,9 @@ int ebitmap_write(const struct ebitmap *e, void *fp)
> return rc;
>
> map = 0;
> - last_startbit = INT_MIN;
> + last_startbit = (u32)-1;
> ebitmap_for_each_positive_bit(e, n, bit) {
> - if (rounddown(bit, (int)BITS_PER_U64) > last_startbit) {
> + if (last_startbit == (u32)-1 || rounddown(bit, BITS_PER_U64) > last_startbit) {
> __le64 buf64[1];
Both of these changes are discussed above.
> /* this is the very first bit */
--
paul-moore.com
next prev parent reply other threads:[~2023-08-04 2:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 15:54 Christian Göttsche
2023-07-28 15:54 ` [PATCH v2 3/9] selinux: use identical iterator type in hashtab_duplicate() Christian Göttsche
2023-08-04 2:20 ` Paul Moore
2023-07-28 15:54 ` [PATCH v2 4/9] selinux: avoid implicit conversions in mls code Christian Göttsche
2023-08-04 2:20 ` Paul Moore
2023-07-28 15:54 ` [PATCH v2 5/9] selinux: services: update type for number of class permissions Christian Göttsche
2023-07-31 1:46 ` Gong Ruiqi
2023-08-04 2:20 ` Paul Moore
2023-08-04 15:21 ` David Laight
2023-07-28 15:54 ` [PATCH v2 6/9] selinux: avoid implicit conversions in services code Christian Göttsche
2023-07-31 2:01 ` Gong Ruiqi
2023-08-04 2:20 ` Paul Moore
2023-07-28 15:54 ` [PATCH v2 7/9] selinux: avoid implicit conversions in selinuxfs code Christian Göttsche
2023-08-04 2:20 ` Paul Moore
2023-07-28 15:54 ` [PATCH v2 8/9] selinux: policydb: implicit conversions Christian Göttsche
2023-08-04 2:20 ` Paul Moore
2023-07-28 15:54 ` [PATCH v2 9/9] selinux: avoid implicit conversion in nlmsgtab code Christian Göttsche
2023-08-04 2:20 ` Paul Moore
2023-07-28 15:55 ` [PATCH v2 1/9] selinux: avoid implicit conversions in avtab code Christian Göttsche
2023-08-04 2:20 ` Paul Moore
2023-08-04 2:20 ` Paul Moore [this message]
2023-08-04 15:11 ` [PATCH v2 2/9] selinux: use u32 as bit type in ebitmap code David Laight
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=c8f7b16afb26b2357fdc2b590a8cdcba.paul@paul-moore.com \
--to=paul@paul-moore.com \
--cc=cgzones@googlemail.com \
--cc=eparis@parisplace.org \
--cc=linux-kernel@vger.kernel.org \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.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
all inboxes | Powered by JetHome®