2016-10-23 17:09:15

by Nicolas Iooss

[permalink] [raw]
Subject: Re: [PATCH 1/1] [media] mb86a20s: always initialize a return value

Hello,

I sent the following patch (available on
https://patchwork.kernel.org/patch/9325035/) a few weeks ago and got no
feedback even though the bug it fixes seems to still exist in
linux-next. Did I do something wrong? Should I consider this patch to be
rejected?

Thanks,
Nicolas

On 10/09/16 18:49, Nicolas Iooss wrote:
> In mb86a20s_read_status_and_stats(), when mb86a20s_read_status() fails,
> the function returns the value in variable rc without initializing it
> first. Fix this by propagating the error code from variable status_nr.
>
> This bug has been found using clang and -Wsometimes-uninitialized
> warning flag.
>
> Signed-off-by: Nicolas Iooss <[email protected]>
> ---
> drivers/media/dvb-frontends/mb86a20s.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
> index 41325328a22e..eca07432645e 100644
> --- a/drivers/media/dvb-frontends/mb86a20s.c
> +++ b/drivers/media/dvb-frontends/mb86a20s.c
> @@ -1971,6 +1971,7 @@ static int mb86a20s_read_status_and_stats(struct dvb_frontend *fe,
> if (status_nr < 0) {
> dev_err(&state->i2c->dev,
> "%s: Can't read frontend lock status\n", __func__);
> + rc = status_nr;
> goto error;
> }
>
>


2016-10-23 20:06:05

by Andrey Utkin

[permalink] [raw]
Subject: Re: [PATCH 1/1] [media] mb86a20s: always initialize a return value

On Sun, Oct 23, 2016 at 07:09:10PM +0200, Nicolas Iooss wrote:
> Hello,
>
> I sent the following patch (available on
> https://patchwork.kernel.org/patch/9325035/) a few weeks ago and got no
> feedback even though the bug it fixes seems to still exist in
> linux-next. Did I do something wrong? Should I consider this patch to be
> rejected?

No, it's extremely unlikely that bug fixing patches get silently
rejected by being ignored. Most probably the time of your submission is
unfortunate, being at the time when submissions are not merged.
I am in same situation with a couple of patches. I asked Mauro yesterday
on IRC and he replied:

I don't handle submissions during 3 weeks, during the merge window
one week before, and the two weeks after that
except when it is a bug that would affect the merge window
(end of quote)

So unless you make it clear about which "release branches" are affected,
your submission is to be delayed - possibly up to 6 weeks or so.

I was suggested to add tags Fixes: buggy-commit-id and
Cc: [email protected]