linux-kernel - Re: [PATCH v3 1/2] Staging: lustre: Refactor the function interval_erase_color() in /lustre/ldlm/interval

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 14 Jan 2014 17:41:58 +0000
From:	"Xiong, Jinshan" <jinshan.xiong@...el.com>
To:	Monam Agarwal <monamagarwal123@...il.com>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"Dilger, Andreas" <andreas.dilger@...el.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rashika Kheria <rashika.kheria@...il.com>
Subject: Re: [PATCH v3 1/2] Staging: lustre: Refactor the function
 interval_erase_color() in /lustre/ldlm/interval_tree.c

On Jan 14, 2014, at 3:09 AM, Monam Agarwal <monamagarwal123@...il.com<mailto:monamagarwal123@...il.com>> wrote:

On Tue, Jan 14, 2014 at 1:31 PM, Xiong, Jinshan <jinshan.xiong@...el.com<mailto:jinshan.xiong@...el.com>> wrote:

On Jan 13, 2014, at 11:56 PM, Dilger, Andreas <andreas.dilger@...el.com<mailto:andreas.dilger@...el.com>> wrote:

Begin forwarded message:

From: Greg KH <gregkh@...uxfoundation.org<mailto:gregkh@...uxfoundation.org>>
Subject: Re: [PATCH v3 1/2] Staging: lustre: Refactor the function interval_erase_color() in /lustre/ldlm/interval_tree.c
Date: January 11, 2014 at 1:33:58 PM MST
To: Monam Agarwal <monamagarwal123@...il.com<mailto:monamagarwal123@...il.com>>
Cc: Dan Carpenter <dan.carpenter@...cle.com<mailto:dan.carpenter@...cle.com>>, <devel@...verdev.osuosl.org<mailto:devel@...verdev.osuosl.org>>, <andreas.dilger@...el.com<mailto:andreas.dilger@...el.com>>, <peter.p.waskiewicz.jr@...el.com<mailto:peter.p.waskiewicz.jr@...el.com>>, <linux-kernel@...r.kernel.org<mailto:linux-kernel@...r.kernel.org>>, Rashika Kheria <rashika.kheria@...il.com<mailto:rashika.kheria@...il.com>>

On Sat, Jan 11, 2014 at 05:14:35PM +0530, Monam Agarwal wrote:
On Sat, Jan 11, 2014 at 5:09 PM, Dan Carpenter <dan.carpenter@...cle.com<mailto:dan.carpenter@...cle.com>> wrote:
On Sat, Jan 11, 2014 at 04:56:44PM +0530, Monam Agarwal wrote:
I took n as a flag to decide whether parent->in_left == node is true
or not in the called function.

So "n" stands for "node"?

Should I use some other name for the flag.

Yes.

Will "flag" be a suitable name?

I’d suggest `bool is_right_child’.

I’ve checked the patch and it looks good. There exists a unit test case for interval tree under lustre/tests/ named it_test.c, please compile it and verify your change.

I am using tree from
http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/.
There is no lustre/tests folder in my tree and no file named
it_test.c.
Kindly let me know the tree you are working from.

I’m using git tree git://git.hpdd.intel.com/fs/lustre-release.git<http://git.hpdd.intel.com/?p=fs/lustre-release.git>

there are also some useful information about compiling and running the code: https://wiki.hpdd.intel.com/display/PUB/Testing+a+Lustre+filesystem, usually I download a patched kernel rpm so that I can save a lot of time from building the kernel myself. Go to build.whamcloud.com<http://build.whamcloud.com> and look for lustre-master, click in and choose server side package based on your distro.

If you’re interested in contributing code to lustre, here are some useful links about creating the patch, review the patch, pass regression test, etc: https://wiki.hpdd.intel.com/display/PUB/Lustre+Development

Jinshan

Jinshan

Ick, no.  You don't want a "flag" to have to determine what the logic is
for a given function.  That just causes confusion and makes things
really hard to read and understand over time.

This whole function looks like a red/black tree, or something like that.
Shouldn't we just be using the in-kernel implementation of this?  And if
not, then you really need to get the feedback of the code's original
authors as you might be changing the algorithm in ways that could cause
big problems.

thanks,

greg k-h

Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/