From andreas.dilger at intel.com  Wed Nov  1 02:01:58 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Wed, 1 Nov 2017 02:01:58 +0000
Subject: [lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t'
 with '__u32' and 'uint64_t' with '__u64'.
In-Reply-To: <20171029175839.GA19864@home>
References: <20171029175839.GA19864@home>
Message-ID: <3344B573-4839-4174-A267-B637D7F9C2B8@intel.com>

On Oct 30, 2017, at 01:58, Roman Storozhenko <romeusmeister at gmail.com> wrote:
> 
> There are two reasons for that:
> 1) As Linus Torvalds said we should use kernel types:
> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
> 
> 2) There are only few places in the lustre codebase that use such types.
> In the most cases it uses '__u32' and '__u64'.
> 
> Signed-off-by: Roman Storozhenko <romeusmeister at gmail.com>

Reviewed-by: Andreas Dilger <andreas.dilger at intel.com>

> ---
> drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
> drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
> drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
> drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
> 4 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/lustre_sec.h b/drivers/staging/lustre/lustre/include/lustre_sec.h
> index 03a970b..c616ae5 100644
> --- a/drivers/staging/lustre/lustre/include/lustre_sec.h
> +++ b/drivers/staging/lustre/lustre/include/lustre_sec.h
> @@ -340,8 +340,8 @@ void sptlrpc_conf_client_adapt(struct obd_device *obd);
> #define SPTLRPC_MAX_PAYLOAD     (1024)
> 
> struct vfs_cred {
> -	uint32_t	vc_uid;
> -	uint32_t	vc_gid;
> +	__u32	vc_uid;
> +	__u32	vc_gid;
> };
> 
> struct ptlrpc_ctx_ops {
> diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> index f9d9a16..9a98a95 100644
> --- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
> +++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> @@ -383,7 +383,7 @@ int cl_sb_fini(struct super_block *sb)
> struct vvp_pgcache_id {
> 	unsigned int		 vpi_bucket;
> 	unsigned int		 vpi_depth;
> -	uint32_t		 vpi_index;
> +	__u32			 vpi_index;
> 
> 	unsigned int		 vpi_curdep;
> 	struct lu_object_header *vpi_obj;
> diff --git a/drivers/staging/lustre/lustre/lov/lov_internal.h b/drivers/staging/lustre/lustre/lov/lov_internal.h
> index a21f074..49a106c 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_internal.h
> +++ b/drivers/staging/lustre/lustre/lov/lov_internal.h
> @@ -114,19 +114,19 @@ static inline const struct lsm_operations *lsm_op_find(int magic)
> */
> #if BITS_PER_LONG == 64
> # define lov_do_div64(n, base) ({					\
> -	uint64_t __base = (base);					\
> -	uint64_t __rem;							\
> -	__rem = ((uint64_t)(n)) % __base;				\
> -	(n) = ((uint64_t)(n)) / __base;					\
> +	__u64 __base = (base);						\
> +	__u64 __rem;							\
> +	__rem = ((__u64)(n)) % __base;				\
> +	(n) = ((__u64)(n)) / __base;					\
> 	__rem;								\
> })
> #elif BITS_PER_LONG == 32
> # define lov_do_div64(n, base) ({					\
> -	uint64_t __rem;							\
> +	__u64 __rem;							\
> 	if ((sizeof(base) > 4) && (((base) & 0xffffffff00000000ULL) != 0)) {  \
> 		int __remainder;					      \
> 		LASSERTF(!((base) & (LOV_MIN_STRIPE_SIZE - 1)), "64 bit lov " \
> -			 "division %llu / %llu\n", (n), (uint64_t)(base));    \
> +			 "division %llu / %llu\n", (n), (__u64)(base));    \
> 		__remainder = (n) & (LOV_MIN_STRIPE_SIZE - 1);		\
> 		(n) >>= LOV_MIN_STRIPE_BITS;				\
> 		__rem = do_div(n, (base) >> LOV_MIN_STRIPE_BITS);	\
> diff --git a/drivers/staging/lustre/lustre/osc/osc_internal.h b/drivers/staging/lustre/lustre/osc/osc_internal.h
> index a536908..92d2e1f 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_internal.h
> +++ b/drivers/staging/lustre/lustre/osc/osc_internal.h
> @@ -167,9 +167,9 @@ struct osc_device {
> 
> 	/* Write stats is actually protected by client_obd's lock. */
> 	struct osc_stats {
> -		uint64_t     os_lockless_writes;	  /* by bytes */
> -		uint64_t     os_lockless_reads;	   /* by bytes */
> -		uint64_t     os_lockless_truncates;       /* by times */
> +		__u64     os_lockless_writes;	  /* by bytes */
> +		__u64     os_lockless_reads;	   /* by bytes */
> +		__u64     os_lockless_truncates;       /* by times */
> 	} od_stats;
> 
> 	/* configuration item(s) */
> -- 
> 2.7.4
> 

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







From gregkh at linuxfoundation.org  Fri Nov  3 11:46:18 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 3 Nov 2017 12:46:18 +0100
Subject: [lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t'
 with '__u32' and 'uint64_t' with '__u64'.
In-Reply-To: <20171029175839.GA19864@home>
References: <20171029175839.GA19864@home>
Message-ID: <20171103114618.GA11059@kroah.com>

On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
> There are two reasons for that:
> 1) As Linus Torvalds said we should use kernel types:
> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
> 
> 2) There are only few places in the lustre codebase that use such types.
> In the most cases it uses '__u32' and '__u64'.

The __ types are only needed for when you cross the user/kernel boundry.
Otherwise just use the "normal" types of u32 and u64.

Do the changes you made here all cross that boundry?  If not, please fix
this up.

thanks,

greg k-h

From romeusmeister at gmail.com  Fri Nov  3 12:36:58 2017
From: romeusmeister at gmail.com (Roman Storozhenko)
Date: Fri, 3 Nov 2017 15:36:58 +0300
Subject: [lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t'
 with '__u32' and 'uint64_t' with '__u64'.
In-Reply-To: <20171103114618.GA11059@kroah.com>
References: <20171029175839.GA19864@home>
 <20171103114618.GA11059@kroah.com>
Message-ID: <20171103123658.GA21148@home>

On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
> > There are two reasons for that:
> > 1) As Linus Torvalds said we should use kernel types:
> > http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
> > 
> > 2) There are only few places in the lustre codebase that use such types.
> > In the most cases it uses '__u32' and '__u64'.
> 
> The __ types are only needed for when you cross the user/kernel boundry.
> Otherwise just use the "normal" types of u32 and u64.
> 
> Do the changes you made here all cross that boundry?  If not, please fix
> this up.

Thanks, Greg.

I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?

> 
> thanks,
> 
> greg k-h

From andreas.dilger at intel.com  Thu Nov  9 10:06:10 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Thu, 9 Nov 2017 10:06:10 +0000
Subject: [lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t'
 with '__u32' and 'uint64_t' with '__u64'.
In-Reply-To: <20171103123658.GA21148@home>
References: <20171029175839.GA19864@home> <20171103114618.GA11059@kroah.com>
 <20171103123658.GA21148@home>
Message-ID: <D397582D-545E-4C40-8A51-1F208F5E1883@intel.com>

On Nov 3, 2017, at 06:36, Roman Storozhenko <romeusmeister at gmail.com> wrote:
> 
> On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
>> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
>>> There are two reasons for that:
>>> 1) As Linus Torvalds said we should use kernel types:
>>> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
>>> 
>>> 2) There are only few places in the lustre codebase that use such types.
>>> In the most cases it uses '__u32' and '__u64'.
>> 
>>> drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
>>> drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
>>> drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
>>> drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
>>> 4 files changed, 12 insertions(+), 12 deletions(-)
>> 
>> The __ types are only needed for when you cross the user/kernel boundry.
>> Otherwise just use the "normal" types of u32 and u64.
>> 
>> Do the changes you made here all cross that boundry?  If not, please fix
>> this up.
> 
> Thanks, Greg.
> 
> I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?

Sorry for not getting back to you sooner, I was traveling.

I'm not sure what you mean by the .h files aren't used in client code?
I checked all of the headers, and all of the structures that were changed,
and they all looked to be in use.

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







From romeusmeister at gmail.com  Thu Nov  9 10:57:13 2017
From: romeusmeister at gmail.com (Roman Storozhenko)
Date: Thu, 9 Nov 2017 13:57:13 +0300
Subject: [lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t'
 with '__u32' and 'uint64_t' with '__u64'.
In-Reply-To: <D397582D-545E-4C40-8A51-1F208F5E1883@intel.com>
References: <20171029175839.GA19864@home> <20171103114618.GA11059@kroah.com>
 <20171103123658.GA21148@home> <D397582D-545E-4C40-8A51-1F208F5E1883@intel.com>
Message-ID: <CALsPMBM=478SNripBus-2P0MsKr16nMCATxuxey=iFnpCeeJxw@mail.gmail.com>

On Thu, Nov 9, 2017 at 1:06 PM, Dilger, Andreas
<andreas.dilger at intel.com> wrote:
> On Nov 3, 2017, at 06:36, Roman Storozhenko <romeusmeister at gmail.com> wrote:
>>
>> On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
>>>> There are two reasons for that:
>>>> 1) As Linus Torvalds said we should use kernel types:
>>>> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
>>>>
>>>> 2) There are only few places in the lustre codebase that use such types.
>>>> In the most cases it uses '__u32' and '__u64'.
>>>
>>>> drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
>>>> drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
>>>> drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
>>>> drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
>>>> 4 files changed, 12 insertions(+), 12 deletions(-)
>>>
>>> The __ types are only needed for when you cross the user/kernel boundry.
>>> Otherwise just use the "normal" types of u32 and u64.
>>>
>>> Do the changes you made here all cross that boundry?  If not, please fix
>>> this up.
>>
>> Thanks, Greg.
>>
>> I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?
>
> Sorry for not getting back to you sooner, I was traveling.
>
> I'm not sure what you mean by the .h files aren't used in client code?
> I checked all of the headers, and all of the structures that were changed,
> and they all looked to be in use.

Thanks, Andreas. But let me clarify: did you mean that those
structures are being used in userspace code and this patch could be
accepted?
Or those structures are being used only in the kernel code and I
should change it according to Greg's remark?

Kind regards,
Roman

>
> Cheers, Andreas
> --
> Andreas Dilger
> Lustre Principal Architect
> Intel Corporation
>
>
>
>
>
>
>



-- 
Kind regards,
Roman

From tzw0019 at gmail.com  Thu Nov  9 21:09:31 2017
From: tzw0019 at gmail.com (Charles)
Date: Thu, 9 Nov 2017 13:09:31 -0800
Subject: [lustre-devel] obsolete Lustre file-joining feature
Message-ID: <CACvWVmtgQY8QhgJ4R+uz91qdcBXJg1j0m54G5cd40+fSyLodJg@mail.gmail.com>

Hi,

Seems like "lfs join" command is no longer supported in the version
2.7.2.25. Is there any alternative for this feature? For example, is there
any user-level Lustre API for this feature?

Thanks,
Teng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20171109/9610bf4b/attachment.html>

From andreas.dilger at intel.com  Fri Nov 10 00:38:53 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Fri, 10 Nov 2017 00:38:53 +0000
Subject: [lustre-devel] [lustre-discuss] obsolete Lustre file-joining
 feature
In-Reply-To: <CACvWVms62_8kbFLgPiBVo_KfHiHvqWEOg9JpKdK2BaRZKHZ3og@mail.gmail.com>
References: <CACvWVms62_8kbFLgPiBVo_KfHiHvqWEOg9JpKdK2BaRZKHZ3og@mail.gmail.com>
Message-ID: <DD4EDA04-6B42-417B-B191-3C7BB2081AD6@intel.com>

On Nov 9, 2017, at 14:05, teng wang <tzw0019 at gmail.com> wrote:
> 
> Hi,
> 
> Seems like "lfs join" command is no longer supported in the version 
> 2.7.2.25. Is there any alternative for this feature? For example, is there 
> any user-level Lustre API for this feature?

The "file join" feature was only experimental at best, and has not been available for years.  In Lustre 2.10 the "composite layout" feature
implements similar (though not identical) functionality.

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







From oleg.drokin at intel.com  Thu Nov  9 19:53:44 2017
From: oleg.drokin at intel.com (Oleg Drokin)
Date: Thu, 9 Nov 2017 14:53:44 -0500
Subject: [lustre-devel] New tag 2.10.55
Message-ID: <AC167227-4CAD-41FD-96E5-3032B3DF15FE@intel.com>

Hello!

   I tagged a new tag 2.10.55 in the Lustre master community development branch yesterday

   Here’s the changelog.

Alex Zhuravlev (4):
      LU-9660 ptlrpc: do not wakeup every second
      LU-9578 llite: use security context if it's enabled in the kernel
      LU-10041 osd: osd-zfs to choose dnode size
      LU-7251 osp: do not assign commit callback to every thandle

Alexander Boyko (4):
      LU-8344 test: fix sanity 256
      LU-4134 obdclass: obd_device improvement
      LU-8475 target: use slab allocation
      LU-10015 o2iblnd: fix race at kiblnd_connect_peer

Alexey Lyashkov (1):
      LU-9782 osd-ldiskfs: avoid extra search

Amir Shehata (2):
      LU-9990 lnet: add backwards compatibility for YAML config
      LU-10089 o2iblnd: use IB_MR_TYPE_SG_GAPS

Andreas Dilger (9):
      LU-9462 doc: update lfs setstripe man page and usage
      LU-4923 osd-ldiskfs: dirdata is not needed on MGS
      LU-7990 llite: increase whole-file readahead to RPC size
      LU-9452 ldlm: remove MSG_CONNECT_LIBCLIENT support
      LU-4705 mdc: improve mdc_enqueue() error message
      LU-10046 misc: replace LASSERT() with CLASSERT()
      LU-9611 lov: allow lov.*.stripe{size,count}=-1 param
      LU-7813 lov: rename LOV_MAGIC_V*_DEF to *_DEFINED
      LU-8174 mdt: remove use of typedef mds_reint_t

Ben Evans (1):
      LU-7988 hsm: wake up cdt when requests are empty

Bob Glossman (6):
      LU-10047 tests: stop skipping test_102 subtests
      LU-9469 ldiskfs: add additional attach_jinode call
      LU-9956 kernel: kernel upgrade [SLES12 SP3 4.4.82-6.3]
      LU-10023 kernel: kernel update [SLES12 SP3 4.4.82-6.9]
      LU-10142 kernel: kernel update RHEL7.4 [3.10.0-693.5.2.el7]
      LU-10164 kernel: kernel update [SLES12 SP3 4.4.92-6.18]

Bruno Faccini (1):
      LU-9994 obdclass: fix llog_cat_id2handle() error handling

Chris Horn (1):
      LU-10119 scripts: Correct shebang/hashpling format

Elena Gryaznova (1):
      LU-8721 tests: add parallel-scale fio test

Gu Zheng (1):
      LU-9951 lustre_compat: add wrapper function for posix_acl_update_mode

Henri Doreau (2):
      LU-9416 hsm: add kkuc before sending registration RPCs
      LU-10141 llapi: integer overflow in llapi_changelog_start

James Nunez (5):
      LU-9741 test: Correct check of stripe count for directories
      LU-9860 tests: Run command on MGS for conf-sanity 33a
      LU-9968 tests: correct stripe index sanity 300g
      LU-10101 tests: correct sanity-quota call to quota_error
      LU-10152 tests: reformat after conf-sanity test 99

James Simmons (4):
      LU-9019 ofd: migrate to 64 bit time
      LU-9897 utils: remove libcfsutils.a and libptlctl.a
      LU-8066 obd: migrate to ksets
      LU-9019 ldlm: migrate the rest of the code to 64 bit time

Jan Kara (1):
      LU-9558 llite: port lustre to unified handling of bdi

John L. Hammond (4):
      LU-9983 ko2iblnd: allow for discontiguous fragments
      LU-9405 utils: remove device path parsing from mount.lustre
      LU-10132 llite: handle xattr cache refill race
      LU-10086 libcfs: use dynamic minors for /dev/{lnet,obd}

Nathaniel Clark (5):
      LU-10051 build: Build with ZFS 0.7.2
      LU-9752 man: Reference zgenhostid instead of genhostid
      LU-10098 scripts: Fix mounted check in Lustre RA
      LU-10007 pacemaker: Use lctl and load lustre
      LU-10150 build: Build with ZFS 0.7.3

Oleg Drokin (1):
      New tag 2.10.55

Patrick Farrell (1):
      LU-10131 llite: Update i_nlink on unlink

Qian Yingjin (1):
      LU-9140 nrs: measure the runtime of dd directly

Sebastien Buisson (2):
      LU-9672 gss: fix expiration time of sunrpc cache
      LU-9946 nodemap: have fileset on default nodemap.

Steve Guminski (3):
      LU-5170 lfs: Standardize error messages in lfs_setstripe()
      LU-6051 utils: allow lfs_migrate to handle hard links
      LU-10199 utils: disable sanity test 56xb

Wang Shilong (1):
      LU-10029 osd-ldiskfs: make project inherit attr removeable

Wei Liu (1):
      LU-9158 test: Use project ID for project quota for quota_scan

Yang Sheng (2):
      LU-9908 tests: force umount client in test 70e, 41b, and 105
      LU-9814 ldiskfs: restore simple_strtol in prealloc

dilip krishnagiri (1):
      LU-9590 tests: remove replay-single tests from ALWAYS_EXCEPT

From andreas.dilger at intel.com  Mon Nov 13 17:04:25 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Mon, 13 Nov 2017 17:04:25 +0000
Subject: [lustre-devel] [PATCH] staging: lustre: Replaces 'uint32_t'
 with '__u32' and 'uint64_t' with '__u64'.
In-Reply-To: <CALsPMBM=478SNripBus-2P0MsKr16nMCATxuxey=iFnpCeeJxw@mail.gmail.com>
References: <20171029175839.GA19864@home> <20171103114618.GA11059@kroah.com>
 <20171103123658.GA21148@home>
 <D397582D-545E-4C40-8A51-1F208F5E1883@intel.com>
 <CALsPMBM=478SNripBus-2P0MsKr16nMCATxuxey=iFnpCeeJxw@mail.gmail.com>
Message-ID: <0B205750-7D5F-4976-8B3A-9E657AD4C5EA@intel.com>


> On Nov 9, 2017, at 03:57, Roman Storozhenko <romeusmeister at gmail.com> wrote:
> 
> On Thu, Nov 9, 2017 at 1:06 PM, Dilger, Andreas
> <andreas.dilger at intel.com> wrote:
>> On Nov 3, 2017, at 06:36, Roman Storozhenko <romeusmeister at gmail.com> wrote:
>>> 
>>> On Fri, Nov 03, 2017 at 12:46:18PM +0100, Greg Kroah-Hartman wrote:
>>>> On Sun, Oct 29, 2017 at 08:58:39PM +0300, Roman Storozhenko wrote:
>>>>> There are two reasons for that:
>>>>> 1) As Linus Torvalds said we should use kernel types:
>>>>> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
>>>>> 
>>>>> 2) There are only few places in the lustre codebase that use such types.
>>>>> In the most cases it uses '__u32' and '__u64'.
>>>> 
>>>>> drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
>>>>> drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
>>>>> drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
>>>>> drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
>>>>> 4 files changed, 12 insertions(+), 12 deletions(-)
>>>> 
>>>> The __ types are only needed for when you cross the user/kernel boundry.
>>>> Otherwise just use the "normal" types of u32 and u64.
>>>> 
>>>> Do the changes you made here all cross that boundry?  If not, please fix
>>>> this up.
>>> 
>>> Thanks, Greg.
>>> 
>>> I have checked lustre repository and it seems that changed ".h" files aren't used in client code. But I realise that I could be mistaken. That why I want to ask lustre guys: am I right?
>> 
>> Sorry for not getting back to you sooner, I was traveling.
>> 
>> I'm not sure what you mean by the .h files aren't used in client code?
>> I checked all of the headers, and all of the structures that were changed,
>> and they all looked to be in use.
> 
> Thanks, Andreas. But let me clarify: did you mean that those
> structures are being used in userspace code and this patch could be
> accepted?
> Or those structures are being used only in the kernel code and I
> should change it according to Greg's remark?

These headers are for kernel code only, so should use the "u32" and similar
types, rather than the "__u32" that are used for user-kernel structures.

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







From romeusmeister at gmail.com  Fri Nov 17 11:46:18 2017
From: romeusmeister at gmail.com (Roman Storozhenko)
Date: Fri, 17 Nov 2017 14:46:18 +0300
Subject: [lustre-devel] [PATCH v2] Replace 'uint32_t' with 'u32' and
 'uint64_t' with 'u64'
Message-ID: <20171117114618.GA26318@home>

There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html

2) There are only few places in the lustre codebase that use such types.
In the most cases it uses 'u32' and 'u64'.

Signed-off-by: Roman Storozhenko <romeusmeister at gmail.com>

---
In the first version of this patch I replaced 'uint32_t' with '__u32' and
'uint64_t' with '__u64'. I was suggested to fix that by Greg K-H:

"The __ types are only needed for when you cross the user/kernel boundry.
Otherwise just use the "normal" types of u32 and u64.

Do the changes you made here all cross that boundry?  If not, please fix
this up."

I asked lustre community whether those code used only in the kernel
space and Andreas Dilger said:

"These headers are for kernel code only, so should use the "u32" and
similar
types, rather than the "__u32" that are used for user-kernel
structures."

So I have replaced my first patch version with this one.

 drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
 drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
 drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
 drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_sec.h b/drivers/staging/lustre/lustre/include/lustre_sec.h
index a40f706..64b6fd4 100644
--- a/drivers/staging/lustre/lustre/include/lustre_sec.h
+++ b/drivers/staging/lustre/lustre/include/lustre_sec.h
@@ -341,8 +341,8 @@ void sptlrpc_conf_client_adapt(struct obd_device *obd);
 #define SPTLRPC_MAX_PAYLOAD     (1024)
 
 struct vfs_cred {
-	uint32_t	vc_uid;
-	uint32_t	vc_gid;
+	u32	vc_uid;
+	u32	vc_gid;
 };
 
 struct ptlrpc_ctx_ops {
diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c b/drivers/staging/lustre/lustre/llite/vvp_dev.c
index 8ccc8b7..987c03b 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
@@ -384,7 +384,7 @@ int cl_sb_fini(struct super_block *sb)
 struct vvp_pgcache_id {
 	unsigned int		 vpi_bucket;
 	unsigned int		 vpi_depth;
-	uint32_t		 vpi_index;
+	u32			 vpi_index;
 
 	unsigned int		 vpi_curdep;
 	struct lu_object_header *vpi_obj;
diff --git a/drivers/staging/lustre/lustre/lov/lov_internal.h b/drivers/staging/lustre/lustre/lov/lov_internal.h
index ae28ddf..a56d71c 100644
--- a/drivers/staging/lustre/lustre/lov/lov_internal.h
+++ b/drivers/staging/lustre/lustre/lov/lov_internal.h
@@ -115,19 +115,19 @@ static inline const struct lsm_operations *lsm_op_find(int magic)
  */
 #if BITS_PER_LONG == 64
 # define lov_do_div64(n, base) ({					\
-	uint64_t __base = (base);					\
-	uint64_t __rem;							\
-	__rem = ((uint64_t)(n)) % __base;				\
-	(n) = ((uint64_t)(n)) / __base;					\
+	u64 __base = (base);					\
+	u64 __rem;							\
+	__rem = ((u64)(n)) % __base;				\
+	(n) = ((u64)(n)) / __base;					\
 	__rem;								\
 })
 #elif BITS_PER_LONG == 32
 # define lov_do_div64(n, base) ({					\
-	uint64_t __rem;							\
+	u64 __rem;							\
 	if ((sizeof(base) > 4) && (((base) & 0xffffffff00000000ULL) != 0)) {  \
 		int __remainder;					      \
 		LASSERTF(!((base) & (LOV_MIN_STRIPE_SIZE - 1)), "64 bit lov " \
-			 "division %llu / %llu\n", (n), (uint64_t)(base));    \
+			 "division %llu / %llu\n", (n), (u64)(base));    \
 		__remainder = (n) & (LOV_MIN_STRIPE_SIZE - 1);		\
 		(n) >>= LOV_MIN_STRIPE_BITS;				\
 		__rem = do_div(n, (base) >> LOV_MIN_STRIPE_BITS);	\
diff --git a/drivers/staging/lustre/lustre/osc/osc_internal.h b/drivers/staging/lustre/lustre/osc/osc_internal.h
index feda61b..32db150 100644
--- a/drivers/staging/lustre/lustre/osc/osc_internal.h
+++ b/drivers/staging/lustre/lustre/osc/osc_internal.h
@@ -168,9 +168,9 @@ struct osc_device {
 
 	/* Write stats is actually protected by client_obd's lock. */
 	struct osc_stats {
-		uint64_t     os_lockless_writes;	  /* by bytes */
-		uint64_t     os_lockless_reads;	   /* by bytes */
-		uint64_t     os_lockless_truncates;       /* by times */
+		u64	os_lockless_writes;	  /* by bytes */
+		u64	os_lockless_reads;	  /* by bytes */
+		u64	os_lockless_truncates;    /* by times */
 	} od_stats;
 
 	/* configuration item(s) */
-- 
2.7.4

From andreas.dilger at intel.com  Fri Nov 17 22:27:10 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Fri, 17 Nov 2017 22:27:10 +0000
Subject: [lustre-devel] [PATCH v2] Replace 'uint32_t' with 'u32' and
 'uint64_t' with 'u64'
In-Reply-To: <20171117114618.GA26318@home>
References: <20171117114618.GA26318@home>
Message-ID: <36D3BDA1-FA6F-475D-9CF0-EBEAE1733756@intel.com>

On Nov 17, 2017, at 04:46, Roman Storozhenko <romeusmeister at gmail.com> wrote:
> 
> There are two reasons for that:
> 1) As Linus Torvalds said we should use kernel types:
> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
> 
> 2) There are only few places in the lustre codebase that use such types.
> In the most cases it uses 'u32' and 'u64'.
> 
> Signed-off-by: Roman Storozhenko <romeusmeister at gmail.com>

Reviewed-by: Andreas Dilger <andreas.dilger at intel.com>

> ---
> In the first version of this patch I replaced 'uint32_t' with '__u32' and
> 'uint64_t' with '__u64'. I was suggested to fix that by Greg K-H:
> 
> "The __ types are only needed for when you cross the user/kernel boundry.
> Otherwise just use the "normal" types of u32 and u64.
> 
> Do the changes you made here all cross that boundry?  If not, please fix
> this up."
> 
> I asked lustre community whether those code used only in the kernel
> space and Andreas Dilger said:
> 
> "These headers are for kernel code only, so should use the "u32" and
> similar
> types, rather than the "__u32" that are used for user-kernel
> structures."
> 
> So I have replaced my first patch version with this one.
> 
> drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
> drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
> drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
> drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
> 4 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/lustre_sec.h b/drivers/staging/lustre/lustre/include/lustre_sec.h
> index a40f706..64b6fd4 100644
> --- a/drivers/staging/lustre/lustre/include/lustre_sec.h
> +++ b/drivers/staging/lustre/lustre/include/lustre_sec.h
> @@ -341,8 +341,8 @@ void sptlrpc_conf_client_adapt(struct obd_device *obd);
> #define SPTLRPC_MAX_PAYLOAD     (1024)
> 
> struct vfs_cred {
> -	uint32_t	vc_uid;
> -	uint32_t	vc_gid;
> +	u32	vc_uid;
> +	u32	vc_gid;
> };
> 
> struct ptlrpc_ctx_ops {
> diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> index 8ccc8b7..987c03b 100644
> --- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
> +++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> @@ -384,7 +384,7 @@ int cl_sb_fini(struct super_block *sb)
> struct vvp_pgcache_id {
> 	unsigned int		 vpi_bucket;
> 	unsigned int		 vpi_depth;
> -	uint32_t		 vpi_index;
> +	u32			 vpi_index;
> 
> 	unsigned int		 vpi_curdep;
> 	struct lu_object_header *vpi_obj;
> diff --git a/drivers/staging/lustre/lustre/lov/lov_internal.h b/drivers/staging/lustre/lustre/lov/lov_internal.h
> index ae28ddf..a56d71c 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_internal.h
> +++ b/drivers/staging/lustre/lustre/lov/lov_internal.h
> @@ -115,19 +115,19 @@ static inline const struct lsm_operations *lsm_op_find(int magic)
>  */
> #if BITS_PER_LONG == 64
> # define lov_do_div64(n, base) ({					\
> -	uint64_t __base = (base);					\
> -	uint64_t __rem;							\
> -	__rem = ((uint64_t)(n)) % __base;				\
> -	(n) = ((uint64_t)(n)) / __base;					\
> +	u64 __base = (base);					\
> +	u64 __rem;							\
> +	__rem = ((u64)(n)) % __base;				\
> +	(n) = ((u64)(n)) / __base;					\
> 	__rem;								\
> })
> #elif BITS_PER_LONG == 32
> # define lov_do_div64(n, base) ({					\
> -	uint64_t __rem;							\
> +	u64 __rem;							\
> 	if ((sizeof(base) > 4) && (((base) & 0xffffffff00000000ULL) != 0)) {  \
> 		int __remainder;					      \
> 		LASSERTF(!((base) & (LOV_MIN_STRIPE_SIZE - 1)), "64 bit lov " \
> -			 "division %llu / %llu\n", (n), (uint64_t)(base));    \
> +			 "division %llu / %llu\n", (n), (u64)(base));    \
> 		__remainder = (n) & (LOV_MIN_STRIPE_SIZE - 1);		\
> 		(n) >>= LOV_MIN_STRIPE_BITS;				\
> 		__rem = do_div(n, (base) >> LOV_MIN_STRIPE_BITS);	\
> diff --git a/drivers/staging/lustre/lustre/osc/osc_internal.h b/drivers/staging/lustre/lustre/osc/osc_internal.h
> index feda61b..32db150 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_internal.h
> +++ b/drivers/staging/lustre/lustre/osc/osc_internal.h
> @@ -168,9 +168,9 @@ struct osc_device {
> 
> 	/* Write stats is actually protected by client_obd's lock. */
> 	struct osc_stats {
> -		uint64_t     os_lockless_writes;	  /* by bytes */
> -		uint64_t     os_lockless_reads;	   /* by bytes */
> -		uint64_t     os_lockless_truncates;       /* by times */
> +		u64	os_lockless_writes;	  /* by bytes */
> +		u64	os_lockless_reads;	  /* by bytes */
> +		u64	os_lockless_truncates;    /* by times */
> 	} od_stats;
> 
> 	/* configuration item(s) */
> -- 
> 2.7.4
> 

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







From me at tobin.cc  Thu Nov 23 04:59:26 2017
From: me at tobin.cc (Tobin C. Harding)
Date: Thu, 23 Nov 2017 15:59:26 +1100
Subject: [lustre-devel] [PATCH 0/4] staging: lustre: fixed some
 signedness warns from sparse
In-Reply-To: <20171122193831.11801-1-stefano.manni@gmail.com>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
Message-ID: <20171123045926.GD12736@eros>

On Wed, Nov 22, 2017 at 08:38:27PM +0100, Stefano Manni wrote:
> Fixed some signedness warnings from sparse on lustre.
> 
> Stefano Manni (4):
>   staging: lustre: fixed signedness of some socklnd params
>   staging: lustre: fixed signedness of llite
>   staging: lustre: fixed signedness of lov
>   staging: lustre: fixed signedness of obdclass

You may like to use imperative mood for your git log brief descriptions
Stefano.  

s/fixed/fix/

For justification see Documentation/process/submitting-patches.rst.

Specifically section 2 of that document.

Hope this helps,
Tobin.


>  drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h        |  4 ++--
>  .../staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c  |  2 +-
>  drivers/staging/lustre/lustre/llite/dir.c                  |  3 ++-
>  drivers/staging/lustre/lustre/llite/llite_lib.c            |  9 ++++++---
>  drivers/staging/lustre/lustre/llite/lproc_llite.c          | 14 ++++++--------
>  drivers/staging/lustre/lustre/lov/lov_obd.c                |  2 +-
>  drivers/staging/lustre/lustre/lov/lov_offset.c             | 11 +++++++----
>  drivers/staging/lustre/lustre/obdclass/obd_mount.c         |  2 +-
>  8 files changed, 26 insertions(+), 21 deletions(-)
> 
> -- 
> 2.5.5
> 
> _______________________________________________
> devel mailing list
> devel at linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

From dan.carpenter at oracle.com  Thu Nov 23 11:51:38 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 23 Nov 2017 14:51:38 +0300
Subject: [lustre-devel] [PATCH 0/4] staging: lustre: fixed some
 signedness warns from sparse
In-Reply-To: <20171123045926.GD12736@eros>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
 <20171123045926.GD12736@eros>
Message-ID: <20171123115138.5nku6epnct35mmha@mwanda>

On Thu, Nov 23, 2017 at 03:59:26PM +1100, Tobin C. Harding wrote:
> On Wed, Nov 22, 2017 at 08:38:27PM +0100, Stefano Manni wrote:
> > Fixed some signedness warnings from sparse on lustre.
> > 
> > Stefano Manni (4):
> >   staging: lustre: fixed signedness of some socklnd params
> >   staging: lustre: fixed signedness of llite
> >   staging: lustre: fixed signedness of lov
> >   staging: lustre: fixed signedness of obdclass
> 
> You may like to use imperative mood for your git log brief descriptions
> Stefano.  
> 
> s/fixed/fix/
> 

Someone once chewed me a second butt hole for not using the imperative
mood so I know some people care intensely about this but I think so long
as you can understand the description it's fine.  I will never send a
patch for that maintainer's subsystem again, btw, which is probably
grateful for and now I can poop twice as fast so we're both winners.

Especially in the 0/4 patch which is going to be discarded.  Who cares?

regards,
dan carpenter


From dan.carpenter at oracle.com  Thu Nov 23 12:13:06 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 23 Nov 2017 15:13:06 +0300
Subject: [lustre-devel] [PATCH 1/4] staging: lustre: fixed signedness of
 some socklnd params
In-Reply-To: <20171122193831.11801-2-stefano.manni@gmail.com>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
 <20171122193831.11801-2-stefano.manni@gmail.com>
Message-ID: <20171123121306.nu66ktiqjedongpp@mwanda>

On Wed, Nov 22, 2017 at 08:38:28PM +0100, Stefano Manni wrote:
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c
> index 5663a4c..2ad89ca 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_modparams.c
> @@ -43,7 +43,7 @@ MODULE_PARM_DESC(peer_timeout, "Seconds without aliveness news to declare peer d
>   * Number of daemons in each thread pool which is percpt,
>   * we will estimate reasonable value based on CPUs if it's not set.
>   */
> -static unsigned int nscheds;
> +static int nscheds;

I've looked through this series and I feel like none of these are real
bugs.  It's just about type safety and being consistent.  Which are good
things.  I'm not sure that I like the parts where we make the variables
signed.

Here "nscheds" is the number of threads.  How can we have a negative
number?  I think it should be unsigned.  It's way more tricky to change
the rest of the code, and leave nscheds unsigned int but I think it's
probably the right thing.

regards,
dan carpenter

From rick at globus.org  Thu Nov 23 19:00:12 2017
From: rick at globus.org (Rick Wagner)
Date: Thu, 23 Nov 2017 11:00:12 -0800
Subject: [lustre-devel] [lustre-discuss] strange time of reading for
 large file
In-Reply-To: <CY4PR06MB32554D7B2D35F990BD01F661BD210@CY4PR06MB3255.namprd06.prod.outlook.com>
References: <CY4PR06MB32554D7B2D35F990BD01F661BD210@CY4PR06MB3255.namprd06.prod.outlook.com>
Message-ID: <EA369C7B-467D-43EC-881A-9E2D2C8EA14F@globus.org>

Hi Rosana,

Without knowing anything about your setup or test, my first question would be whether you accounted for caching between your read tests? That can occur at several layers within the environment, including the client, server, and underlying storage hardware. This is naturally a benefit when in production, but needs to understand during performance testing. And I’m assuming that your file system was not otherwise utilized during your tests. Another assumption would be that the file system was mostly empty so that file fragmentation and disk seeks weren’t a problem.

—Rick

> On Nov 23, 2017, at 10:52 AM, Rosana Guimaraes Ribeiro <rosana_guimaraes_ at hotmail.com> wrote:
> 
> Hi,
> 
> I have some doubts about Lustre, I already sent my issues to forums but no one answer me.
> In our application, during the performance testing on lustre 2.4.2 we got times of reading and writing to test I/O operations with a file of almost 400GB. 
> Running this application a lot of times, consecutively, we see that in write operations, I/O time remain on same range, but in read operations there are a huge difference of time. As you can see below:
> Write time [sec]:
> 325.77
> 318.80
> 325.44
> 458.54
> 316.89
> 327.75
> 344.90
> 340.34
> 383.57
> 316.35
> Read time [sec]:
> 570.48
> 601.11
> 447.14
> 406.39
> 480.44
> 5824.40
> 299.40
> 293.54
> 1049.93
> 4190.47
> We ran on the single client with 1 process and tested on same infrastructure (hardware and network).
> Could you explain why is reading time so distorted? What kind of problem might be occurring?
> 
> Regards,
> Rosana
> 
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org <mailto:lustre-discuss at lists.lustre.org>
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org <http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20171123/becbaa9b/attachment.html>

From me at tobin.cc  Thu Nov 23 22:20:20 2017
From: me at tobin.cc (Tobin C. Harding)
Date: Fri, 24 Nov 2017 09:20:20 +1100
Subject: [lustre-devel] [PATCH 0/4] staging: lustre: fixed some
 signedness warns from sparse
In-Reply-To: <20171123115138.5nku6epnct35mmha@mwanda>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
 <20171123045926.GD12736@eros>
 <20171123115138.5nku6epnct35mmha@mwanda>
Message-ID: <20171123222020.GI12736@eros>

On Thu, Nov 23, 2017 at 02:51:38PM +0300, Dan Carpenter wrote:
> On Thu, Nov 23, 2017 at 03:59:26PM +1100, Tobin C. Harding wrote:
> > On Wed, Nov 22, 2017 at 08:38:27PM +0100, Stefano Manni wrote:
> > > Fixed some signedness warnings from sparse on lustre.
> > > 
> > > Stefano Manni (4):
> > >   staging: lustre: fixed signedness of some socklnd params
> > >   staging: lustre: fixed signedness of llite
> > >   staging: lustre: fixed signedness of lov
> > >   staging: lustre: fixed signedness of obdclass
> > 
> > You may like to use imperative mood for your git log brief descriptions
> > Stefano.  
> > 
> > s/fixed/fix/
> > 
> 
> Someone once chewed me a second butt hole for not using the imperative
> mood so I know some people care intensely about this but I think so long
> as you can understand the description it's fine.  I will never send a
> patch for that maintainer's subsystem again, btw, which is probably
> grateful for and now I can poop twice as fast so we're both winners.

I try to only make these suggestions to people doing clean up patches to
staging, with the reasoning that if we are learning we might as well
learn the correct method from the start.

I try to be polite and helpful, I am not very long past learning these
things myself. No one likes being told they are wrong, better to learn
how to take it while in staging, that's what it's there for right.

> Especially in the 0/4 patch which is going to be discarded.  Who cares?

Definitely agree for the 0/4 patch, doesn't _need_ imperative mood.

For the record, I love your short snappy reviews Dan. My current
favourite review of all time was done by you on a what was at the time a
pretty hard patch for me. It was

	Nope

I burst out laughing when I got that one. It spurred me on to greater
things (though I'm not sure everyone would be equally encouraged :)

All the best,
Tobin.

From dan.carpenter at oracle.com  Fri Nov 24 12:49:44 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Fri, 24 Nov 2017 15:49:44 +0300
Subject: [lustre-devel] [PATCH 1/4] staging: lustre: fixed signedness of
 some socklnd params
In-Reply-To: <1511480841.8829.3.camel@gmail.com>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
 <20171122193831.11801-2-stefano.manni@gmail.com>
 <20171123121306.nu66ktiqjedongpp@mwanda>
 <1511480841.8829.3.camel@gmail.com>
Message-ID: <20171124124944.qriokiaedpi4xjzp@mwanda>

On Fri, Nov 24, 2017 at 12:47:21AM +0100, Stefano Manni wrote:
> I've made the module param nsched signed because the
> ksock_tunables.ksnd_nscheds (the real container) is signed too.

Yeah.  I know.  And it's way more involved and controversial to change
ksock_tunables.

> 
> I definitely agree with you that it does not make sense to have a
> negative number of threads.
> In my opinion it's better to fix this inconsistency between the param
> and the container and then try submit another patch to harmonize
> signedness around the code.

No one will ever think about types again if Sparse stops complaining.
It's better to keep the error message instead of silencing it in a less
than ideal way because it means we have to think about types.
Eventually someone will get sick of the warning and write a huger patch
that rewrites a lot of code.

regards,
dan carpenter

From dan.carpenter at oracle.com  Fri Nov 24 13:02:09 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Fri, 24 Nov 2017 16:02:09 +0300
Subject: [lustre-devel] [PATCH 0/4] staging: lustre: fixed some
 signedness warns from sparse
In-Reply-To: <20171123222020.GI12736@eros>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
 <20171123045926.GD12736@eros>
 <20171123115138.5nku6epnct35mmha@mwanda>
 <20171123222020.GI12736@eros>
Message-ID: <20171124124511.g2rigyszy26t2ze3@mwanda>

On Fri, Nov 24, 2017 at 09:20:20AM +1100, Tobin C. Harding wrote:
> My current favourite review of all time was done by you on a what was
> at the time a pretty hard patch for me. It was
> 
> 	Nope
> 

Wow...  I know I've said that to other people but I can't believe I sent
that to *you*...  Sorry.  You write good patches.

regards,
dan carpenter


From gregkh at linuxfoundation.org  Fri Nov 24 15:42:47 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 24 Nov 2017 16:42:47 +0100
Subject: [lustre-devel] [PATCH 3/4] staging: lustre: fixed signedness of
 lov
In-Reply-To: <20171122193831.11801-4-stefano.manni@gmail.com>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
 <20171122193831.11801-4-stefano.manni@gmail.com>
Message-ID: <20171124154247.GA15000@kroah.com>

On Wed, Nov 22, 2017 at 08:38:30PM +0100, Stefano Manni wrote:
> sparse warning on lov_obd.c:
> warning: incorrect type in argument 3 (different signedness)
> expected int *res
> got unsigned int [usertype] *i
> 
> sparse warning on lov_offset.c:
> warning: incorrect type in argument 4 (different signedness)
> expected long long [usertype] *<noident>
> got unsigned long long *<noident>

Can you not line-wrap these sparse warning lines, it makes them hard to
read.  It's ok to leave them as very long lines in the changelog.

> 
> Signed-off-by: Stefano Manni <stefano.manni at gmail.com>
> ---
>  drivers/staging/lustre/lustre/lov/lov_obd.c    |  2 +-
>  drivers/staging/lustre/lustre/lov/lov_offset.c | 11 +++++++----
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c b/drivers/staging/lustre/lustre/lov/lov_obd.c
> index 7ce0102..3cccd79 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_obd.c
> +++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
> @@ -899,7 +899,7 @@ int lov_process_config_base(struct obd_device *obd, struct lustre_cfg *lcfg,
>  
>  		obd_str2uuid(&obd_uuid,  lustre_cfg_buf(lcfg, 1));
>  
> -		rc = kstrtoint(lustre_cfg_buf(lcfg, 2), 10, indexp);
> +		rc = kstrtouint(lustre_cfg_buf(lcfg, 2), 10, indexp);
>  		if (rc < 0)
>  			goto out;
>  		rc = kstrtoint(lustre_cfg_buf(lcfg, 3), 10, genp);
> diff --git a/drivers/staging/lustre/lustre/lov/lov_offset.c b/drivers/staging/lustre/lustre/lov/lov_offset.c
> index 3e16e64..954a01b 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_offset.c
> +++ b/drivers/staging/lustre/lustre/lov/lov_offset.c
> @@ -44,7 +44,7 @@ u64 lov_stripe_size(struct lov_stripe_md *lsm, u64 ost_size, int stripeno)
>  {
>  	unsigned long ssize = lsm->lsm_stripe_size;
>  	unsigned long stripe_size;
> -	u64 swidth;
> +	long long swidth;

This feels wrong, u64 should be used instead, can the code be fixed up
to use that type properly?  Don't rely on long long anywhere, it's hard
to always know what it should be on all arches...

Please fix up and resend this series based on the reviews you've gotten
so far.

thanks,

greg k-h

From gregkh at linuxfoundation.org  Fri Nov 24 15:43:41 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 24 Nov 2017 16:43:41 +0100
Subject: [lustre-devel] [PATCH 08/10] staging: lustre: lov: use
 list_for_each_entry in lov_obd.c
In-Reply-To: <150933956729.22133.13130557672702877610.stgit@noble>
References: <150933945578.22133.8029060522107378499.stgit@noble>
 <150933956729.22133.13130557672702877610.stgit@noble>
Message-ID: <20171124154341.GA16654@kroah.com>

On Mon, Oct 30, 2017 at 03:59:27PM +1100, NeilBrown wrote:
> Signed-off-by: NeilBrown <neilb at suse.com>
> ---
>  drivers/staging/lustre/lustre/lov/lov_obd.c |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)

I can't take patches with no changelog text at all, sorry.

greg k-h

From gregkh at linuxfoundation.org  Fri Nov 24 15:44:27 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 24 Nov 2017 16:44:27 +0100
Subject: [lustre-devel] [PATCH 00/10] staging: lustre: assorted code
 improvements for list manipulations.
In-Reply-To: <150933945578.22133.8029060522107378499.stgit@noble>
References: <150933945578.22133.8029060522107378499.stgit@noble>
Message-ID: <20171124154427.GA19111@kroah.com>

On Mon, Oct 30, 2017 at 03:59:27PM +1100, NeilBrown wrote:
> There are mostly conversions of list_for_each() to
> list_for_each_entry() and similar.  list_first_entry()
> also makes a few appearances.

I've taken the patches that had a changelog text.

thanks,

greg k-h

From me at tobin.cc  Fri Nov 24 21:37:09 2017
From: me at tobin.cc (Tobin C. Harding)
Date: Sat, 25 Nov 2017 08:37:09 +1100
Subject: [lustre-devel] [PATCH 0/4] staging: lustre: fixed some
 signedness warns from sparse
In-Reply-To: <20171124124511.g2rigyszy26t2ze3@mwanda>
References: <20171122193831.11801-1-stefano.manni@gmail.com>
 <20171123045926.GD12736@eros>
 <20171123115138.5nku6epnct35mmha@mwanda>
 <20171123222020.GI12736@eros>
 <20171124124511.g2rigyszy26t2ze3@mwanda>
Message-ID: <20171124213709.GH17858@eros>

On Fri, Nov 24, 2017 at 04:02:09PM +0300, Dan Carpenter wrote:
> On Fri, Nov 24, 2017 at 09:20:20AM +1100, Tobin C. Harding wrote:
> > My current favourite review of all time was done by you on a what was
> > at the time a pretty hard patch for me. It was
> > 
> > 	Nope
> > 
> 
> Wow...  I know I've said that to other people but I can't believe I sent
> that to *you*...  Sorry.  You write good patches.

Not always :) No apology needed, I was genuinely encouraged to tighten
my game.

thanks,
Tobin

From gregkh at linuxfoundation.org  Tue Nov 28 13:21:48 2017
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 28 Nov 2017 14:21:48 +0100
Subject: [lustre-devel] [PATCH 4/4] staging: most: Remove a attribute
 group from a kobject
In-Reply-To: <1511591971-8615-5-git-send-email-arvind.yadav.cs@gmail.com>
References: <1511591971-8615-1-git-send-email-arvind.yadav.cs@gmail.com>
 <1511591971-8615-5-git-send-email-arvind.yadav.cs@gmail.com>
Message-ID: <20171128132148.GA29890@kroah.com>

On Sat, Nov 25, 2017 at 12:09:31PM +0530, Arvind Yadav wrote:
> All attribute group created during dim2_sysfs_probe() should be removed
> in dim2_sysfs_destroy().
> 
> Signed-off-by: Arvind Yadav <arvind.yadav.cs at gmail.com>
> ---
>  drivers/staging/most/hdm-dim2/dim2_sysfs.c | 1 +

This file is not in the tree anymore.

From dan.carpenter at oracle.com  Tue Nov 28 13:51:08 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Tue, 28 Nov 2017 16:51:08 +0300
Subject: [lustre-devel] [bug report] staging: lustre: remove unnecessary
 NULL checks in kernel_comm.c
Message-ID: <20171128135108.hedez7bglpdidkky@mwanda>

Hi Lustre devs,

Smatch generates this warning:

	drivers/staging/lustre/lustre/obdclass/kernelcomm.c:146 libcfs_kkuc_group_rem()
	error: buffer overflow 'kkuc_groups' 3 <= u32max

drivers/staging/lustre/lustre/obdclass/kernelcomm.c
   142  int libcfs_kkuc_group_rem(int uid, unsigned int group)
   143  {
   144          struct kkuc_reg *reg, *next;
   145  
   146          if (!kkuc_groups[group].next)
                                 ^^^^^
Basically the complaint is that Smatch thinks "group" comes from the
user and hasn't been checked at all.

   147                  return 0;
   148  
   149          if (!uid) {
   150                  /* Broadcast a shutdown message */
   151                  struct kuc_hdr lh;
   152  

Where "group" comes from is lmv_iocontrol() in lmv_obd.c:

drivers/staging/lustre/lustre/lmv/lmv_obd.c
  1078          case LL_IOC_HSM_CT_START: {
  1079                  struct lustre_kernelcomm *lk = karg;
                                                  ^^^^^^^^^
  1080  
  1081                  if (lk->lk_flags & LK_FLG_STOP)
  1082                          rc = lmv_hsm_ct_unregister(lmv, cmd, len, lk, uarg);
                                                                          ^^
We take "karg" from somewhere get lk->lk_group here.

  1083                  else
  1084                          rc = lmv_hsm_ct_register(lmv, cmd, len, lk, uarg);
  1085                  break;
  1086          }

The problem is that, in Lustre, instead of functions we just have
ioctls.  Sometimes lmv_iocontrol() is called with validated data and
sometimes it's called with untrusted data.  Often with these kinds of
things I could just print the call tree to see where it's set to user
data and audit those places, but in Lustre the ioctls just call
themselves recursively so the call tree doesn't help.

And what I hate the most is obd_iocontrol().  Everything goes through
obd_iocontrol()...  It would be hard to design something which makes the
code more opaque than obd_iocontrol().

The bottom line, is I have no idea if this warning is correct or not.

regards,
dan carpenter

From dan.carpenter at oracle.com  Tue Nov 28 14:13:28 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Tue, 28 Nov 2017 17:13:28 +0300
Subject: [lustre-devel] [bug report] staging: lustre: remove unnecessary
 NULL checks in kernel_comm.c
In-Reply-To: <20171128135108.hedez7bglpdidkky@mwanda>
References: <20171128135108.hedez7bglpdidkky@mwanda>
Message-ID: <20171128141328.mf575s7rdab5kxql@mwanda>


Sorry for the bad subject line.

regards,
dan carpenter

From neilb at suse.com  Wed Nov 29 03:01:12 2017
From: neilb at suse.com (NeilBrown)
Date: Wed, 29 Nov 2017 14:01:12 +1100
Subject: [lustre-devel] [PATCH 08/10] staging: lustre: lov: use
 list_for_each_entry in lov_obd.c
In-Reply-To: <20171124154341.GA16654@kroah.com>
References: <150933945578.22133.8029060522107378499.stgit@noble>
 <150933956729.22133.13130557672702877610.stgit@noble>
 <20171124154341.GA16654@kroah.com>
Message-ID: <87r2shwzyf.fsf@notabene.neil.brown.name>

Subject: [PATCH] staging: lustre: lov: use list_for_each_entry in lov_obd.c

Using the *_entry macro simplifies the code slightly.

Signed-off-by: NeilBrown <neilb at suse.com>
---

Resubmitted with non-empty changelog text.

Thanks,
NeilBrown

 drivers/staging/lustre/lustre/lov/lov_obd.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c b/drivers/staging/lustre/lustre/lov/lov_obd.c
index 7ce01026a409..ec70c12e5b40 100644
--- a/drivers/staging/lustre/lustre/lov/lov_obd.c
+++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
@@ -828,11 +828,9 @@ int lov_setup(struct obd_device *obd, struct lustre_cfg *lcfg)
 static int lov_cleanup(struct obd_device *obd)
 {
 	struct lov_obd *lov = &obd->u.lov;
-	struct list_head *pos, *tmp;
-	struct pool_desc *pool;
+	struct pool_desc *pool, *tmp;
 
-	list_for_each_safe(pos, tmp, &lov->lov_pool_list) {
-		pool = list_entry(pos, struct pool_desc, pool_list);
+	list_for_each_entry_safe(pool, tmp, &lov->lov_pool_list, pool_list) {
 		/* free pool structs */
 		CDEBUG(D_INFO, "delete pool %p\n", pool);
 		/* In the function below, .hs_keycmp resolves to
-- 
2.14.0.rc0.dirty

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20171129/c4003335/attachment.sig>

From gregkh at linuxfoundation.org  Wed Nov 29 09:40:23 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 29 Nov 2017 10:40:23 +0100
Subject: [lustre-devel] [PATCH 08/10] staging: lustre: lov: use
 list_for_each_entry in lov_obd.c
In-Reply-To: <87r2shwzyf.fsf@notabene.neil.brown.name>
References: <150933945578.22133.8029060522107378499.stgit@noble>
 <150933956729.22133.13130557672702877610.stgit@noble>
 <20171124154341.GA16654@kroah.com>
 <87r2shwzyf.fsf@notabene.neil.brown.name>
Message-ID: <20171129094023.GA7597@kroah.com>

On Wed, Nov 29, 2017 at 02:01:12PM +1100, NeilBrown wrote:
> Subject: [PATCH] staging: lustre: lov: use list_for_each_entry in lov_obd.c

Why is there a subject line in the body of the text here?  Will git
figure this out correctly?

> Using the *_entry macro simplifies the code slightly.
> 
> Signed-off-by: NeilBrown <neilb at suse.com>
> ---
> 
> Resubmitted with non-empty changelog text.

Did I apply the others?  Can you just send a new series of whatever I
didn't apply so it's obvious for me as to what to do?

thanks,

greg k-h

From gregkh at linuxfoundation.org  Wed Nov 29 10:41:25 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 29 Nov 2017 11:41:25 +0100
Subject: [lustre-devel] [PATCH v2] Replace 'uint32_t' with 'u32' and
 'uint64_t' with 'u64'
In-Reply-To: <20171117114618.GA26318@home>
References: <20171117114618.GA26318@home>
Message-ID: <20171129104125.GA14678@kroah.com>

On Fri, Nov 17, 2017 at 02:46:18PM +0300, Roman Storozhenko wrote:
> There are two reasons for that:
> 1) As Linus Torvalds said we should use kernel types:
> http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html
> 
> 2) There are only few places in the lustre codebase that use such types.
> In the most cases it uses 'u32' and 'u64'.
> 
> Signed-off-by: Roman Storozhenko <romeusmeister at gmail.com>
> 
> ---
> In the first version of this patch I replaced 'uint32_t' with '__u32' and
> 'uint64_t' with '__u64'. I was suggested to fix that by Greg K-H:
> 
> "The __ types are only needed for when you cross the user/kernel boundry.
> Otherwise just use the "normal" types of u32 and u64.
> 
> Do the changes you made here all cross that boundry?  If not, please fix
> this up."
> 
> I asked lustre community whether those code used only in the kernel
> space and Andreas Dilger said:
> 
> "These headers are for kernel code only, so should use the "u32" and
> similar
> types, rather than the "__u32" that are used for user-kernel
> structures."
> 
> So I have replaced my first patch version with this one.

Please fix up the subject to have the subsystem and driver name in it:
	Subject: [PATCH] staging: lustre: ...

thanks,

greg k-h

From neilb at suse.com  Wed Nov 29 11:37:54 2017
From: neilb at suse.com (NeilBrown)
Date: Wed, 29 Nov 2017 22:37:54 +1100
Subject: [lustre-devel] [PATCH 08/10] staging: lustre: lov: use
 list_for_each_entry in lov_obd.c
In-Reply-To: <20171129094023.GA7597@kroah.com>
References: <150933945578.22133.8029060522107378499.stgit@noble>
 <150933956729.22133.13130557672702877610.stgit@noble>
 <20171124154341.GA16654@kroah.com> <87r2shwzyf.fsf@notabene.neil.brown.name>
 <20171129094023.GA7597@kroah.com>
Message-ID: <87bmjlwc19.fsf@notabene.neil.brown.name>

On Wed, Nov 29 2017, Greg Kroah-Hartman wrote:

> On Wed, Nov 29, 2017 at 02:01:12PM +1100, NeilBrown wrote:
>> Subject: [PATCH] staging: lustre: lov: use list_for_each_entry in lov_obd.c
>
> Why is there a subject line in the body of the text here?  Will git
> figure this out correctly?

Because I wanted to leave the original subject unchanged so it would be
fairly clear to you the context of the email, but also wanted to be
certain picked up the right subject (though in this case it would have
worked right anyway I think).
Yes, "git am" will see the Subject: line in the body and over-ride the
Subject line in the headers.

Thanks,
NeilBrown


>
>> Using the *_entry macro simplifies the code slightly.
>> 
>> Signed-off-by: NeilBrown <neilb at suse.com>
>> ---
>> 
>> Resubmitted with non-empty changelog text.
>
> Did I apply the others?  Can you just send a new series of whatever I
> didn't apply so it's obvious for me as to what to do?
>
> thanks,
>
> greg k-h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20171129/2003f661/attachment.sig>

From romeusmeister at gmail.com  Wed Nov 29 16:46:21 2017
From: romeusmeister at gmail.com (Roman Storozhenko)
Date: Wed, 29 Nov 2017 19:46:21 +0300
Subject: [lustre-devel] [PATCH v3] staging: lustre: Replace 'uint32_t' with
 'u32' and 'uint64_t' with 'u64'
Message-ID: <20171129164621.GA10881@home>

There are two reasons for that:
1) As Linus Torvalds said we should use kernel types:
http://lkml.iu.edu/hypermail//linux/kernel/1506.0/00160.html

2) There are only few places in the lustre codebase that use such types.
In the most cases it uses 'u32' and 'u64'.

Signed-off-by: Roman Storozhenko <romeusmeister at gmail.com>

---
In the second version of this patch I forgot to add subsystem and
driver. As Greg K-H mentioned:
"Please fix up the subject to have the subsystem and driver name in it:
        Subject: [PATCH] staging: lustre: ..."

In the first version of this patch I replaced 'uint32_t' with '__u32' and
'uint64_t' with '__u64'. I was suggested to fix that by Greg K-H:

"The __ types are only needed for when you cross the user/kernel boundry.
Otherwise just use the "normal" types of u32 and u64.

Do the changes you made here all cross that boundry?  If not, please fix
this up."

I asked lustre community whether those code used only in the kernel
space and Andreas Dilger said:

"These headers are for kernel code only, so should use the "u32" and
similar
types, rather than the "__u32" that are used for user-kernel
structures."

So I have replaced my first patch version with this one.

 drivers/staging/lustre/lustre/include/lustre_sec.h |  4 ++--
 drivers/staging/lustre/lustre/llite/vvp_dev.c      |  2 +-
 drivers/staging/lustre/lustre/lov/lov_internal.h   | 12 ++++++------
 drivers/staging/lustre/lustre/osc/osc_internal.h   |  6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_sec.h b/drivers/staging/lustre/lustre/include/lustre_sec.h
index a40f706..64b6fd4 100644
--- a/drivers/staging/lustre/lustre/include/lustre_sec.h
+++ b/drivers/staging/lustre/lustre/include/lustre_sec.h
@@ -341,8 +341,8 @@ void sptlrpc_conf_client_adapt(struct obd_device *obd);
 #define SPTLRPC_MAX_PAYLOAD     (1024)
 
 struct vfs_cred {
-	uint32_t	vc_uid;
-	uint32_t	vc_gid;
+	u32	vc_uid;
+	u32	vc_gid;
 };
 
 struct ptlrpc_ctx_ops {
diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c b/drivers/staging/lustre/lustre/llite/vvp_dev.c
index 8ccc8b7..987c03b 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
@@ -384,7 +384,7 @@ int cl_sb_fini(struct super_block *sb)
 struct vvp_pgcache_id {
 	unsigned int		 vpi_bucket;
 	unsigned int		 vpi_depth;
-	uint32_t		 vpi_index;
+	u32			 vpi_index;
 
 	unsigned int		 vpi_curdep;
 	struct lu_object_header *vpi_obj;
diff --git a/drivers/staging/lustre/lustre/lov/lov_internal.h b/drivers/staging/lustre/lustre/lov/lov_internal.h
index ae28ddf..a56d71c 100644
--- a/drivers/staging/lustre/lustre/lov/lov_internal.h
+++ b/drivers/staging/lustre/lustre/lov/lov_internal.h
@@ -115,19 +115,19 @@ static inline const struct lsm_operations *lsm_op_find(int magic)
  */
 #if BITS_PER_LONG == 64
 # define lov_do_div64(n, base) ({					\
-	uint64_t __base = (base);					\
-	uint64_t __rem;							\
-	__rem = ((uint64_t)(n)) % __base;				\
-	(n) = ((uint64_t)(n)) / __base;					\
+	u64 __base = (base);					\
+	u64 __rem;							\
+	__rem = ((u64)(n)) % __base;				\
+	(n) = ((u64)(n)) / __base;					\
 	__rem;								\
 })
 #elif BITS_PER_LONG == 32
 # define lov_do_div64(n, base) ({					\
-	uint64_t __rem;							\
+	u64 __rem;							\
 	if ((sizeof(base) > 4) && (((base) & 0xffffffff00000000ULL) != 0)) {  \
 		int __remainder;					      \
 		LASSERTF(!((base) & (LOV_MIN_STRIPE_SIZE - 1)), "64 bit lov " \
-			 "division %llu / %llu\n", (n), (uint64_t)(base));    \
+			 "division %llu / %llu\n", (n), (u64)(base));    \
 		__remainder = (n) & (LOV_MIN_STRIPE_SIZE - 1);		\
 		(n) >>= LOV_MIN_STRIPE_BITS;				\
 		__rem = do_div(n, (base) >> LOV_MIN_STRIPE_BITS);	\
diff --git a/drivers/staging/lustre/lustre/osc/osc_internal.h b/drivers/staging/lustre/lustre/osc/osc_internal.h
index feda61b..32db150 100644
--- a/drivers/staging/lustre/lustre/osc/osc_internal.h
+++ b/drivers/staging/lustre/lustre/osc/osc_internal.h
@@ -168,9 +168,9 @@ struct osc_device {
 
 	/* Write stats is actually protected by client_obd's lock. */
 	struct osc_stats {
-		uint64_t     os_lockless_writes;	  /* by bytes */
-		uint64_t     os_lockless_reads;	   /* by bytes */
-		uint64_t     os_lockless_truncates;       /* by times */
+		u64	os_lockless_writes;	  /* by bytes */
+		u64	os_lockless_reads;	  /* by bytes */
+		u64	os_lockless_truncates;    /* by times */
 	} od_stats;
 
 	/* configuration item(s) */
-- 
2.7.4

From andreas.dilger at intel.com  Thu Nov 30 00:45:03 2017
From: andreas.dilger at intel.com (Dilger, Andreas)
Date: Thu, 30 Nov 2017 00:45:03 +0000
Subject: [lustre-devel] [PATCH] staging: lustre: Check for
 register_shrinker() failure.
In-Reply-To: <1511962602-3840-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
References: <1511962602-3840-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
Message-ID: <440FDAB5-EEAD-4C44-9646-3DA33D811215@intel.com>

On Nov 29, 2017, at 06:36, Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> wrote:
> 
> register_shrinker() might return -ENOMEM error since Linux 3.12.
> Note that since callers are not always calling undo functions
> appropriately, error handling added by this patch might not be helpful.
> 
> Signed-off-by: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
> Cc: Oleg Drokin <oleg.drokin at intel.com>
> Cc: James Simmons <jsimmons at infradead.org>
> Cc: Michal Hocko <mhocko at suse.com>

Reviewed-by: Andreas Dilger <andreas.dilger at intel.com>


> ---
> drivers/staging/lustre/lustre/ldlm/ldlm_pool.c     | 7 +++++--
> drivers/staging/lustre/lustre/obdclass/lu_object.c | 4 +++-
> drivers/staging/lustre/lustre/osc/osc_request.c    | 4 +++-
> drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c    | 5 ++++-
> 4 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> index da65d00..7795ece 100644
> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> @@ -1086,8 +1086,11 @@ int ldlm_pools_init(void)
> 	int rc;
> 
> 	rc = ldlm_pools_thread_start();
> -	if (rc == 0)
> -		register_shrinker(&ldlm_pools_cli_shrinker);
> +	if (rc == 0) {
> +		rc = register_shrinker(&ldlm_pools_cli_shrinker);
> +		if (rc)
> +			ldlm_pools_thread_stop();
> +	}
> 
> 	return rc;
> }
> diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c b/drivers/staging/lustre/lustre/obdclass/lu_object.c
> index b938a3f..e19f0b9 100644
> --- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
> +++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
> @@ -1951,7 +1951,9 @@ int lu_global_init(void)
> 	 * inode, one for ea. Unfortunately setting this high value results in
> 	 * lu_object/inode cache consuming all the memory.
> 	 */
> -	register_shrinker(&lu_site_shrinker);
> +	result = register_shrinker(&lu_site_shrinker);
> +	if (result)
> +		lu_global_fini();
> 
> 	return result;
> }
> diff --git a/drivers/staging/lustre/lustre/osc/osc_request.c b/drivers/staging/lustre/lustre/osc/osc_request.c
> index 53eda4c..45b1ebf 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_request.c
> +++ b/drivers/staging/lustre/lustre/osc/osc_request.c
> @@ -2844,7 +2844,9 @@ static int __init osc_init(void)
> 	if (rc)
> 		goto out_kmem;
> 
> -	register_shrinker(&osc_cache_shrinker);
> +	rc = register_shrinker(&osc_cache_shrinker);
> +	if (rc)
> +		goto out_type;
> 
> 	/* This is obviously too much memory, only prevent overflow here */
> 	if (osc_reqpool_mem_max >= 1 << 12 || osc_reqpool_mem_max == 0) {
> diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c b/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
> index 77a3721..b85ae55 100644
> --- a/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
> +++ b/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
> @@ -432,7 +432,10 @@ int sptlrpc_enc_pool_init(void)
> 	if (!page_pools.epp_pools)
> 		return -ENOMEM;
> 
> -	register_shrinker(&pools_shrinker);
> +	if (register_shrinker(&pools_shrinker)) {
> +		enc_pools_free();
> +		return -ENOMEM;
> +	}
> 
> 	return 0;
> }
> -- 
> 1.8.3.1
> 

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







From dan.carpenter at oracle.com  Thu Nov 30 06:08:46 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 30 Nov 2017 09:08:46 +0300
Subject: [lustre-devel] [PATCH v3] staging: lustre: Replace 'uint32_t'
 with 'u32' and 'uint64_t' with 'u64'
In-Reply-To: <20171129164621.GA10881@home>
References: <20171129164621.GA10881@home>
Message-ID: <20171130060846.jghmmojo45ropbol@mwanda>

On Wed, Nov 29, 2017 at 07:46:21PM +0300, Roman Storozhenko wrote:
> There are two reasons for that:

In my email client the subject line and body are not next to each other.
It looks like this:

https://marc.info/?l=linux-arm-kernel&m=151187366315885&w=2

So it took me a while to realize what you were talking about.  Please
assume I'm either reading the subject or the body but not both.

regards,
dan carpenter