[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220721104731.GK2316@kadam>
Date: Thu, 21 Jul 2022 13:47:31 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: alsa-devel@...a-project.org,
Banajit Goswami <bgoswami@...eaurora.org>,
Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Banajit Goswami <bgoswami@...cinc.com>
Subject: Re: [PATCH] ASoC: qcom: q6dsp: Fix an off-by-one in
q6adm_alloc_copp()
On Thu, Jul 21, 2022 at 12:30:32PM +0200, Christophe JAILLET wrote:
> You could add find_last_bit(), find_next_zero_bit_le() and
> find_next_bit_le().
>
Thanks!
> >
> > regards,
> > dan carpenter
> >
> >
>
> A reduced version of mine was:
>
> @@
> expression e1, e2;
> statement S;
> @@
> (
> * e1 = find_first_bit(...);
> |
> * e1 = find_last_bit(...);
> |
> [... snip ...]
> )
> ...
> if (e1 > e2)
> S
>
>
> (and it takes only a few seconds to scan the whole kernel :) )
Nice!
I wasn't going to be before but now I have to re-write my generic
check to be even more *powerful* than before! The new check doesn't
rely on known values for the limit, but uses comparison data instead.
(Still takes overnight to run so I might end up sorely dissappointed
and defeated tomorrow morning)
regards,
dan carpenter
View attachment "check_off_by_one_capped_return.c" of type "text/x-csrc" (1529 bytes)
Powered by blists - more mailing lists