All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Brian Norris <computersforpeace@gmail.com>
Cc: kernel-janitors@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 0/5] UBI: Coverity-inspired fixes
Date: Thu, 26 Mar 2015 09:11:37 +0000	[thread overview]
Message-ID: <5513CD49.30803@nod.at> (raw)
In-Reply-To: <20150306020442.GP18140@ld-irv-0074>

Am 06.03.2015 um 03:04 schrieb Brian Norris:
> On Thu, Mar 05, 2015 at 11:33:14AM +0100, Richard Weinberger wrote:
>> Brian,
>>
>> Am 28.02.2015 um 11:23 schrieb Brian Norris:
>>> Except for the last one, these were inspired by Coverity Scan results.
>>>
>>> These fixes have barely been tested, but they are pretty straightforward
>>> logically. As they've been sitting in my dust pile too long, I thought I'd at
>>> least get them out there.
>>>
>>> Brian Norris (5):
>>>   UBI: account for bitflips in both the VID header and data
>>>   UBI: fix out of bounds write
>>>   UBI: initialize LEB number variable
>>>   UBI: fix check for "too many bytes"
>>>   UBI: align comment for readability
>>
>> Nice work!
>> I'll test them later today.
>> Just a quick question, no patch has a stable tag, is this by design?
>> From a first look most of them look like stable material.
> 
> Two reasons:
> 
>  1. I hadn't tested them heavily, and I definitely didn't try to target
>  their codepaths much.
> 
>  2. Given #1 and the fact that these were just found by static analysis,
>  I don't think they pass this test from
>  Documentation/stable_kernel_rules.txt:
> 
>  " - It must fix a real bug that bothers people (not a, "This could be a
>     problem..." type thing)."
> 
> So, I expected they would only be sent to stable if somebody (perhaps
> me) is able to trigger something real, or at least gets some significant
> testing on them.
> 
> Maybe this is a case where you send the fixes, and then send the commit
> IDs to Greg after they have been proven stable and/or can be exploited
> in some way through testing. (Option 2 in the updated
> stable_kernel_rules.txt.)
> 
> But really, it's your/Artem's call.

Applied, thanks a lot Brian!
I've marked patches 1 to 4 as stable material.

Thanks,
//richard

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Brian Norris <computersforpeace@gmail.com>
Cc: kernel-janitors@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 0/5] UBI: Coverity-inspired fixes
Date: Thu, 26 Mar 2015 10:11:37 +0100	[thread overview]
Message-ID: <5513CD49.30803@nod.at> (raw)
In-Reply-To: <20150306020442.GP18140@ld-irv-0074>

Am 06.03.2015 um 03:04 schrieb Brian Norris:
> On Thu, Mar 05, 2015 at 11:33:14AM +0100, Richard Weinberger wrote:
>> Brian,
>>
>> Am 28.02.2015 um 11:23 schrieb Brian Norris:
>>> Except for the last one, these were inspired by Coverity Scan results.
>>>
>>> These fixes have barely been tested, but they are pretty straightforward
>>> logically. As they've been sitting in my dust pile too long, I thought I'd at
>>> least get them out there.
>>>
>>> Brian Norris (5):
>>>   UBI: account for bitflips in both the VID header and data
>>>   UBI: fix out of bounds write
>>>   UBI: initialize LEB number variable
>>>   UBI: fix check for "too many bytes"
>>>   UBI: align comment for readability
>>
>> Nice work!
>> I'll test them later today.
>> Just a quick question, no patch has a stable tag, is this by design?
>> From a first look most of them look like stable material.
> 
> Two reasons:
> 
>  1. I hadn't tested them heavily, and I definitely didn't try to target
>  their codepaths much.
> 
>  2. Given #1 and the fact that these were just found by static analysis,
>  I don't think they pass this test from
>  Documentation/stable_kernel_rules.txt:
> 
>  " - It must fix a real bug that bothers people (not a, "This could be a
>     problem..." type thing)."
> 
> So, I expected they would only be sent to stable if somebody (perhaps
> me) is able to trigger something real, or at least gets some significant
> testing on them.
> 
> Maybe this is a case where you send the fixes, and then send the commit
> IDs to Greg after they have been proven stable and/or can be exploited
> in some way through testing. (Option 2 in the updated
> stable_kernel_rules.txt.)
> 
> But really, it's your/Artem's call.

Applied, thanks a lot Brian!
I've marked patches 1 to 4 as stable material.

Thanks,
//richard

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 0/5] UBI: Coverity-inspired fixes
Date: Thu, 26 Mar 2015 10:11:37 +0100	[thread overview]
Message-ID: <5513CD49.30803@nod.at> (raw)
In-Reply-To: <20150306020442.GP18140@ld-irv-0074>

Am 06.03.2015 um 03:04 schrieb Brian Norris:
> On Thu, Mar 05, 2015 at 11:33:14AM +0100, Richard Weinberger wrote:
>> Brian,
>>
>> Am 28.02.2015 um 11:23 schrieb Brian Norris:
>>> Except for the last one, these were inspired by Coverity Scan results.
>>>
>>> These fixes have barely been tested, but they are pretty straightforward
>>> logically. As they've been sitting in my dust pile too long, I thought I'd at
>>> least get them out there.
>>>
>>> Brian Norris (5):
>>>   UBI: account for bitflips in both the VID header and data
>>>   UBI: fix out of bounds write
>>>   UBI: initialize LEB number variable
>>>   UBI: fix check for "too many bytes"
>>>   UBI: align comment for readability
>>
>> Nice work!
>> I'll test them later today.
>> Just a quick question, no patch has a stable tag, is this by design?
>> From a first look most of them look like stable material.
> 
> Two reasons:
> 
>  1. I hadn't tested them heavily, and I definitely didn't try to target
>  their codepaths much.
> 
>  2. Given #1 and the fact that these were just found by static analysis,
>  I don't think they pass this test from
>  Documentation/stable_kernel_rules.txt:
> 
>  " - It must fix a real bug that bothers people (not a, "This could be a
>     problem..." type thing)."
> 
> So, I expected they would only be sent to stable if somebody (perhaps
> me) is able to trigger something real, or at least gets some significant
> testing on them.
> 
> Maybe this is a case where you send the fixes, and then send the commit
> IDs to Greg after they have been proven stable and/or can be exploited
> in some way through testing. (Option 2 in the updated
> stable_kernel_rules.txt.)
> 
> But really, it's your/Artem's call.

Applied, thanks a lot Brian!
I've marked patches 1 to 4 as stable material.

Thanks,
//richard

  reply	other threads:[~2015-03-26  9:11 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-28 10:23 [PATCH 0/5] UBI: Coverity-inspired fixes Brian Norris
2015-02-28 10:23 ` Brian Norris
2015-02-28 10:23 ` Brian Norris
2015-02-28 10:23 ` [PATCH 1/5] UBI: account for bitflips in both the VID header and data Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23 ` [PATCH 2/5] UBI: fix out of bounds write Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23 ` [PATCH 3/5] UBI: initialize LEB number variable Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23 ` [PATCH 4/5] UBI: fix check for "too many bytes" Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-03-26  9:29   ` Richard Weinberger
2015-03-26  9:29     ` Richard Weinberger
2015-03-26  9:29     ` Richard Weinberger
2015-02-28 10:23 ` [PATCH 5/5] UBI: align comment for readability Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-02-28 10:23   ` Brian Norris
2015-03-05 10:33 ` [PATCH 0/5] UBI: Coverity-inspired fixes Richard Weinberger
2015-03-05 10:33   ` Richard Weinberger
2015-03-05 10:33   ` Richard Weinberger
2015-03-06  2:04   ` Brian Norris
2015-03-06  2:04     ` Brian Norris
2015-03-06  2:04     ` Brian Norris
2015-03-26  9:11     ` Richard Weinberger [this message]
2015-03-26  9:11       ` Richard Weinberger
2015-03-26  9:11       ` Richard Weinberger

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=5513CD49.30803@nod.at \
    --to=richard@nod.at \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.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 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.