Re: [PATCH 2/2] Staging: Lustre: Fixed coding style issues

On Apr 17, 2016, at 10:11 AM, Panos Vlachos wrote: > Fixed one coding style issue in the > file router_proc.c (Lustre staging driver) Perhaps it's best to reference what the issue is. I.e. "Fix too long line in …" and then in the actual message add that you just split it? > > Signed-off-by:

Re: [PATCH 2/2] Staging: Lustre: Fixed coding style issues

On Apr 17, 2016, at 10:11 AM, Panos Vlachos wrote: > Fixed one coding style issue in the > file router_proc.c (Lustre staging driver) Perhaps it's best to reference what the issue is. I.e. "Fix too long line in …" and then in the actual message add that you just split it? > > Signed-off-by:

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Apr 1, 2016, at 2:44 PM, Joe Perches wrote: > On Fri, 2016-04-01 at 14:23 +0000, Drokin, Oleg wrote: >> On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: >>> >>> Question about removing lustre typedefs. >>> >>> Various bits of lustre code use a mix

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Apr 1, 2016, at 2:44 PM, Joe Perches wrote: > On Fri, 2016-04-01 at 14:23 +0000, Drokin, Oleg wrote: >> On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: >>> >>> Question about removing lustre typedefs. >>> >>> Various bits of lustre code use a mix

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: > Question about removing lustre typedefs. > > Various bits of lustre code use a mix of struct foo and foo_t. > > When would be an appropriate time to submit patches similar to > below that individually remove various typedefs from lustre code? I

Re: [lustre-devel] [RFC PATCH 0/3] staging: lustre: detypedef

On Apr 1, 2016, at 9:02 AM, Joe Perches wrote: > Question about removing lustre typedefs. > > Various bits of lustre code use a mix of struct foo and foo_t. > > When would be an appropriate time to submit patches similar to > below that individually remove various typedefs from lustre code? I

Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc

On Mar 12, 2016, at 1:56 PM, Joe Perches wrote: > On Sat, 2016-03-12 at 18:32 +0000, Drokin, Oleg wrote: >> On Mar 12, 2016, at 1:23 PM, Joe Perches wrote: >>> On Sat, 2016-03-12 at 13:00 -0500, James Simmons wrote: >>>> From: James Nunez <james.a.nu...@

Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc

On Mar 12, 2016, at 1:56 PM, Joe Perches wrote: > On Sat, 2016-03-12 at 18:32 +0000, Drokin, Oleg wrote: >> On Mar 12, 2016, at 1:23 PM, Joe Perches wrote: >>> On Sat, 2016-03-12 at 13:00 -0500, James Simmons wrote: >>>> From: James Nunez >>>> >>

Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc

On Mar 12, 2016, at 1:23 PM, Joe Perches wrote: > On Sat, 2016-03-12 at 13:00 -0500, James Simmons wrote: >> From: James Nunez >> >> This is one of the fixes broken out of patch 1 that was >> missed in the merger. With this fix the CERROR called in >>

Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc

On Mar 12, 2016, at 1:23 PM, Joe Perches wrote: > On Sat, 2016-03-12 at 13:00 -0500, James Simmons wrote: >> From: James Nunez >> >> This is one of the fixes broken out of patch 1 that was >> missed in the merger. With this fix the CERROR called in >> sfw_handle_server_rpc will print out

Re: [PATCH 07/10] staging: lustre: add last missing sparse annotation __user

On Mar 4, 2016, at 9:09 PM, James Simmons wrote: > From: Frank Zago > > One of the __user was missed in being applied to upstream > client. This is broken out of patch 11819. It was not, the bug was fixed in another way. > Signed-off-by: Frank Zago >

Re: [PATCH 07/10] staging: lustre: add last missing sparse annotation __user

On Mar 4, 2016, at 9:09 PM, James Simmons wrote: > From: Frank Zago > > One of the __user was missed in being applied to upstream > client. This is broken out of patch 11819. It was not, the bug was fixed in another way. > Signed-off-by: Frank Zago > Intel-bug-id:

Re: [lustre-devel] [PATCH v2 0/6] staging: lustre: update modinfo data

On Feb 26, 2016, at 1:03 AM, Greg Kroah-Hartman wrote: > On Thu, Feb 25, 2016 at 08:07:06PM -0500, James Simmons wrote: >> The module information for Lustre is stale or in some cases >> completely missing. This collection of patches brings the >> modinfo up to date as well as filling in any

Re: [lustre-devel] [PATCH v2 0/6] staging: lustre: update modinfo data

On Feb 26, 2016, at 1:03 AM, Greg Kroah-Hartman wrote: > On Thu, Feb 25, 2016 at 08:07:06PM -0500, James Simmons wrote: >> The module information for Lustre is stale or in some cases >> completely missing. This collection of patches brings the >> modinfo up to date as well as filling in any

Re: [lustre-devel] [PATCH] staging: lustre: Fixed the parenthesis

On Feb 14, 2016, at 10:37 PM, Shalin Mehta wrote: > The parentehsis are fixed in the macro for the ldlm lock to set and > clear the flags. > > Signed-off-by: Shalin Mehta > --- > drivers/staging/lustre/lustre/include/lustre_dlm_flags.h | 4 ++-- > 1 file changed, 2

Re: [lustre-devel] [PATCH] staging: lustre: Fixed the parenthesis

On Feb 14, 2016, at 10:37 PM, Shalin Mehta wrote: > The parentehsis are fixed in the macro for the ldlm lock to set and > clear the flags. > > Signed-off-by: Shalin Mehta > --- > drivers/staging/lustre/lustre/include/lustre_dlm_flags.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] staging: lustre: Fixed the parenthesis

On Feb 15, 2016, at 9:28 PM, Greg KH wrote: > On Sun, Feb 14, 2016 at 07:37:02PM -0800, Shalin Mehta wrote: >> The parentehsis are fixed in the macro for the ldlm lock to set and >> clear the flags. > > "fixed" in what way? Did you test-build this patch? Also, you > mispelled a word here…

Re: [PATCH] staging: lustre: Fixed the parenthesis

On Feb 15, 2016, at 9:28 PM, Greg KH wrote: > On Sun, Feb 14, 2016 at 07:37:02PM -0800, Shalin Mehta wrote: >> The parentehsis are fixed in the macro for the ldlm lock to set and >> clear the flags. > > "fixed" in what way? Did you test-build this patch? Also, you > mispelled a word here…

Re: [PATCH] staging: lustre: lov: Fix sparse warning

Hello! On Nov 21, 2015, at 3:26 AM, Paul Davies C wrote: > This patch fixes the following warnings:- > > drivers/staging/lustre/lustre/lov/lov_object.c:926:22: warning: symbol > 'lov_lsm_get' was not declared. Should it be static? > drivers/staging/lustre/lustre/lov/lov_object.c:942:6:

Re: [PATCH] staging: lustre: lov: Fix sparse warning

Hello! On Nov 21, 2015, at 3:26 AM, Paul Davies C wrote: > This patch fixes the following warnings:- > > drivers/staging/lustre/lustre/lov/lov_object.c:926:22: warning: symbol > 'lov_lsm_get' was not declared. Should it be static? > drivers/staging/lustre/lustre/lov/lov_object.c:942:6:

Re: [lustre-devel] [PATCH] staging: lustre: export cfs_str2mask

On Nov 8, 2015, at 11:34 AM, James Simmons wrote: > We need cfs_str2mask exported for our server code. > Even with the server code not available upstream > it would be nice to use the upstream code on Lustre > servers. > > Signed-off-by: James Simmons > --- >

Re: [PATCH 1/9] Staging: lustre: dir: Replace function calls

On Nov 7, 2015, at 2:41 AM, Shivani Bhardwaj wrote: > Replace the calls of the function ll_finish_md_op_data() with the > standard function kfree(). For functions like this that have meaningflul name and also might include additional logic (even though they don't now), does it make sense to do

Re: [PATCH 1/9] Staging: lustre: dir: Replace function calls

On Nov 7, 2015, at 2:41 AM, Shivani Bhardwaj wrote: > Replace the calls of the function ll_finish_md_op_data() with the > standard function kfree(). For functions like this that have meaningflul name and also might include additional logic (even though they don't now), does it make sense to do

Re: [lustre-devel] [PATCH] staging: lustre: export cfs_str2mask

On Nov 8, 2015, at 11:34 AM, James Simmons wrote: > We need cfs_str2mask exported for our server code. > Even with the server code not available upstream > it would be nice to use the upstream code on Lustre > servers. > > Signed-off-by: James Simmons > --- >

Re: [PATCH] staging: lustre: lustre: llite: Added a blank line

On Oct 3, 2015, at 7:39 AM, Anjali Menon wrote: > Added a blank line after declaration to fix the coding > style warning detected by checkpatch.pl > > WARNING: Missing a blank line after declarations > > Signed-off-by: Anjali Menon > --- > drivers/staging/lustre/lustre/llite/llite_capa.c | 1

Re: [PATCH] staging: lustre: lustre: llite: Added a blank line

On Oct 3, 2015, at 7:39 AM, Anjali Menon wrote: > Added a blank line after declaration to fix the coding > style warning detected by checkpatch.pl > > WARNING: Missing a blank line after declarations > > Signed-off-by: Anjali Menon > --- >

Re: [PATCH 05/10] mm, page_alloc: Distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

Hello! On Sep 30, 2015, at 8:26 AM, Vlastimil Babka wrote: > [diff --git a/drivers/staging/lustre/lnet/lnet/router.c > b/drivers/staging/lustre/lnet/lnet/router.c >> >> index 4fbae5ef44a9..dad9816dfee7 100644 >> --- a/drivers/staging/lustre/lnet/lnet/router.c >> +++

Re: [PATCH 05/10] mm, page_alloc: Distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

Hello! On Sep 30, 2015, at 8:26 AM, Vlastimil Babka wrote: > [diff --git a/drivers/staging/lustre/lnet/lnet/router.c > b/drivers/staging/lustre/lnet/lnet/router.c >> >> index 4fbae5ef44a9..dad9816dfee7 100644 >> --- a/drivers/staging/lustre/lnet/lnet/router.c >> +++

Re: linux-next: build failure after merge of the nfs tree

Hello! On Aug 18, 2015, at 8:05 PM, Stephen Rothwell wrote: > Hi Trond, > > On Tue, 18 Aug 2015 10:56:34 +1000 Stephen Rothwell > wrote: >> >> After merging the nfs tree, today's linux-next build (x86_64 allmodconfig) >> failed like this: >> >>

Re: linux-next: build failure after merge of the nfs tree

Hello! On Aug 18, 2015, at 8:05 PM, Stephen Rothwell wrote: Hi Trond, On Tue, 18 Aug 2015 10:56:34 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: After merging the nfs tree, today's linux-next build (x86_64 allmodconfig) failed like this:

Re: [PATCH v2] staging: lustre: fix symbol redeclared with different type in libcfs

On Aug 15, 2015, at 4:35 AM, Maxime Lorrillere wrote: > lbug_with_loc is declared with __attribute__((noreturn)) in libcfs_private.h > and without this attribute in linux-debug.c. This generates the following > sparse error: drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c:149:6:

Re: [HPDD-discuss] [PATCH] staging: lustre: ptlrpc: add missing include directive

Hello! On Aug 15, 2015, at 4:13 AM, Ioan-Adrian Ratiu wrote: >>> Without including ptlrpc_internal.h, GCC gives prototype warnings >>> "pack_generic.c:642:5: warning: no previous prototype for ..." >> It does? What version of gcc give you that, I don't see that here. > Yes, but it's a

Re: [PATCH v2] staging: lustre: fix symbol redeclared with different type in libcfs

On Aug 15, 2015, at 4:35 AM, Maxime Lorrillere wrote: lbug_with_loc is declared with __attribute__((noreturn)) in libcfs_private.h and without this attribute in linux-debug.c. This generates the following sparse error: drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c:149:6: error:

Re: [HPDD-discuss] [PATCH] staging: lustre: ptlrpc: add missing include directive

Hello! On Aug 15, 2015, at 4:13 AM, Ioan-Adrian Ratiu wrote: Without including ptlrpc_internal.h, GCC gives prototype warnings pack_generic.c:642:5: warning: no previous prototype for ... It does? What version of gcc give you that, I don't see that here. Yes, but it's a non-default warning

Re: about ENOSYS

subject have been missing, so I filled in something. On Aug 3, 2015, at 2:18 AM, Shraddha Barke wrote: > From b67c6c20455b04b77447ab4561e44f1a75dd978d Mon Sep 17 00:00:00 2001 > From: Shraddha Barke > Date: Mon, 3 Aug 2015 11:34:19 +0530 > Subject: [PATCH] Staging : lustre : Use -EINVAL instead

Re: about ENOSYS

subject have been missing, so I filled in something. On Aug 3, 2015, at 2:18 AM, Shraddha Barke wrote: From b67c6c20455b04b77447ab4561e44f1a75dd978d Mon Sep 17 00:00:00 2001 From: Shraddha Barke shraddha.6...@gmail.com Date: Mon, 3 Aug 2015 11:34:19 +0530 Subject: [PATCH] Staging : lustre :

Re: linux-next: build failure after merge of the block tree

On Jul 30, 2015, at 12:17 AM, Stephen Rothwell wrote: > Hi Jens, > > After merging the block tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > drivers/staging/lustre/lustre/llite/../include/obd_support.h:42:0, > from >

Re: linux-next: build failure after merge of the block tree

On Jul 30, 2015, at 12:17 AM, Stephen Rothwell wrote: Hi Jens, After merging the block tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/lustre/lustre/llite/../include/obd_support.h:42:0, from

Re: lustre: LIBCFS_ALLOC

On Jun 23, 2015, at 2:23 AM, Julia Lawall wrote: > It seems that libcfs_kvzalloc doesn't use any particular threshold or > switchingbetween kzalloc and vmalloc, so can be replaced by ths function > too? If you mean to replace all instances of LIBCFS_ALLOC with libcfs_kvzalloc (and all frees

Re: lustre: LIBCFS_ALLOC

On Jun 23, 2015, at 2:23 AM, Julia Lawall wrote: It seems that libcfs_kvzalloc doesn't use any particular threshold or switchingbetween kzalloc and vmalloc, so can be replaced by ths function too? If you mean to replace all instances of LIBCFS_ALLOC with libcfs_kvzalloc (and all frees

Re: [PATCH] Staging: lusture: Remove an open coded simple_open() function

On Jun 16, 2015, at 3:03 AM, Abdul, Hussain (H.) wrote: > From: Abdul Hussain > > This patch removes an open coded simple_open() function and replace file > operations references to the function with simple_open() instead > > Signed-off-by: Abdul Hussain > --- >

Re: [PATCH] Staging: lusture: Remove an open coded simple_open() function

On Jun 16, 2015, at 3:03 AM, Abdul, Hussain (H.) wrote: From: Abdul Hussain hab...@visteon.com This patch removes an open coded simple_open() function and replace file operations references to the function with simple_open() instead Signed-off-by: Abdul Hussain hab...@visteon.com ---

Re: lustre: question about lov_request.c

On Jun 8, 2015, at 3:24 AM, Julia Lawall wrote: >> You are right, set_pga seems to be a dead member. It was alive a once, but >> somehow not fully removed now, >> so it's safe to drop the whole if and also the struct member itself. >> set_oabufs could be dropped as well. > > Looking

Re: lustre: question about lov_request.c

On Jun 8, 2015, at 3:24 AM, Julia Lawall wrote: You are right, set_pga seems to be a dead member. It was alive a once, but somehow not fully removed now, so it's safe to drop the whole if and also the struct member itself. set_oabufs could be dropped as well. Looking further, in the

Re: lustre: question about lov_request.c

Hello! You are right, set_pga seems to be a dead member. It was alive a once, but somehow not fully removed now, so it's safe to drop the whole if and also the struct member itself. set_oabufs could be dropped as well. Thanks. Bye, Oleg On Jun 7, 2015, at 4:11 PM, Julia Lawall

Re: lustre: question about lov_request.c

Hello! You are right, set_pga seems to be a dead member. It was alive a once, but somehow not fully removed now, so it's safe to drop the whole if and also the struct member itself. set_oabufs could be dropped as well. Thanks. Bye, Oleg On Jun 7, 2015, at 4:11 PM, Julia Lawall

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 8:18 PM, Joe Perches wrote: I wonder what is more clear about that in your opinion ve lustre_error/lustre_debug? >>> >>> The fact that you have to explain this shows that it's >>> at least misleading unless you completely understand the >>> code. >> >> Or you know,

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 7:57 PM, Joe Perches wrote: > On Fri, 2015-05-22 at 21:16 +0000, Drokin, Oleg wrote: >> On May 22, 2015, at 11:42 AM, Joe Perches wrote: >> >>> On Fri, 2015-05-22 at 08:08 +, Drokin, Oleg wrote: >>>> On May 22, 2015, at 1:06 AM, Julia

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 11:42 AM, Joe Perches wrote: > On Fri, 2015-05-22 at 08:08 +0000, Drokin, Oleg wrote: >> On May 22, 2015, at 1:06 AM, Julia Lawall wrote: >> >>> On Thu, 21 May 2015, Michael Shuey wrote: >>> >>>> That's a task (of many) I've b

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 1:06 AM, Julia Lawall wrote: > On Thu, 21 May 2015, Michael Shuey wrote: > >> That's a task (of many) I've been putting on the back burner until the code >> is cleaner. It's also a HUGE change, since there are debug macros >> everywhere, and they all check a #define'd mask

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

Removal of lustre-added typedefs is worthwhile, actually. I scraped the surface some time ago, but could not complete it back then. On May 21, 2015, at 5:47 PM, Michael Shuey wrote: > I've been killing off a *lot* of checkpatch warnings, and I'm probably > getting a tad overzealous. I'll drop

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

Removal of lustre-added typedefs is worthwhile, actually. I scraped the surface some time ago, but could not complete it back then. On May 21, 2015, at 5:47 PM, Michael Shuey wrote: I've been killing off a *lot* of checkpatch warnings, and I'm probably getting a tad overzealous. I'll drop

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 1:06 AM, Julia Lawall wrote: On Thu, 21 May 2015, Michael Shuey wrote: That's a task (of many) I've been putting on the back burner until the code is cleaner. It's also a HUGE change, since there are debug macros everywhere, and they all check a #define'd mask to see

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 11:42 AM, Joe Perches wrote: On Fri, 2015-05-22 at 08:08 +, Drokin, Oleg wrote: On May 22, 2015, at 1:06 AM, Julia Lawall wrote: On Thu, 21 May 2015, Michael Shuey wrote: That's a task (of many) I've been putting on the back burner until the code is cleaner

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 8:18 PM, Joe Perches wrote: I wonder what is more clear about that in your opinion ve lustre_error/lustre_debug? The fact that you have to explain this shows that it's at least misleading unless you completely understand the code. Or you know, you might take the

Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes

On May 22, 2015, at 7:57 PM, Joe Perches wrote: On Fri, 2015-05-22 at 21:16 +, Drokin, Oleg wrote: On May 22, 2015, at 11:42 AM, Joe Perches wrote: On Fri, 2015-05-22 at 08:08 +, Drokin, Oleg wrote: On May 22, 2015, at 1:06 AM, Julia Lawall wrote: On Thu, 21 May 2015, Michael

Re: [PATCH 4/4] Staging: lustre: sparse lock warning fix

On May 21, 2015, at 11:12 AM, Dan Carpenter wrote: > Oh, sorry, I didn't read your patch very carefully. It won't cause a > deadlock. But I'm going to assume it's still not right until lustre > expert Acks it. I just took a closer look and it appears original code is buggy and the patch just

Re: [PATCH 4/4] Staging: lustre: sparse lock warning fix

On May 21, 2015, at 11:12 AM, Dan Carpenter wrote: Oh, sorry, I didn't read your patch very carefully. It won't cause a deadlock. But I'm going to assume it's still not right until lustre expert Acks it. I just took a closer look and it appears original code is buggy and the patch just

Re: [PATCH] staging: Replace kzalloc and memcpy by kmemdup

Thanks! But rather than that, this whole function (lprocfs_exp_setup) needs to go, since it's not used by anything on the client. The removal is sitting in my queue of "stop using procfs in lustre" patches that I am going to submit real soon now and this patch would just create an unnecessary

Re: [PATCH] staging: Replace kzalloc and memcpy by kmemdup

Thanks! But rather than that, this whole function (lprocfs_exp_setup) needs to go, since it's not used by anything on the client. The removal is sitting in my queue of stop using procfs in lustre patches that I am going to submit real soon now and this patch would just create an unnecessary

Re: lustre_dlm_flags.h GPLv3 license clarification

Hello! On May 12, 2015, at 6:43 PM, George G. Davis wrote: > Greetings, > > Resending this using the correct version of get_maintainers.pl. > > As recommended in the thread "SPDX-License-Identifier” [1], I would like to > followup with the > maintainers of the file >

Re: lustre_dlm_flags.h GPLv3 license clarification

Hello! On May 12, 2015, at 6:43 PM, George G. Davis wrote: Greetings, Resending this using the correct version of get_maintainers.pl. As recommended in the thread SPDX-License-Identifier” [1], I would like to followup with the maintainers of the file

Re: [PATCH] staging: lustre: remove unused variable

Hello! On May 11, 2015, at 7:43 AM, Sudip Mukherjee wrote: > On Mon, May 11, 2015 at 02:31:02PM +0300, Dan Carpenter wrote: >> On Mon, May 11, 2015 at 04:17:10PM +0530, Sudip Mukherjee wrote: >>> - if (set->set_pga) { >>> - int len = set->set_oabufs * sizeof(*set->set_pga); >>> + if

Re: [PATCH] staging: lustre: remove unused variable

Hello! On May 11, 2015, at 7:43 AM, Sudip Mukherjee wrote: On Mon, May 11, 2015 at 02:31:02PM +0300, Dan Carpenter wrote: On Mon, May 11, 2015 at 04:17:10PM +0530, Sudip Mukherjee wrote: - if (set-set_pga) { - int len = set-set_oabufs * sizeof(*set-set_pga); + if (set-set_pga)

Re: [HPDD-discuss] [PATCH] staging: lustre: code cleanup - variable declaration spacing

Hello! On May 7, 2015, at 8:09 AM, Dan Carpenter wrote: >>> Clean up spacing in some variable declarations, to be more consistent. >>> >>> It's small, but I need to start somewhere. Please let me know if I'm not >>> adhering to proper procedure for trivial cleanups. >> >> It's actually Lustre

Re: [HPDD-discuss] [PATCH] staging: lustre: code cleanup - variable declaration spacing

Hello! On May 7, 2015, at 8:09 AM, Dan Carpenter wrote: Clean up spacing in some variable declarations, to be more consistent. It's small, but I need to start somewhere. Please let me know if I'm not adhering to proper procedure for trivial cleanups. It's actually Lustre coding style to

Re: [PATCH 0/3 v2] Replace OBD_CPT_ALLOC etc by kzalloc_node

All three are good from my perspective. Thanks! On May 3, 2015, at 10:07 AM, Julia Lawall wrote: > The complete semantic patch used to make this transformation is as follows: > (http://coccinelle.lip6.fr/). > > // > @@ > expression ptr,cptab,cpt,size,gfp; > @@ > > - OBD_CPT_ALLOC_GFP(ptr,

Re: [PATCH] staging: lustre: obd_support: Add obd_cpt_alloc function

On May 3, 2015, at 1:53 AM, Julia Lawall wrote: > On Sat, 2 May 2015, Drokin, Oleg wrote: > >> >> On May 2, 2015, at 5:16 PM, Julia Lawall wrote: >> >>> Summarize OBD_CPT_ALLOC_GFP, OBD_CPT_ALLOC, and OBD_CPT_ALLOC_PTR as a >>> function, obd_cpt_a

Re: [PATCH] staging: lustre: obd_support: Add obd_cpt_alloc function

On May 3, 2015, at 1:53 AM, Julia Lawall wrote: On Sat, 2 May 2015, Drokin, Oleg wrote: On May 2, 2015, at 5:16 PM, Julia Lawall wrote: Summarize OBD_CPT_ALLOC_GFP, OBD_CPT_ALLOC, and OBD_CPT_ALLOC_PTR as a function, obd_cpt_alloc. Signed-off-by: Julia Lawall julia.law...@lip6.fr

Re: [PATCH 0/3 v2] Replace OBD_CPT_ALLOC etc by kzalloc_node

All three are good from my perspective. Thanks! On May 3, 2015, at 10:07 AM, Julia Lawall wrote: The complete semantic patch used to make this transformation is as follows: (http://coccinelle.lip6.fr/). // smpl @@ expression ptr,cptab,cpt,size,gfp; @@ - OBD_CPT_ALLOC_GFP(ptr, cptab,

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

Hello! On May 2, 2015, at 4:14 AM, Dan Carpenter wrote: > On Fri, May 01, 2015 at 09:13:11PM +0000, Drokin, Oleg wrote: >>>> The patch was submitted. >>>> But it depends on a symbol that's not exported. >>>> I was not able to change that. >>>>

Re: [PATCH] staging: lustre: obd_support: Add obd_cpt_alloc function

On May 2, 2015, at 5:16 PM, Julia Lawall wrote: > Summarize OBD_CPT_ALLOC_GFP, OBD_CPT_ALLOC, and OBD_CPT_ALLOC_PTR as a > function, obd_cpt_alloc. > > Signed-off-by: Julia Lawall > > --- > > Some questions: Is the name OK? Is the NULL test needed? If not, should > the call to kzalloc_node

Re: [PATCH] staging: lustre: obd_support: Add obd_cpt_alloc function

On May 2, 2015, at 5:16 PM, Julia Lawall wrote: Summarize OBD_CPT_ALLOC_GFP, OBD_CPT_ALLOC, and OBD_CPT_ALLOC_PTR as a function, obd_cpt_alloc. Signed-off-by: Julia Lawall julia.law...@lip6.fr --- Some questions: Is the name OK? Is the NULL test needed? If not, should the call to

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

Hello! On May 2, 2015, at 4:14 AM, Dan Carpenter wrote: On Fri, May 01, 2015 at 09:13:11PM +, Drokin, Oleg wrote: The patch was submitted. But it depends on a symbol that's not exported. I was not able to change that. http://www.spinics.net/lists/linux-mm/msg83997.html But you were

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:58 PM, Greg Kroah-Hartman wrote: > On Fri, May 01, 2015 at 08:52:37PM +0000, Drokin, Oleg wrote: >> >> On May 1, 2015, at 4:49 PM, Greg Kroah-Hartman wrote: >> >>> On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote: >>&

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:49 PM, Greg Kroah-Hartman wrote: > On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote: >>> We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though. >>> >>> It's simple enough to write a function: >>> >>> void *obd_zalloc(size_t size) >>> { >>>

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:18 PM, Simmons, James A. wrote: > Yes the LARGE functions do the switching. I was expecting also patches to > remove the > OBD_ALLOC_LARGE functions as well which is not the case here. I do have one > question still. The > macro __OBD_MALLOC_VERBOSE allowed the ability

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:02 PM, Dan Carpenter wrote: > We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though. > > It's simple enough to write a function: > > void *obd_zalloc(size_t size) > { > if (size > 4 * PAGE_CACHE_SIZE) > return vzalloc(size); >

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

Hello! On May 1, 2015, at 1:48 PM, Julia Lawall wrote: >>> From: Julia Lawall >>> >>> Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by >>> kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree. >> >> Nak: James Simmons >> >> A simple replace will not work. The

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:02 PM, Dan Carpenter wrote: We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though. It's simple enough to write a function: void *obd_zalloc(size_t size) { if (size 4 * PAGE_CACHE_SIZE) return vzalloc(size); else

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

Hello! On May 1, 2015, at 1:48 PM, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree. Nak: James Simmons jsimm...@infradead.org A simple replace

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:58 PM, Greg Kroah-Hartman wrote: On Fri, May 01, 2015 at 08:52:37PM +, Drokin, Oleg wrote: On May 1, 2015, at 4:49 PM, Greg Kroah-Hartman wrote: On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote: We are hopefully going to get rid

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:18 PM, Simmons, James A. wrote: Yes the LARGE functions do the switching. I was expecting also patches to remove the OBD_ALLOC_LARGE functions as well which is not the case here. I do have one question still. The macro __OBD_MALLOC_VERBOSE allowed the ability to

Re: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

On May 1, 2015, at 4:49 PM, Greg Kroah-Hartman wrote: On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote: We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though. It's simple enough to write a function: void *obd_zalloc(size_t size) { if (size 4 *

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 3:34 AM, Christoph Hellwig wrote: > On Wed, Apr 22, 2015 at 06:49:08AM +0000, Drokin, Oleg wrote: >> I know this is not going to be a popular opinion with you, but sometimes >> opening a file >> is just too expensive. 1 RPC roudntrip to open a file

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 3:34 AM, Christoph Hellwig wrote: On Wed, Apr 22, 2015 at 06:49:08AM +, Drokin, Oleg wrote: I know this is not going to be a popular opinion with you, but sometimes opening a file is just too expensive. 1 RPC roudntrip to open a file and then another one to close

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 2:31 AM, Christoph Hellwig wrote: > On Wed, Apr 22, 2015 at 06:27:11AM +0000, Drokin, Oleg wrote: >>> Nak on exporting symbols for broken staging code. Please get rid of >>> the ioctls looking up path names in horrible ways in the lustre code. &

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 2:31 AM, Greg Kroah-Hartman wrote: > On Tue, Apr 21, 2015 at 10:53:11PM -0700, Christoph Hellwig wrote: >> Nak on exporting symbols for broken staging code. Please get rid of >> the ioctls looking up path names in horrible ways in the lustre code. > > I agree with

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 1:53 AM, Christoph Hellwig wrote: > Nak on exporting symbols for broken staging code. Please get rid of > the ioctls looking up path names in horrible ways in the lustre code. For a reference, is there a good example of a non-horrible way to look up a pathname? Thanks.

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 1:53 AM, Christoph Hellwig wrote: Nak on exporting symbols for broken staging code. Please get rid of the ioctls looking up path names in horrible ways in the lustre code. For a reference, is there a good example of a non-horrible way to look up a pathname? Thanks. Bye,

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 2:31 AM, Greg Kroah-Hartman wrote: On Tue, Apr 21, 2015 at 10:53:11PM -0700, Christoph Hellwig wrote: Nak on exporting symbols for broken staging code. Please get rid of the ioctls looking up path names in horrible ways in the lustre code. I agree with Christoph, we

Re: [PATCH 1/2] vfs: export symbol 'getname' and 'putname'

On Apr 22, 2015, at 2:31 AM, Christoph Hellwig wrote: On Wed, Apr 22, 2015 at 06:27:11AM +, Drokin, Oleg wrote: Nak on exporting symbols for broken staging code. Please get rid of the ioctls looking up path names in horrible ways in the lustre code. For a reference, is there a good

Re: [HPDD-discuss] [PATCH] staging: lustre: Make cfs_sched_rehash static

If you checked the code, you would see that it's used in drivers/staging/lustre/lustre/libcfs/module.c too. drivers/staging/lustre/lustre/libcfs/module.c:extern struct cfs_wi_sched *cfs_sched_rehash; drivers/staging/lustre/lustre/libcfs/module.c: rc, _sched_rehash);

Re: [HPDD-discuss] [PATCH] staging: lustre: Make cfs_sched_rehash static

If you checked the code, you would see that it's used in drivers/staging/lustre/lustre/libcfs/module.c too. drivers/staging/lustre/lustre/libcfs/module.c:extern struct cfs_wi_sched *cfs_sched_rehash; drivers/staging/lustre/lustre/libcfs/module.c: rc,

Re: [PATCH] staging: lustre: replace kzalloc with copy_from_user with memdup_user

Hello! On Apr 2, 2015, at 6:18 AM, Julia Lawall wrote: >> Julia, I wonder if you happen to have a bunch of other patches to get rid of >> the rest of OBD_ALLOC and OBD_FREE stuff by any chance? > I can generate them again, but I wasn't clear on what was wanted. I would > really prefer

Re: [PATCH] staging: lustre: replace kzalloc with copy_from_user with memdup_user

Hello! On Apr 2, 2015, at 6:18 AM, Julia Lawall wrote: Julia, I wonder if you happen to have a bunch of other patches to get rid of the rest of OBD_ALLOC and OBD_FREE stuff by any chance? I can generate them again, but I wasn't clear on what was wanted. I would really prefer something

Re: [PATCH] staging: lustre: replace kzalloc with copy_from_user with memdup_user

On Mar 31, 2015, at 11:57 AM, gre...@linuxfoundation.org wrote: > On Tue, Mar 31, 2015 at 05:15:23PM +0200, Julia Lawall wrote: >> On Tue, 31 Mar 2015, Dhere, Chaitanya (C.) wrote: >> >>> This patch replaces kzalloc and copy_from_user with memdup_user call >>> This change was detected with

Re: [PATCH] staging: lustre: replace kzalloc with copy_from_user with memdup_user

On Mar 31, 2015, at 11:57 AM, gre...@linuxfoundation.org wrote: On Tue, Mar 31, 2015 at 05:15:23PM +0200, Julia Lawall wrote: On Tue, 31 Mar 2015, Dhere, Chaitanya (C.) wrote: This patch replaces kzalloc and copy_from_user with memdup_user call This change was detected with coccinelle tool

Re: [PATCH v3] staging: lustre: fix coding style errors

On Feb 9, 2015, at 4:34 PM, wrote: >> There's a third coding style error in this file which I've chosen to >> not fix for clarity's sake. It is: initializing min_watchdog_ratelimit >> (static int) to 0 > > Please fix that too, it's not correct. Drop the comment there if you > think that's

Re: [PATCH v3] staging: lustre: fix coding style errors

On Feb 9, 2015, at 4:34 PM, gre...@linuxfoundation.org wrote: There's a third coding style error in this file which I've chosen to not fix for clarity's sake. It is: initializing min_watchdog_ratelimit (static int) to 0 Please fix that too, it's not correct. Drop the comment there if you

  1   2   >