On Sat, 2007-05-05 at 19:02 +0530, Satyam Sharma wrote:
> > write_error:
> > if (err == -EIO && ++tries <= 5) {
> > /*
> > * Probably this physical eraseblock went bad, try to pick
> > * another one.
> > */
> >
On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
> Again, I saw that too, but would still prefer using the higher level
> function ubi_scan_add_to_list() to add to the corrupted list, but with
> a different identifier for the return value to avoid overwriting err.
> list_add_tail seems best
On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
[...]
On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
> Artem would have to step in here to verify if there really is a good
> reason why we kmalloc a fresh ubi_scan_leb every time we want to add
> one to a list.
Particularly in
On Sat, 2007-05-05 at 17:56 +0530, Satyam Sharma wrote:
> > And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
> Ah, good to know that, but please keep list_add_tail (or whatever is
> the implementation abstraction of the various ubi_scan_info lists)
> local to scan.c -- you
On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
On Sat, 2007-05-05 at 17:56 +0530, Satyam Sharma wrote:
> > And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
> Ah, good to know that, but please keep list_add_tail (or whatever is
> the implementation abstraction of
On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
[...]
I've put the fix here:
http://git.infradead.org/?p=users/dedekind/ubi-2.6.git;a=commit;h=5125237efb6a3309fbf5b9a7a21aaf716787f2a2
write_error:
if (err == -EIO && ++tries <= 5) {
/*
* Probably
On Sat, 2007-05-05 at 19:18 +0530, Satyam Sharma wrote:
> Well, you're developing / maintaining this right now, so it's your
> call. Though I bet most people would find keeping that list_add_tail
> local to scan.c more tasteful.
I do not think so. If you are interested, try to find "UBI take 2"
On 5/5/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
On Sat, 2007-05-05 at 19:18 +0530, Satyam Sharma wrote:
> Well, you're developing / maintaining this right now, so it's your
> call. Though I bet most people would find keeping that list_add_tail
> local to scan.c more tasteful.
I do not
Hi,
thanks for finding bugs in this patch. Although this path will likely
never happen, this is good to have it bug-free.
On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
> Artem would have to step in here to verify if there really is a good
> reason why we kmalloc a fresh ubi_scan_leb
Hi,
thanks for finding bugs in this patch. Although this path will likely
never happen, this is good to have it bug-free.
On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
Artem would have to step in here to verify if there really is a good
reason why we kmalloc a fresh ubi_scan_leb
On 5/5/07, Artem Bityutskiy [EMAIL PROTECTED] wrote:
On Sat, 2007-05-05 at 19:18 +0530, Satyam Sharma wrote:
Well, you're developing / maintaining this right now, so it's your
call. Though I bet most people would find keeping that list_add_tail
local to scan.c more tasteful.
I do not think
On 5/5/07, Artem Bityutskiy [EMAIL PROTECTED] wrote:
[...]
I've put the fix here:
http://git.infradead.org/?p=users/dedekind/ubi-2.6.git;a=commit;h=5125237efb6a3309fbf5b9a7a21aaf716787f2a2
write_error:
if (err == -EIO ++tries = 5) {
/*
* Probably this
On Sat, 2007-05-05 at 19:18 +0530, Satyam Sharma wrote:
Well, you're developing / maintaining this right now, so it's your
call. Though I bet most people would find keeping that list_add_tail
local to scan.c more tasteful.
I do not think so. If you are interested, try to find UBI take 2
On 5/5/07, Artem Bityutskiy [EMAIL PROTECTED] wrote:
On Sat, 2007-05-05 at 17:56 +0530, Satyam Sharma wrote:
And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
Ah, good to know that, but please keep list_add_tail (or whatever is
the implementation abstraction of the
On Sat, 2007-05-05 at 17:56 +0530, Satyam Sharma wrote:
And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
Ah, good to know that, but please keep list_add_tail (or whatever is
the implementation abstraction of the various ubi_scan_info lists)
local to scan.c -- you could
On 5/5/07, Artem Bityutskiy [EMAIL PROTECTED] wrote:
[...]
On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
Artem would have to step in here to verify if there really is a good
reason why we kmalloc a fresh ubi_scan_leb every time we want to add
one to a list.
Particularly in vtbl.c
On Sat, 2007-05-05 at 19:02 +0530, Satyam Sharma wrote:
write_error:
if (err == -EIO ++tries = 5) {
/*
* Probably this physical eraseblock went bad, try to pick
* another one.
*/
list_add_tail(new_seb-u.list,
On Sat, 2007-05-05 at 09:25 +0530, Satyam Sharma wrote:
Again, I saw that too, but would still prefer using the higher level
function ubi_scan_add_to_list() to add to the corrupted list, but with
a different identifier for the return value to avoid overwriting err.
list_add_tail seems best
On 5/5/07, Florin Malita <[EMAIL PROTECTED]> wrote:
Hi Satyam,
Satyam Sharma wrote:
> Eeks ... no, wait. You found a (two, actually) bug alright, but fixed
> it wrong. When we fail a write, we *must* add it to the corrupted list
> and _then_ attempt to retry. So, the "if (++tries <= 5)" applies
Hi Satyam,
Satyam Sharma wrote:
Eeks ... no, wait. You found a (two, actually) bug alright, but fixed
it wrong. When we fail a write, we *must* add it to the corrupted list
and _then_ attempt to retry. So, the "if (++tries <= 5)" applies to
"if (!err) goto retry;" and not to the
Hi Florin, Artem,
On 5/3/07, Florin Malita <[EMAIL PROTECTED]> wrote:
[...]
write_error:
- kfree(new_seb);
- /* May be this physical eraseblock went bad, try to pick another one */
- if (++tries <= 5) {
+ /* Maybe this physical eraseblock went bad, try to pick another
On Thu, 2007-05-03 at 11:49 -0400, Florin Malita wrote:
> Coverity (CID 1614) spotted new_seb being dereferenced after kfree() in
> create_vtbl's write_error path.
Applied with minor trailing white-space cleanup, thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from
On Thu, 2007-05-03 at 11:49 -0400, Florin Malita wrote:
Coverity (CID 1614) spotted new_seb being dereferenced after kfree() in
create_vtbl's write_error path.
Applied with minor trailing white-space cleanup, thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from
Hi Florin, Artem,
On 5/3/07, Florin Malita [EMAIL PROTECTED] wrote:
[...]
write_error:
- kfree(new_seb);
- /* May be this physical eraseblock went bad, try to pick another one */
- if (++tries = 5) {
+ /* Maybe this physical eraseblock went bad, try to pick another one
Hi Satyam,
Satyam Sharma wrote:
Eeks ... no, wait. You found a (two, actually) bug alright, but fixed
it wrong. When we fail a write, we *must* add it to the corrupted list
and _then_ attempt to retry. So, the if (++tries = 5) applies to
if (!err) goto retry; and not to the
On 5/5/07, Florin Malita [EMAIL PROTECTED] wrote:
Hi Satyam,
Satyam Sharma wrote:
Eeks ... no, wait. You found a (two, actually) bug alright, but fixed
it wrong. When we fail a write, we *must* add it to the corrupted list
and _then_ attempt to retry. So, the if (++tries = 5) applies to
if
Coverity (CID 1614) spotted new_seb being dereferenced after kfree() in
create_vtbl's write_error path.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
vtbl.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
Coverity (CID 1614) spotted new_seb being dereferenced after kfree() in
create_vtbl's write_error path.
Signed-off-by: Florin Malita [EMAIL PROTECTED]
---
vtbl.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
28 matches
Mail list logo
