From: Cody P Schafer <cody@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/8] fs/ext3: use rbtree postorder iteration helper instead of opencoding
Date: Mon, 04 Nov 2013 17:33:19 -0800 [thread overview]
Message-ID: <52784ADF.1040104@linux.vnet.ibm.com> (raw)
In-Reply-To: <20131105004559.GB24531@quack.suse.cz>
On 11/04/2013 04:45 PM, Jan Kara wrote:
> On Mon 04-11-13 15:26:38, Jan Kara wrote:
>> On Fri 01-11-13 15:38:50, Cody P Schafer wrote:
>>> Use rbtree_postorder_for_each_entry_safe() to destroy the rbtree instead
>>> of opencoding an alternate postorder iteration that modifies the tree
>> Thanks. I've merged the patch into my tree.
> Hum, except that the kernel oopses with this patch. And I think the
> problem is in rbtree_postorder_for_each_entry_safe(). How are those tests
> for NULL supposed to work? For example if the tree is empty, 'pos' will be
> NULL and you'll call rb_next_postorder(&NULL->field) which is pretty much
> guaranteed to oops if 'field' doesn't have offset 0 in the structure...
>
You're absolutely right, those NULL checks are wrong when the rb_node
isn't the first element. Fix incoming shortly.
next prev parent reply other threads:[~2013-11-05 1:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-01 22:38 [PATCH 1/8] net ipset: use rbtree postorder iteration instead of opencoding Cody P Schafer
2013-11-01 22:38 ` [PATCH 2/8] trace/trace_stat: use rbtree postorder iteration helper " Cody P Schafer
2013-11-02 2:45 ` Steven Rostedt
2013-11-04 8:49 ` Cody P Schafer
2013-11-04 14:22 ` Steven Rostedt
2013-11-01 22:38 ` [PATCH 3/8] fs/ubifs: " Cody P Schafer
2013-11-01 22:38 ` Cody P Schafer
2013-11-01 22:38 ` [PATCH 4/8] fs/ext4: " Cody P Schafer
2013-11-01 22:38 ` [PATCH 5/8] fs/jffs2: " Cody P Schafer
2013-11-01 22:38 ` Cody P Schafer
2013-11-01 22:38 ` [PATCH 6/8] fs/ext3: " Cody P Schafer
2013-11-04 14:26 ` Jan Kara
2013-11-05 0:45 ` Jan Kara
2013-11-05 1:33 ` Cody P Schafer [this message]
2013-11-05 1:40 ` [PATCH 1/2] rbtree: fix postorder iteration when the rb_node is not the first element in an entry Cody P Schafer
2013-11-05 1:40 ` [PATCH 2/2] rbtree/test: move rb_node to the middle of the test struct Cody P Schafer
2013-11-05 10:05 ` [PATCH 1/2] rbtree: fix postorder iteration when the rb_node is not the first element in an entry Cody P Schafer
2013-11-05 21:57 ` Jan Kara
2013-11-05 22:56 ` Jan Kara
2013-11-06 20:18 ` Cody P Schafer
2013-11-06 21:37 ` [PATCH] rbtree/test: test rbtree_postorder_for_each_entry_safe() Cody P Schafer
2013-11-06 23:16 ` Andrew Morton
2013-11-01 22:38 ` [PATCH 7/8] mtd/ubi: use rbtree postorder iteration helper instead of opencoding Cody P Schafer
2013-11-01 22:38 ` Cody P Schafer
2013-11-01 22:38 ` [PATCH 8/8] sh/dwarf: use rbtree postorder iteration helper instead of solution using repeated rb_er Cody P Schafer
2013-11-01 22:38 ` [PATCH 8/8] sh/dwarf: use rbtree postorder iteration helper instead of solution using repeated rb_erase() Cody P Schafer
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=52784ADF.1040104@linux.vnet.ibm.com \
--to=cody@linux.vnet.ibm.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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.