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 10:55:11 +0300 [thread overview]
Message-ID: <1178351711.3659.54.camel@sauron> (raw)
In-Reply-To: <a781481a0705042055u5e9ba060w95da83b0fbeff76a@mail.gmail.com>
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 every time we want to add
> one to a list.
Particularly in vtbl.c there is no good reason. Leftover of itsy-bitsy
units. I'll make ubi_scan_add_to_list static, as well as
ubi_scan_add_used(). And I'll rename them to something shorter. They are
only useful in scan.c.
And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
> If possible, the best solution would be to change
> ubi_scan_add_to_list() to take in a valid struct ubi_scan_leb and just
> add that to the specified list (using list_add_tail or whatever) --
> and leave allocation up to callers,
In scan.c it is useful because _all_ callers have to allocate it. vtbl.c
is the only place which does not need it. I'll fix this.
> >though this likely requires a
> major cleanup of this driver w.r.t. ubi_scan_leb lifetime semantics.
What is wrong with the semantics, please be more specific.
I'll fix this shortly.
--
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>,
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 10:55:11 +0300 [thread overview]
Message-ID: <1178351711.3659.54.camel@sauron> (raw)
In-Reply-To: <a781481a0705042055u5e9ba060w95da83b0fbeff76a@mail.gmail.com>
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 every time we want to add
> one to a list.
Particularly in vtbl.c there is no good reason. Leftover of itsy-bitsy
units. I'll make ubi_scan_add_to_list static, as well as
ubi_scan_add_used(). And I'll rename them to something shorter. They are
only useful in scan.c.
And it is fine to use list_add_tail() directly in vtbl.c. Will be fixed.
> If possible, the best solution would be to change
> ubi_scan_add_to_list() to take in a valid struct ubi_scan_leb and just
> add that to the specified list (using list_add_tail or whatever) --
> and leave allocation up to callers,
In scan.c it is useful because _all_ callers have to allocate it. vtbl.c
is the only place which does not need it. I'll fix this.
> >though this likely requires a
> major cleanup of this driver w.r.t. ubi_scan_leb lifetime semantics.
What is wrong with the semantics, please be more specific.
I'll fix this shortly.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2007-05-05 7:55 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 [this message]
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
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=1178351711.3659.54.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.