All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Satyam Sharma <satyam.sharma@gmail.com>
Cc: Florin Malita <fmalita@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mtd@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] UBI: dereference after kfree in create_vtbl
Date: Sat, 05 May 2007 16:48:21 +0300	[thread overview]
Message-ID: <1178372901.3659.132.camel@sauron> (raw)
In-Reply-To: <a781481a0705050632y6ffa11a3qeb89f5e6e92da681@mail.gmail.com>

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, &si->corr);
> > 		goto retry;
> > 	}
> > 	kfree(new_seb);
> > out_free:
> > 	ubi_free_vid_hdr(ubi, vid_hdr);
> > 	return err;
> 
> Ummm ...
> 
> 1. "if (err == -EIO)" applies to adding new_seb to the corrupted list,
> and not to retrying. We wouldn't want _not_ to retry if there's some
> other error, or would we?

In case of other error - no, we do not want to retry. Only in case of
-EIO because we just might have hit a new badblock, which is unlikely,
but possible.

If it is anything else then -EIO, then we just return an error and
_refuse_ to attach this MTD device. In this case it does not matter
where we add new_seb. We just drop it. We free all allocated data
structures.

> 2. "if (++tries <= 5)" applies to "goto retry" and not to adding
> new_seb to the corrupted list. If we hit write failure for the 5th
> time and err == -EIO, we should still be adding it to corrupted list,
> but not retry, of course. Otherwise we would add the first 4 write
> failure (with -EIO) eraseblocks to si->corr, but the 5th _similar_
> case is ... just freed?

If we hit -EIO more then five times, there is probably something _really
bad_ with this MTD device and we _refuse_ attaching it. We return error,
and every data structure is freed. It does not matter if we add new_seb
anywhere or not. It is anyway just freed.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)


WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind@infradead.org>
To: Satyam Sharma <satyam.sharma@gmail.com>
Cc: Florin Malita <fmalita@gmail.com>,
	linux-mtd@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] UBI: dereference after kfree in create_vtbl
Date: Sat, 05 May 2007 16:48:21 +0300	[thread overview]
Message-ID: <1178372901.3659.132.camel@sauron> (raw)
In-Reply-To: <a781481a0705050632y6ffa11a3qeb89f5e6e92da681@mail.gmail.com>

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, &si->corr);
> > 		goto retry;
> > 	}
> > 	kfree(new_seb);
> > out_free:
> > 	ubi_free_vid_hdr(ubi, vid_hdr);
> > 	return err;
> 
> Ummm ...
> 
> 1. "if (err == -EIO)" applies to adding new_seb to the corrupted list,
> and not to retrying. We wouldn't want _not_ to retry if there's some
> other error, or would we?

In case of other error - no, we do not want to retry. Only in case of
-EIO because we just might have hit a new badblock, which is unlikely,
but possible.

If it is anything else then -EIO, then we just return an error and
_refuse_ to attach this MTD device. In this case it does not matter
where we add new_seb. We just drop it. We free all allocated data
structures.

> 2. "if (++tries <= 5)" applies to "goto retry" and not to adding
> new_seb to the corrupted list. If we hit write failure for the 5th
> time and err == -EIO, we should still be adding it to corrupted list,
> but not retry, of course. Otherwise we would add the first 4 write
> failure (with -EIO) eraseblocks to si->corr, but the 5th _similar_
> case is ... just freed?

If we hit -EIO more then five times, there is probably something _really
bad_ with this MTD device and we _refuse_ attaching it. We return error,
and every data structure is freed. It does not matter if we add new_seb
anywhere or not. It is anyway just freed.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2007-05-05 16:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03 15:49 [PATCH] UBI: dereference after kfree in create_vtbl Florin Malita
2007-05-04  7:17 ` Artem Bityutskiy
2007-05-04 21:42 ` Satyam Sharma
2007-05-04 21:42   ` Satyam Sharma
2007-05-04 23:22   ` Florin Malita
2007-05-04 23:22     ` Florin Malita
2007-05-05  3:55     ` Satyam Sharma
2007-05-05  3:55       ` Satyam Sharma
2007-05-05  7:55       ` Artem Bityutskiy
2007-05-05  7:55         ` Artem Bityutskiy
2007-05-05 12:26         ` Satyam Sharma
2007-05-05 12:26           ` Satyam Sharma
2007-05-05 13:18           ` Artem Bityutskiy
2007-05-05 13:18             ` Artem Bityutskiy
2007-05-05 13:48             ` Satyam Sharma
2007-05-05 13:48               ` Satyam Sharma
2007-05-05 13:59               ` Artem Bityutskiy
2007-05-05 13:59                 ` Artem Bityutskiy
2007-05-05 15:00                 ` Satyam Sharma
2007-05-05 15:00                   ` Satyam Sharma
2007-05-05 12:09       ` Artem Bityutskiy
2007-05-05 12:09         ` Artem Bityutskiy
2007-05-05 13:32         ` Satyam Sharma
2007-05-05 13:32           ` Satyam Sharma
2007-05-05 13:48           ` Artem Bityutskiy [this message]
2007-05-05 13:48             ` Artem Bityutskiy

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=1178372901.3659.132.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=fmalita@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=satyam.sharma@gmail.com \
    /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.