Re: [lustre-devel] [PATCH 00/20] staging: lustre: convert to rhashtable

>>> libcfs in lustre has a resizeable hashtable. >>> Linux already has a resizeable hashtable, rhashtable, which is better >>> is most metrics. See https://lwn.net/Articles/751374/ in a few days >>> for an introduction to rhashtable. >> >> Thansk for starting this work. I was think about cleaning

Re: [lustre-devel] [PATCH 00/20] staging: lustre: convert to rhashtable

>>> libcfs in lustre has a resizeable hashtable. >>> Linux already has a resizeable hashtable, rhashtable, which is better >>> is most metrics. See https://lwn.net/Articles/751374/ in a few days >>> for an introduction to rhashtable. >> >> Thansk for starting this work. I was think about cleaning

RE: Staging: lustre: Make lustre_profile_list static

>Variable lustre_profile_list is only used inside obd_config.c, >better make it static > >Signed-off-by: Iban Rodriguez Acked-by: James Simmons >--- > drivers/staging/lustre/lustre/obdclass/obd_config.c | 2 +- > 1 file changed, 1 insertion(+), 1

RE: Staging: lustre: Make lustre_profile_list static

>Variable lustre_profile_list is only used inside obd_config.c, >better make it static > >Signed-off-by: Iban Rodriguez Acked-by: James Simmons >--- > drivers/staging/lustre/lustre/obdclass/obd_config.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

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

>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? > >These are pretty trivial to produce and verify so

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

>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? > >These are pretty trivial to produce and verify so

RE: [lustre-devel] [PATCH 2/6] staging: lustre: libcfs: move memory_pressure functions to libcfs_prim.h

>On Thu, Mar 31, 2016 at 10:18:36AM -0400, James Simmons wrote: >> Long ago libcfs_prim.h was used for userland code which is why >> memory_pressure_*() handling is in both libcfs_prim.h and >> linux-mem.h headers. So lets just move the memory_pressure_*() >> to libcfs_prim.h. >> >>

RE: [lustre-devel] [PATCH 2/6] staging: lustre: libcfs: move memory_pressure functions to libcfs_prim.h

>On Thu, Mar 31, 2016 at 10:18:36AM -0400, James Simmons wrote: >> Long ago libcfs_prim.h was used for userland code which is why >> memory_pressure_*() handling is in both libcfs_prim.h and >> linux-mem.h headers. So lets just move the memory_pressure_*() >> to libcfs_prim.h. >> >>

RE: [lustre-devel] [PATCH] Revert "Staging: lustre: o2iblnd: Use sizeof type *pointer instead of sizeof type."

>> > > so the right code should be: >> > > >> > > sizeof(**net->ibn_tx_ps); >> > > and the same for sizeof(**net->ibn_fmr_ps) >> > That's a mess, isn't there some other way to fix this up to be more >> > "obvious"? >> This must have been encountered in the past. How was it handle in

RE: [lustre-devel] [PATCH] Revert "Staging: lustre: o2iblnd: Use sizeof type *pointer instead of sizeof type."

>> > > so the right code should be: >> > > >> > > sizeof(**net->ibn_tx_ps); >> > > and the same for sizeof(**net->ibn_fmr_ps) >> > That's a mess, isn't there some other way to fix this up to be more >> > "obvious"? >> This must have been encountered in the past. How was it handle in

RE: [lustre-devel] [PATCH] Revert "Staging: lustre: o2iblnd: Use sizeof type *pointer instead of sizeof type."

>On Wed, Mar 23, 2016 at 05:39:36AM +, Dilger, Andreas wrote: >> On 2016/03/22, 19:49, "lustre-devel on behalf of Greg Kroah-Hartman" >> > gre...@linuxfoundation.org> wrote: >> >> >On Tue, Mar 22, 2016 at 06:21:04PM -0400, James Simmons

RE: [lustre-devel] [PATCH] Revert "Staging: lustre: o2iblnd: Use sizeof type *pointer instead of sizeof type."

>On Wed, Mar 23, 2016 at 05:39:36AM +, Dilger, Andreas wrote: >> On 2016/03/22, 19:49, "lustre-devel on behalf of Greg Kroah-Hartman" >> > gre...@linuxfoundation.org> wrote: >> >> >On Tue, Mar 22, 2016 at 06:21:04PM -0400, James Simmons wrote: >> >> Latest testing fails when using ko2iblnd.

RE: [PATCH] staging: lustre: really make lustre dependent on LNet

>A patch intended to add a dependency on LNET for lustre didn't >actually do that and instead allowed configurations that contain >lustre with lnet but without IPv4 support that subsequently >fail to link: > >warning: (LUSTRE_FS) selects LNET which has unmet direct dependencies (STAGING >&& INET

RE: [PATCH] staging: lustre: really make lustre dependent on LNet

>A patch intended to add a dependency on LNET for lustre didn't >actually do that and instead allowed configurations that contain >lustre with lnet but without IPv4 support that subsequently >fail to link: > >warning: (LUSTRE_FS) selects LNET which has unmet direct dependencies (STAGING >&& INET

RE: [lustre-devel] [PATCH 00/10] Last batch of fixes for LNet

>On Fri, Mar 04, 2016 at 09:09:40PM -0500, James Simmons wrote: >> This batch merges the remaining LNet patches from the OpenSFS >> branch for the upstream client. Once merged the LNet code >> will be up to date with the latest production code. Only style >> issues are remaining. Still future

RE: [lustre-devel] [PATCH 00/10] Last batch of fixes for LNet

>On Fri, Mar 04, 2016 at 09:09:40PM -0500, James Simmons wrote: >> This batch merges the remaining LNet patches from the OpenSFS >> branch for the upstream client. Once merged the LNet code >> will be up to date with the latest production code. Only style >> issues are remaining. Still future

RE: [lustre-devel] [PATCH 00/27] Third batch of LNet fixes

>On Wed, Mar 02, 2016 at 05:01:43PM -0500, James Simmons wrote: >> This patch set merges all the fixes for the klnd drivers, socklnd and >> o2iblnd, to what is currently used in production environments. Several >> more fixes for the LNet core are also included with this patch set. > >I've applied

RE: [lustre-devel] [PATCH 00/27] Third batch of LNet fixes

>On Wed, Mar 02, 2016 at 05:01:43PM -0500, James Simmons wrote: >> This patch set merges all the fixes for the klnd drivers, socklnd and >> o2iblnd, to what is currently used in production environments. Several >> more fixes for the LNet core are also included with this patch set. > >I've applied

RE: [lustre-devel] [PATCH] staging: lustre: Support different ko2iblnd configs between systems

>On Wed, Mar 02, 2016 at 05:02:04PM -0500, James Simmons wrote: >> From: Jeremy Filizetti >> >> This patch adds suppoort for ko2iblnd to have different values for >> peer_credits and map_on_demand between systems. > >Your subject has no number for this patch, is it

RE: [lustre-devel] [PATCH] staging: lustre: Support different ko2iblnd configs between systems

>On Wed, Mar 02, 2016 at 05:02:04PM -0500, James Simmons wrote: >> From: Jeremy Filizetti >> >> This patch adds suppoort for ko2iblnd to have different values for >> peer_credits and map_on_demand between systems. > >Your subject has no number for this patch, is it really patch 21 in the

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

>On Fri, Feb 26, 2016 at 06:11:07AM +, Drokin, Oleg wrote: >> >> 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

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

>On Fri, Feb 26, 2016 at 06:11:07AM +, Drokin, Oleg wrote: >> >> 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

RE: [lustre-devel] [PATCH 5/7] staging:lustre: simplify libcfs_psdev_[open|release]

>> diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c >> b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c >> index 33f6036..64f0fbf 100644 >> --- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c >> +++

RE: [lustre-devel] [PATCH 06/11] staging: lustre: add missing spaces for LNet layer reported by checkpatch.pl

>On Fri, 2016-02-12 at 12:06 -0500, James Simmons wrote: >> Add missing spaces in the code reported by checkpatch.pl. >[] >> diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h >> b/drivers/staging/lustre/include/linux/lnet/lib-types.h >[] >> @@ -112,7 +112,7 @@ typedef struct

RE: [lustre-devel] [PATCH 06/11] staging: lustre: add missing spaces for LNet layer reported by checkpatch.pl

>On Fri, 2016-02-12 at 12:06 -0500, James Simmons wrote: >> Add missing spaces in the code reported by checkpatch.pl. >[] >> diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h >> b/drivers/staging/lustre/include/linux/lnet/lib-types.h >[] >> @@ -112,7 +112,7 @@ typedef struct

RE: [lustre-devel] [PATCH 5/7] staging:lustre: simplify libcfs_psdev_[open|release]

>> diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c >> b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c >> index 33f6036..64f0fbf 100644 >> --- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c >> +++

RE: [lustre-devel] [PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported by sparse

>>>2. Is it OK to hardcode the appropriate gfp_t flags for the >>>IOC_LIBCFS_MEMHOG, as the userspace >>>seems to be taking the decision about the page allocation >>>zone/strategy, is this what is intended? >> >> The memhog functionality is used to introduce memory pressure on a client >> or

RE: [lustre-devel] [PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported by sparse

>> On Wed, Dec 09, 2015 at 10:38:13PM +0530, Niranjan Dighe wrote: >>> The third argument to function kportal_memhog_alloc is expected to >>> be gfp_t whereas the actual argument was unsigned int. Fix this by >>> explicitly typecasting to gfp_t >>> >>> Signed-off-by: Niranjan Dighe >>> --- >>>

RE: [lustre-devel] [PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported by sparse

>> On Wed, Dec 09, 2015 at 10:38:13PM +0530, Niranjan Dighe wrote: >>> The third argument to function kportal_memhog_alloc is expected to >>> be gfp_t whereas the actual argument was unsigned int. Fix this by >>> explicitly typecasting to gfp_t >>> >>> Signed-off-by: Niranjan Dighe

RE: [lustre-devel] [PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported by sparse

>>>2. Is it OK to hardcode the appropriate gfp_t flags for the >>>IOC_LIBCFS_MEMHOG, as the userspace >>>seems to be taking the decision about the page allocation >>>zone/strategy, is this what is intended? >> >> The memhog functionality is used to introduce memory pressure on a client >> or

RE: [lustre-devel] [PATCH] staging: lustre: Remove unused memhog functionality

>On 2015/12/23, 14:40, "Simmons, James A." wrote: > >>>From: Niranjan Dighe >>> >>>Remove IOC_LIBCFS_MEMHOG ioctl functionality as it is no longer needed >>>thereby >>>making functions like - kportal_memhog_alloc(), kportal_memhog_

RE: [lustre-devel] [PATCH] staging: lustre: Remove unused memhog functionality

>From: Niranjan Dighe > >Remove IOC_LIBCFS_MEMHOG ioctl functionality as it is no longer needed thereby >making functions like - kportal_memhog_alloc(), kportal_memhog_free() and type >- >struct libcfs_device_userstate unused. Actually so much more can be cleaned up. This work is also being

RE: [lustre-devel] [PATCH] staging: lustre: Remove unused memhog functionality

>On 2015/12/23, 14:40, "Simmons, James A." <simmon...@ornl.gov> wrote: > >>>From: Niranjan Dighe <ndi...@visteon.com> >>> >>>Remove IOC_LIBCFS_MEMHOG ioctl functionality as it is no longer needed >>>thereby >>>making f

RE: [lustre-devel] [PATCH] staging: lustre: Remove unused memhog functionality

>From: Niranjan Dighe > >Remove IOC_LIBCFS_MEMHOG ioctl functionality as it is no longer needed thereby >making functions like - kportal_memhog_alloc(), kportal_memhog_free() and type >- >struct libcfs_device_userstate unused. Actually so much more can be cleaned up. This

RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

>On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote: >> >> >> struct libcfs_ioctl_hdr { >> >> __u32 ioc_len; >> >> @@ -87,6 +88,13 @@ do { \ >> >> data.ioc_hdr.ioc_l

RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

>On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote: >> >> >> struct libcfs_ioctl_hdr { >> >> __u32 ioc_len; >> >> @@ -87,6 +88,13 @@ do { \ >> >> data.ioc_hdr.ioc_l

RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

>> struct libcfs_ioctl_hdr { >> __u32 ioc_len; >> @@ -87,6 +88,13 @@ do { \ >> data.ioc_hdr.ioc_len = sizeof(data);\ >> } while (0) >> >> +#define LIBCFS_IOC_INIT_V2(data, hdr) \ >> +do {

RE: [PATCH 02/40] staging: lustre: fix 'NULL pointer dereference' errors for LNet

>> diff --git a/drivers/staging/lustre/lnet/selftest/conctl.c >> b/drivers/staging/lustre/lnet/selftest/conctl.c >> index 556c837..2ca7d0e 100644 >> --- a/drivers/staging/lustre/lnet/selftest/conctl.c >> +++ b/drivers/staging/lustre/lnet/selftest/conctl.c >> @@ -679,45 +679,46 @@ static int >>

RE: [PATCH 21/40] staging: lustre: improve LNet clean up code and API

>Actually we're going to have to redo so much code that it's not worth it >for me to review the rest of these patches. Sorry I didn't get back to you sooner but I was on vacation. Thanks for reviewing this work. Especially since this is the first major bug fixing merge for the lustre client

RE: [PATCH 02/40] staging: lustre: fix 'NULL pointer dereference' errors for LNet

>> diff --git a/drivers/staging/lustre/lnet/selftest/conctl.c >> b/drivers/staging/lustre/lnet/selftest/conctl.c >> index 556c837..2ca7d0e 100644 >> --- a/drivers/staging/lustre/lnet/selftest/conctl.c >> +++ b/drivers/staging/lustre/lnet/selftest/conctl.c >> @@ -679,45 +679,46 @@ static int >>

RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

>> struct libcfs_ioctl_hdr { >> __u32 ioc_len; >> @@ -87,6 +88,13 @@ do { \ >> data.ioc_hdr.ioc_len = sizeof(data);\ >> } while (0) >> >> +#define LIBCFS_IOC_INIT_V2(data, hdr) \ >> +do {

RE: [PATCH 21/40] staging: lustre: improve LNet clean up code and API

>Actually we're going to have to redo so much code that it's not worth it >for me to review the rest of these patches. Sorry I didn't get back to you sooner but I was on vacation. Thanks for reviewing this work. Especially since this is the first major bug fixing merge for the lustre client

RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

>On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote: >> >> >> struct libcfs_ioctl_hdr { >> >> __u32 ioc_len; >> >> @@ -87,6 +88,13 @@ do { \ >> >> data.ioc_hdr.ioc_l

RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

>On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote: >> >> >> struct libcfs_ioctl_hdr { >> >> __u32 ioc_len; >> >> @@ -87,6 +88,13 @@ do { \ >> >> data.ioc_hdr.ioc_l

RE: [lustre-devel] [PATCH] staging: lustre: Handle nodemask on UMP machines

>On Sun, Nov 08, 2015 at 11:34:55AM -0500, James Simmons wrote: >> For UMP and SMP machines the struct cfs_cpt_table are >> defined differently. In the case handled by this patch >> nodemask is defined as a integer for the UMP case and >> as a pointer for the SMP case. This will cause a problem >>

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

>> 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 >> --- >> .../staging/lustre/lustre/libcfs/libcfs_string.c |1 + >> 1 files

RE: [lustre-devel] next-20151101 - depmod issues with Lustre modules

>Reproduced on mainline v4.3-9038-g27eb427bdc0960 with >Arch Linux default config (attached): > >depmod: ERROR: Found 2 modules in dependency cycles! >depmod: ERROR: Cycle detected: lnet -> libcfs -> lnet >make: *** [_modinst_post] Error 1 I submitted a patch (staging: lustre: remove

RE: [PATCH 8/9] Staging: lustre: llite_lib: Remove wrapper function

>On Mon, Nov 9, 2015 at 7:07 PM, Michał Kępień wrote: >>> Remove the function ll_finish_md_op_data() and replace all its calls >>> with the standrd function ll_finish_md_op_data(). >> >> I believe you meant to write "standard function kfree()". >> > >Yes. I am so sorry. Should I be sending the

RE: [lustre-devel] next-20151101 - depmod issues with Lustre modules

>Reproduced on mainline v4.3-9038-g27eb427bdc0960 with >Arch Linux default config (attached): > >depmod: ERROR: Found 2 modules in dependency cycles! >depmod: ERROR: Cycle detected: lnet -> libcfs -> lnet >make: *** [_modinst_post] Error 1 I submitted a patch (staging: lustre: remove

RE: [PATCH 8/9] Staging: lustre: llite_lib: Remove wrapper function

>On Mon, Nov 9, 2015 at 7:07 PM, Michał Kępień wrote: >>> Remove the function ll_finish_md_op_data() and replace all its calls >>> with the standrd function ll_finish_md_op_data(). >> >> I believe you meant to write "standard function kfree()". >> > >Yes. I am so sorry. Should

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

>> 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 >> --- >> .../staging/lustre/lustre/libcfs/libcfs_string.c |

RE: [lustre-devel] [PATCH] staging: lustre: Handle nodemask on UMP machines

>On Sun, Nov 08, 2015 at 11:34:55AM -0500, James Simmons wrote: >> For UMP and SMP machines the struct cfs_cpt_table are >> defined differently. In the case handled by this patch >> nodemask is defined as a integer for the UMP case and >> as a pointer for the SMP case. This will cause a problem >>

RE: [lustre-devel] [PATCH 07/10] staging: lustre: Handle nodemask on UMP machines

>All warnings (new ones prefixed by >>): > > In file included from include/linux/bitops.h:36:0, >from > drivers/staging/lustre/lustre/libcfs/../../include/linux/libcfs/linux/libcfs.h:44, >from >

RE: [lustre-devel] [PATCH] staging: lustre: lnet: klnds: socklnd: Move extern declarations to header

>From: lustre-devel [mailto:lustre-devel-boun...@lists.lustre.org] On Behalf Of >Amitoj Kaur Chawla >Sent: Friday, November 06, 2015 9:57 AM >To: oleg.dro...@intel.com; andreas.dil...@intel.com; >gre...@linuxfoundation.org; lustre-de...@lists.lustre.org; >de...@driverdev.osuosl.org;

RE: [PATCH] Staging: lustre: dir: Remove wrapper function

>From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 11:55 AM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com; linux-kernel@vger.kernel.org;

RE: [PATCH 1/3] Staging: lustre: module: Replace function calls

>From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:18 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com; linux-kernel@vger.kernel.org >Subject:

RE: [PATCH 2/3] Staging: lustre: tracefile: Remove wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:19 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 1/3] Staging: lustre: ldlm_pool: Remove unneeded wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:43 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 2/3] Staging: lustre: ldlm_pool: Drop wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:44 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 3/3] Staging: lustre: ldlm_pool: Drop unneeded wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:45 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 3/3] Staging: lustre: ldlm_pool: Drop unneeded wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:45 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 1/3] Staging: lustre: ldlm_pool: Remove unneeded wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:43 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 2/3] Staging: lustre: ldlm_pool: Drop wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:44 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 2/3] Staging: lustre: tracefile: Remove wrapper function

>-Original Message- >From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:19 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com;

RE: [PATCH 1/3] Staging: lustre: module: Replace function calls

>From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 12:18 PM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com; linux-kernel@vger.kernel.org >Subject:

RE: [PATCH] Staging: lustre: dir: Remove wrapper function

>From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf >Of Shivani Bhardwaj >Sent: Friday, November 06, 2015 11:55 AM >To: gre...@linuxfoundation.org >Cc: oleg.dro...@intel.com; de...@driverdev.osuosl.org; >andreas.dil...@intel.com; linux-kernel@vger.kernel.org;

RE: [lustre-devel] [PATCH] staging: lustre: lnet: klnds: socklnd: Move extern declarations to header

>From: lustre-devel [mailto:lustre-devel-boun...@lists.lustre.org] On Behalf Of >Amitoj Kaur Chawla >Sent: Friday, November 06, 2015 9:57 AM >To: oleg.dro...@intel.com; andreas.dil...@intel.com; >gre...@linuxfoundation.org; lustre-de...@lists.lustre.org; >de...@driverdev.osuosl.org;

RE: [lustre-devel] [PATCH 07/10] staging: lustre: Handle nodemask on UMP machines

>All warnings (new ones prefixed by >>): > > In file included from include/linux/bitops.h:36:0, >from > drivers/staging/lustre/lustre/libcfs/../../include/linux/libcfs/linux/libcfs.h:44, >from >

RE: [lustre-devel] [PATCH v2 1/7] staging: lustre: remove white space in libcfs_hash.h

>On Tue, Nov 03, 2015 at 07:46:07PM -0800, Greg Kroah-Hartman wrote: >> On Mon, Nov 02, 2015 at 12:22:07PM -0500, James Simmons wrote: >> > Cleanup all the unneeded white space in libcfs_hash.h. >> > >> > Signed-off-by: James Simmons >> > --- >> > .../lustre/include/linux/libcfs/libcfs_hash.h

RE: [PATCH v2 1/7] staging: lustre: remove white space in libcfs_hash.h

>On Mon, Nov 02, 2015 at 12:22:07PM -0500, James Simmons wrote: >> Cleanup all the unneeded white space in libcfs_hash.h. >> >> Signed-off-by: James Simmons >> --- >> .../lustre/include/linux/libcfs/libcfs_hash.h | 135 >> ++-- >> 1 files changed, 70 insertions(+), 65

RE: [lustre-devel] [PATCH v2 1/7] staging: lustre: remove white space in libcfs_hash.h

>On Tue, Nov 03, 2015 at 07:46:07PM -0800, Greg Kroah-Hartman wrote: >> On Mon, Nov 02, 2015 at 12:22:07PM -0500, James Simmons wrote: >> > Cleanup all the unneeded white space in libcfs_hash.h. >> > >> > Signed-off-by: James Simmons >> > --- >> >

RE: [PATCH v2 1/7] staging: lustre: remove white space in libcfs_hash.h

>On Mon, Nov 02, 2015 at 12:22:07PM -0500, James Simmons wrote: >> Cleanup all the unneeded white space in libcfs_hash.h. >> >> Signed-off-by: James Simmons >> --- >> .../lustre/include/linux/libcfs/libcfs_hash.h | 135 >> ++-- >> 1 files changed,

RE: [PATCH] staging:lustre: Prevent duplicate CT registrations

>On Fri, Oct 23, 2015 at 03:59:14PM -0400, James Simmons wrote: >> diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c >> b/drivers/staging/lustre/lustre/lmv/lmv_obd.c >> index 635a93c..d6d70d8 100644 >> --- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c >> +++

RE: [lustre-devel] [PATCH 1/3] staging: lustre: checkpatch cleanups for nidstring.c

>Yeah. That is often the fastest way to fix all the checkpatch warnings. > >Checkpatch warnings are pretty mechanical. Just send like 100 patches >at a time until everything is fixed. Don't overthink. Say your patch >breaks the alignment then you have to fix that, but otherwise only fix >one

RE: [lustre-devel] [PATCH 1/3] staging: lustre: checkpatch cleanups for nidstring.c

>Yeah. That is often the fastest way to fix all the checkpatch warnings. > >Checkpatch warnings are pretty mechanical. Just send like 100 patches >at a time until everything is fixed. Don't overthink. Say your patch >breaks the alignment then you have to fix that, but otherwise only fix >one

RE: [PATCH] staging:lustre: Prevent duplicate CT registrations

>On Fri, Oct 23, 2015 at 03:59:14PM -0400, James Simmons wrote: >> diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c >> b/drivers/staging/lustre/lustre/lmv/lmv_obd.c >> index 635a93c..d6d70d8 100644 >> --- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c >> +++

RE: [lustre-devel] [PATCH 1/3] staging: lustre: checkpatch cleanups for nidstring.c

>On Thu, Oct 29, 2015 at 07:28:21PM -0400, James Simmons wrote: >> With nidstring now having the latest fixes we can >> now clean up all the remaining checkpatch errors >> for nidstring.c. > >Please be specific as to exactly what you changed, and break it up into >one-patch-per-thing. And no,

RE: [lustre-devel] [PATCH 1/3] staging: lustre: checkpatch cleanups for nidstring.c

>On Thu, Oct 29, 2015 at 07:28:21PM -0400, James Simmons wrote: >> With nidstring now having the latest fixes we can >> now clean up all the remaining checkpatch errors >> for nidstring.c. > >Please be specific as to exactly what you changed, and break it up into >one-patch-per-thing. And no,

RE: [lustre-devel] [PATCH 09/10] staging: lustre: fix remaining checkpatch issues for libcfs_hash.h

>>diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h >>b/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h >>index 5df8ba2..563b2b4 100644 >>--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h >>+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h

RE: [lustre-devel] [PATCH 08/10] staging: lustre: remove white space in libcfs_hash.h

>>struct cfs_hash_bd { >>- struct cfs_hash_bucket *bd_bucket; /**< address of bucket */ >>- unsigned intbd_offset; /**< offset in bucket */ >>+ /**< address of bucket */ >>+ struct cfs_hash_bucket *bd_bucket; >>+ /**< offset in bucket */ >>+ unsigned

RE: [lustre-devel] [PATCH 08/10] staging: lustre: remove white space in libcfs_hash.h

>>struct cfs_hash_bd { >>- struct cfs_hash_bucket *bd_bucket; /**< address of bucket */ >>- unsigned intbd_offset; /**< offset in bucket */ >>+ /**< address of bucket */ >>+ struct cfs_hash_bucket *bd_bucket; >>+ /**< offset in bucket */ >>+ unsigned

RE: [lustre-devel] [PATCH 09/10] staging: lustre: fix remaining checkpatch issues for libcfs_hash.h

>>diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h >>b/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h >>index 5df8ba2..563b2b4 100644 >>--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h >>+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h

RE: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

>Fixed- Return of an errno should typically be negative (ie: return -EAGAIN) > >Signed-off-by: Nilesh Kokane >--- > drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) Bad idea. I also made this mistake and it broke LNet

RE: [PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)

>Fixed- Return of an errno should typically be negative (ie: return -EAGAIN) > >Signed-off-by: Nilesh Kokane >--- > drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) Bad idea. I also made this

RE: [lustre-devel] [PATCH] staging/lustre: fix block comment formatting

>Running checkpatch.pl on lnet/klnds/o2iblnd/o2iblnd.h produces several >"Block comments use a trailing */ on a separate line" warnings. This patch >fixes these. These fixes are just plain ugly. Is this change a requirement? .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 90

RE: [lustre-devel] [PATCH] staging/lustre: fix block comment formatting

Running checkpatch.pl on lnet/klnds/o2iblnd/o2iblnd.h produces several Block comments use a trailing */ on a separate line warnings. This patch fixes these. These fixes are just plain ugly. Is this change a requirement? .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 90

RE: [lustre-devel] LIBCFS_ALLOC

>> >Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even >> >a tiny sliver of RAM isn't going to work. It's easier to use >> >libcfs_kvzalloc() everywhere, but it's probably the wrong thing. >> >> The original reason we have the vmalloc water mark wasn't so much the >> issue

RE: [lustre-devel] LIBCFS_ALLOC

Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even a tiny sliver of RAM isn't going to work. It's easier to use libcfs_kvzalloc() everywhere, but it's probably the wrong thing. The original reason we have the vmalloc water mark wasn't so much the issue of memory

RE: LIBCFS_ALLOC

>Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even >a tiny sliver of RAM isn't going to work. It's easier to use >libcfs_kvzalloc() everywhere, but it's probably the wrong thing. The original reason we have the vmalloc water mark wasn't so much the issue of memory

RE: LIBCFS_ALLOC

Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even a tiny sliver of RAM isn't going to work. It's easier to use libcfs_kvzalloc() everywhere, but it's probably the wrong thing. The original reason we have the vmalloc water mark wasn't so much the issue of memory exhaustion

RE: [PATCH v4 4/9] staging:lustre: merge socklnd_lib-linux.h into socklnd.h

>> > diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h >> > b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h >> > index 53275f9..7125eb9 100644 >> > --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h >> > +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h >> > @@

RE: [PATCH v4 4/9] staging:lustre: merge socklnd_lib-linux.h into socklnd.h

>On Thu, Jun 25, 2015 at 3:33 AM, Guenter Roeck wrote: >> I have not tested it, but I think the following may fix the problem >> while avoiding any include problems. Since pt_regs is used in the file, >> one could argue that it should be declared. > >Indeed. I tried that, but... > >> -- >> diff

RE: [PATCH v4 4/9] staging:lustre: merge socklnd_lib-linux.h into socklnd.h

On Thu, Jun 25, 2015 at 3:33 AM, Guenter Roeck li...@roeck-us.net wrote: I have not tested it, but I think the following may fix the problem while avoiding any include problems. Since pt_regs is used in the file, one could argue that it should be declared. Indeed. I tried that, but... --

RE: [PATCH v4 4/9] staging:lustre: merge socklnd_lib-linux.h into socklnd.h

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h index 53275f9..7125eb9 100644 --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h @@ -25,16 +25,40 @@

RE: [lustre-devel] [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure

>> Yes. I know Al's thoughts and kernel style. >> >> But Alan Cox and Andreas have both said they think (x == NULL) can help >> you avoid some kind of boolean vs pointer bugs. I've had co-workers who >> did massive seds changing !foo to foo == NULL on our code base. But >> I've never seen a

RE: [lustre-devel] [PATCH 01/12] staging: lustre: fid: Use !x to check for kzalloc failure

Yes. I know Al's thoughts and kernel style. But Alan Cox and Andreas have both said they think (x == NULL) can help you avoid some kind of boolean vs pointer bugs. I've had co-workers who did massive seds changing !foo to foo == NULL on our code base. But I've never seen a real life

RE: [HPDD-discuss] [PATCH 1/1] staging: lustre/lustre/llite: get rid of incorrect type warning

>>On Wed, Jun 10, 2015 at 5:48 PM, Greg Kroah-Hartman > wrote: >> >> Are you sure all of these are correct? The kernel/user api for lustre >> is a complex beast, and just casting away the pointer types isn't >> usually the proper thing to do in order to resolve the issues here. >> >> thanks, >>

RE: [HPDD-discuss] [PATCH 1/1] staging: lustre/lustre/llite: get rid of incorrect type warning

On Wed, Jun 10, 2015 at 5:48 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: Are you sure all of these are correct? The kernel/user api for lustre is a complex beast, and just casting away the pointer types isn't usually the proper thing to do in order to resolve the issues here.

RE: [lustre-devel] [PATCH v3 7/8] staging:lustre: style cleanups for LNet headers

>We're going through and re-indenting things. I think just one space >between type and name is the right thing for .c files but you guys >really should figure out what style you're using for your header files. This is good to know. I didn't know how you felt about the lustre style. I will fix it

RE: [lustre-devel] [PATCH v3 5/8] staging:lustre: separate kernel and user land defines in the LNet headers

>On 2015/06/05, 3:02 AM, "Dan Carpenter" wrote: > >>On Wed, Jun 03, 2015 at 04:43:24PM -0400, James Simmons wrote: >>> Currently the lnet headers used by user land contain various internal >>> LNet structures that are only used by kernel space. Move the user land >>> structures to headers used by

  1   2   >