All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap
@ 2020-12-28 19:43 Yury Norov
  2020-12-28 19:50 ` Andy Shevchenko
  0 siblings, 1 reply; 7+ messages in thread
From: Yury Norov @ 2020-12-28 19:43 UTC (permalink / raw)
  To: Carsten Haitzler, Liviu Dudau, linux-kernel
  Cc: Yury Norov, Andrew Morton, Andy Shevchenko, Rasmus Villemoes

The commit be3e477effba636ad25 ("drm/komeda: Fix bit
check to import to value of proper type") fixes possible
out-of-bound issue related to find_first_bit() usage, but
does not address the endianness problem.

We can use bitmap_from_arr32() here.

Since I have no hardware, the patch is compile-testes only.
Carsten, could you please test it and consider including into
your tree?

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 719a79728e24..27968215e41d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -136,11 +136,12 @@ struct komeda_component *
 komeda_pipeline_get_first_component(struct komeda_pipeline *pipe,
 				    u32 comp_mask)
 {
+	DECLARE_BITMAP(comp_mask_local, 32);
 	struct komeda_component *c = NULL;
-	unsigned long comp_mask_local = (unsigned long)comp_mask;
 	int id;
 
-	id = find_first_bit(&comp_mask_local, 32);
+	bitmap_from_arr32(comp_mask_local, &comp_mask, 32);
+	id = find_first_bit(comp_mask_local, 32);
 	if (id < 32)
 		c = komeda_pipeline_get_component(pipe, id);
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap
  2020-12-28 19:43 [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap Yury Norov
@ 2020-12-28 19:50 ` Andy Shevchenko
  2020-12-28 20:10   ` Yury Norov
  0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2020-12-28 19:50 UTC (permalink / raw)
  To: Yury Norov
  Cc: Carsten Haitzler, Liviu Dudau, linux-kernel, Andrew Morton,
	Rasmus Villemoes

On Mon, Dec 28, 2020 at 11:43:43AM -0800, Yury Norov wrote:
> The commit be3e477effba636ad25 ("drm/komeda: Fix bit
> check to import to value of proper type") fixes possible
> out-of-bound issue related to find_first_bit() usage, but
> does not address the endianness problem.

Hmm... Can you elaborate?

...

>  				    u32 comp_mask)

> -	unsigned long comp_mask_local = (unsigned long)comp_mask;

Here we convert u32 to unsigned long (LSB is kept LSB since it happens in
native endianess).

> -	id = find_first_bit(&comp_mask_local, 32);

Here it takes an address to unsigned long and tries only lower 32 bits.

Are you telling that find_first_bit() has an issue?

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap
  2020-12-28 19:50 ` Andy Shevchenko
@ 2020-12-28 20:10   ` Yury Norov
  2020-12-29 12:22     ` Carsten Haitzler
  0 siblings, 1 reply; 7+ messages in thread
From: Yury Norov @ 2020-12-28 20:10 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Carsten Haitzler, Liviu Dudau, Linux Kernel Mailing List,
	Andrew Morton, Rasmus Villemoes

On Mon, Dec 28, 2020 at 11:49 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Dec 28, 2020 at 11:43:43AM -0800, Yury Norov wrote:
> > The commit be3e477effba636ad25 ("drm/komeda: Fix bit
> > check to import to value of proper type") fixes possible
> > out-of-bound issue related to find_first_bit() usage, but
> > does not address the endianness problem.
>
> Hmm... Can you elaborate?
>
> ...
>
> >                                   u32 comp_mask)
>
> > -     unsigned long comp_mask_local = (unsigned long)comp_mask;
>
> Here we convert u32 to unsigned long (LSB is kept LSB since it happens in
> native endianess).
>
> > -     id = find_first_bit(&comp_mask_local, 32);
>
> Here it takes an address to unsigned long and tries only lower 32 bits.
>
> Are you telling that find_first_bit() has an issue?

It seems you're right, there's no issue with endianness in existing code.
In fact, the line

> > -     unsigned long comp_mask_local = (unsigned long)comp_mask;

is an opencoded version of bitmap_from_arr32(dst, src, 32).

Maybe it would be better to use the bitmap API here, but existing code is
correct. Sorry for the noise.

Yury

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap
  2020-12-28 20:10   ` Yury Norov
@ 2020-12-29 12:22     ` Carsten Haitzler
  2020-12-29 13:50       ` Andy Shevchenko
  0 siblings, 1 reply; 7+ messages in thread
From: Carsten Haitzler @ 2020-12-29 12:22 UTC (permalink / raw)
  To: Yury Norov, Andy Shevchenko
  Cc: Liviu Dudau, Linux Kernel Mailing List, Andrew Morton, Rasmus Villemoes

On 12/28/20 8:10 PM, Yury Norov wrote:
> On Mon, Dec 28, 2020 at 11:49 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>> On Mon, Dec 28, 2020 at 11:43:43AM -0800, Yury Norov wrote:
>>> The commit be3e477effba636ad25 ("drm/komeda: Fix bit
>>> check to import to value of proper type") fixes possible
>>> out-of-bound issue related to find_first_bit() usage, but
>>> does not address the endianness problem.
>> Hmm... Can you elaborate?
>>
>> ...
>>
>>>                                    u32 comp_mask)
>>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
>> Here we convert u32 to unsigned long (LSB is kept LSB since it happens in
>> native endianess).
>>
>>> -     id = find_first_bit(&comp_mask_local, 32);
>> Here it takes an address to unsigned long and tries only lower 32 bits.
>>
>> Are you telling that find_first_bit() has an issue?
> It seems you're right, there's no issue with endianness in existing code.
> In fact, the line

Indeed Andy covered this. Take LSB32 with the cast to "local on-stack
long" and possible extend upper 32bits with 0's if needed (64bit longs).

>>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> is an opencoded version of bitmap_from_arr32(dst, src, 32).
>
> Maybe it would be better to use the bitmap API here, but existing code is
> correct. Sorry for the noise.
While your code is seemingly also valid (I can check to be sure with
KASAN if you want still), it does seem a little less "nice to read" with
more lines of code for the same work. Is it worth making the code a
little longer here as it's not actually fixing anything to do it this
other way? DECLARE_BITMAP() is a bit of an obscure way to declare a
single unsigned long (in this case) where the compiler does the right
thing anyway with a simple assign+cast making it easier to read/follow IMHO.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap
  2020-12-29 12:22     ` Carsten Haitzler
@ 2020-12-29 13:50       ` Andy Shevchenko
  2020-12-29 18:09         ` Yury Norov
  0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2020-12-29 13:50 UTC (permalink / raw)
  To: Carsten Haitzler
  Cc: Yury Norov, Andy Shevchenko, Liviu Dudau,
	Linux Kernel Mailing List, Andrew Morton, Rasmus Villemoes

On Tue, Dec 29, 2020 at 2:24 PM Carsten Haitzler
<Carsten.Haitzler@arm.com> wrote:
>
> On 12/28/20 8:10 PM, Yury Norov wrote:
> > On Mon, Dec 28, 2020 at 11:49 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> >> On Mon, Dec 28, 2020 at 11:43:43AM -0800, Yury Norov wrote:
> >>> The commit be3e477effba636ad25 ("drm/komeda: Fix bit
> >>> check to import to value of proper type") fixes possible
> >>> out-of-bound issue related to find_first_bit() usage, but
> >>> does not address the endianness problem.
> >> Hmm... Can you elaborate?
> >>
> >> ...
> >>
> >>>                                    u32 comp_mask)
> >>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> >> Here we convert u32 to unsigned long (LSB is kept LSB since it happens in
> >> native endianess).
> >>
> >>> -     id = find_first_bit(&comp_mask_local, 32);
> >> Here it takes an address to unsigned long and tries only lower 32 bits.
> >>
> >> Are you telling that find_first_bit() has an issue?
> > It seems you're right, there's no issue with endianness in existing code.
> > In fact, the line
>
> Indeed Andy covered this. Take LSB32 with the cast to "local on-stack
> long" and possible extend upper 32bits with 0's if needed (64bit longs).
>
> >>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> > is an opencoded version of bitmap_from_arr32(dst, src, 32).
> >
> > Maybe it would be better to use the bitmap API here, but existing code is
> > correct. Sorry for the noise.
> While your code is seemingly also valid (I can check to be sure with
> KASAN if you want still), it does seem a little less "nice to read" with
> more lines of code for the same work. Is it worth making the code a
> little longer here as it's not actually fixing anything to do it this
> other way? DECLARE_BITMAP() is a bit of an obscure way to declare a
> single unsigned long (in this case) where the compiler does the right
> thing anyway with a simple assign+cast making it easier to read/follow IMHO.

What we can do is to declare BITS_PER_U32.
Also we can pay attention on these definitions:
https://elixir.bootlin.com/linux/latest/source/kernel/bpf/btf.c#L168
https://elixir.bootlin.com/linux/latest/source/security/selinux/ss/ebitmap.c#L27

And define BITMAP_FROM_U32() macro.

Then It would be written like

DECLARE_BITMAP(comp_mask_local, BITS_PER_U32) = BITMAP_FROM_U32(comp_mask);

But this is a bit verbose.

Also, it can be something like DECLARE_BITMAP_U32(...) = BITMAP_FROM_U32(...);

> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hmm... you probably have to get rid of this footer.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap
  2020-12-29 13:50       ` Andy Shevchenko
@ 2020-12-29 18:09         ` Yury Norov
  2020-12-29 18:27           ` Yury Norov
  0 siblings, 1 reply; 7+ messages in thread
From: Yury Norov @ 2020-12-29 18:09 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Carsten Haitzler, Andy Shevchenko, Liviu Dudau,
	Linux Kernel Mailing List, Andrew Morton, Rasmus Villemoes

On Tue, Dec 29, 2020 at 5:50 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Tue, Dec 29, 2020 at 2:24 PM Carsten Haitzler
> <Carsten.Haitzler@arm.com> wrote:
> >
> > On 12/28/20 8:10 PM, Yury Norov wrote:
> > > On Mon, Dec 28, 2020 at 11:49 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > >> On Mon, Dec 28, 2020 at 11:43:43AM -0800, Yury Norov wrote:
> > >>> The commit be3e477effba636ad25 ("drm/komeda: Fix bit
> > >>> check to import to value of proper type") fixes possible
> > >>> out-of-bound issue related to find_first_bit() usage, but
> > >>> does not address the endianness problem.
> > >> Hmm... Can you elaborate?
> > >>
> > >> ...
> > >>
> > >>>                                    u32 comp_mask)
> > >>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> > >> Here we convert u32 to unsigned long (LSB is kept LSB since it happens in
> > >> native endianess).
> > >>
> > >>> -     id = find_first_bit(&comp_mask_local, 32);
> > >> Here it takes an address to unsigned long and tries only lower 32 bits.
> > >>
> > >> Are you telling that find_first_bit() has an issue?
> > > It seems you're right, there's no issue with endianness in existing code.
> > > In fact, the line
> >
> > Indeed Andy covered this. Take LSB32 with the cast to "local on-stack
> > long" and possible extend upper 32bits with 0's if needed (64bit longs).
> >
> > >>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> > > is an opencoded version of bitmap_from_arr32(dst, src, 32).
> > >
> > > Maybe it would be better to use the bitmap API here, but existing code is
> > > correct. Sorry for the noise.
> > While your code is seemingly also valid (I can check to be sure with
> > KASAN if you want still), it does seem a little less "nice to read" with
> > more lines of code for the same work. Is it worth making the code a
> > little longer here as it's not actually fixing anything to do it this
> > other way? DECLARE_BITMAP() is a bit of an obscure way to declare a
> > single unsigned long (in this case) where the compiler does the right
> > thing anyway with a simple assign+cast making it easier to read/follow IMHO.
>
> What we can do is to declare BITS_PER_U32.
> Also we can pay attention on these definitions:
> https://elixir.bootlin.com/linux/latest/source/kernel/bpf/btf.c#L168
> https://elixir.bootlin.com/linux/latest/source/security/selinux/ss/ebitmap.c#L27


> And define BITMAP_FROM_U32() macro.
>
> Then It would be written like
>
> DECLARE_BITMAP(comp_mask_local, BITS_PER_U32) = BITMAP_FROM_U32(comp_mask);
>
> But this is a bit verbose.
>
> Also, it can be something like DECLARE_BITMAP_U32(...) = BITMAP_FROM_U32(...);
>
> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> Hmm... you probably have to get rid of this footer.
>
> --
> With Best Regards,
> Andy Shevchenko

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap
  2020-12-29 18:09         ` Yury Norov
@ 2020-12-29 18:27           ` Yury Norov
  0 siblings, 0 replies; 7+ messages in thread
From: Yury Norov @ 2020-12-29 18:27 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Carsten Haitzler, Andy Shevchenko, Liviu Dudau,
	Linux Kernel Mailing List, Andrew Morton, Rasmus Villemoes

On Tue, Dec 29, 2020 at 10:09 AM Yury Norov <yury.norov@gmail.com> wrote:
>
> On Tue, Dec 29, 2020 at 5:50 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> >
> > On Tue, Dec 29, 2020 at 2:24 PM Carsten Haitzler
> > <Carsten.Haitzler@arm.com> wrote:
> > >
> > > On 12/28/20 8:10 PM, Yury Norov wrote:
> > > > On Mon, Dec 28, 2020 at 11:49 AM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >> On Mon, Dec 28, 2020 at 11:43:43AM -0800, Yury Norov wrote:
> > > >>> The commit be3e477effba636ad25 ("drm/komeda: Fix bit
> > > >>> check to import to value of proper type") fixes possible
> > > >>> out-of-bound issue related to find_first_bit() usage, but
> > > >>> does not address the endianness problem.
> > > >> Hmm... Can you elaborate?
> > > >>
> > > >> ...
> > > >>
> > > >>>                                    u32 comp_mask)
> > > >>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> > > >> Here we convert u32 to unsigned long (LSB is kept LSB since it happens in
> > > >> native endianess).
> > > >>
> > > >>> -     id = find_first_bit(&comp_mask_local, 32);
> > > >> Here it takes an address to unsigned long and tries only lower 32 bits.
> > > >>
> > > >> Are you telling that find_first_bit() has an issue?
> > > > It seems you're right, there's no issue with endianness in existing code.
> > > > In fact, the line
> > >
> > > Indeed Andy covered this. Take LSB32 with the cast to "local on-stack
> > > long" and possible extend upper 32bits with 0's if needed (64bit longs).
> > >
> > > >>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> > > > is an opencoded version of bitmap_from_arr32(dst, src, 32).
> > > >
> > > > Maybe it would be better to use the bitmap API here, but existing code is
> > > > correct. Sorry for the noise.
> > > While your code is seemingly also valid (I can check to be sure with
> > > KASAN if you want still), it does seem a little less "nice to read" with
> > > more lines of code for the same work. Is it worth making the code a
> > > little longer here as it's not actually fixing anything to do it this
> > > other way? DECLARE_BITMAP() is a bit of an obscure way to declare a
> > > single unsigned long (in this case) where the compiler does the right
> > > thing anyway with a simple assign+cast making it easier to read/follow IMHO.
> >
> > What we can do is to declare BITS_PER_U32.
> > Also we can pay attention on these definitions:
> > https://elixir.bootlin.com/linux/latest/source/kernel/bpf/btf.c#L168
> > https://elixir.bootlin.com/linux/latest/source/security/selinux/ss/ebitmap.c#L27

On the other hand, fixed width types are designed especially to
contain a specific
number of bits. I don't understand why BITS_PER_U32 is any better than
just 32 ...

> > And define BITMAP_FROM_U32() macro.
> >
> > Then It would be written like
> >
> > DECLARE_BITMAP(comp_mask_local, BITS_PER_U32) = BITMAP_FROM_U32(comp_mask);
> >
> > But this is a bit verbose.
> >
> > Also, it can be something like DECLARE_BITMAP_U32(...) = BITMAP_FROM_U32(...);

People often do things like this:
https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/pcie-hisi-error.c#L199

Maybe it's worth adding a shorthand for it, like CREATE_BITMAP32(name, val) and
CREATE_BITMAP64(name, val)?

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-12-29 18:28 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-28 19:43 [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap Yury Norov
2020-12-28 19:50 ` Andy Shevchenko
2020-12-28 20:10   ` Yury Norov
2020-12-29 12:22     ` Carsten Haitzler
2020-12-29 13:50       ` Andy Shevchenko
2020-12-29 18:09         ` Yury Norov
2020-12-29 18:27           ` Yury Norov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.