Re: [PATCH v2 6/6] staging: lustre: mdc: use large xattr buffers for old servers

On May 31, 2018, at 18:54, Greg Kroah-Hartman wrote: > > On Tue, May 29, 2018 at 10:21:45AM -0400, James Simmons wrote: >> From: "John L. Hammond" >> >> Pre 2.10.1 MDTs will crash when they receive a listxattr (MDS_GETXATTR >> with OBD_MD_FLXATTRLS) RPC for an orphan or dead object. So for >>

Re: [PATCH v2 6/6] staging: lustre: mdc: use large xattr buffers for old servers

On May 31, 2018, at 18:54, Greg Kroah-Hartman wrote: > > On Tue, May 29, 2018 at 10:21:45AM -0400, James Simmons wrote: >> From: "John L. Hammond" >> >> Pre 2.10.1 MDTs will crash when they receive a listxattr (MDS_GETXATTR >> with OBD_MD_FLXATTRLS) RPC for an orphan or dead object. So for >>

Re: [PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode

On May 16, 2018, at 02:00, Dan Carpenter wrote: > > On Tue, May 15, 2018 at 04:02:55PM +0100, James Simmons wrote: >> /* * Allocate new object. This may result in rather complicated * operations, including fld queries, inode loading, etc.

Re: [PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode

On May 16, 2018, at 02:00, Dan Carpenter wrote: > > On Tue, May 15, 2018 at 04:02:55PM +0100, James Simmons wrote: >> /* * Allocate new object. This may result in rather complicated * operations, including fld queries, inode loading, etc. */ o =

Re: [lustre-devel] [PATCH] staging: lustre: Fix an error handling path in 'client_common_fill_super()'

On May 12, 2018, at 00:33, Christophe JAILLET wrote: > > According to error handling path before and after this one, we should go > to 'out_md_fid' here, instead of 'out_md', if 'obd_connect()' fails. > > Signed-off-by: Christophe JAILLET

Re: [lustre-devel] [PATCH] staging: lustre: Fix an error handling path in 'client_common_fill_super()'

On May 12, 2018, at 00:33, Christophe JAILLET wrote: > > According to error handling path before and after this one, we should go > to 'out_md_fid' here, instead of 'out_md', if 'obd_connect()' fails. > > Signed-off-by: Christophe JAILLET Good catch. Reviewed-by: Andreas Dilger > --- >

Re: [lustre-devel] [PATCH] staging: lustre: fix spelling mistake: "req_ulinked" -> "req_unlinked"

On May 11, 2018, at 07:38, Colin King wrote: > > From: Colin Ian King > > Trivial fix to spelling mistake in DEBUG_REQ message text > > Signed-off-by: Colin Ian King Reviewed-by: Andreas Dilger

Re: [lustre-devel] [PATCH] staging: lustre: fix spelling mistake: "req_ulinked" -> "req_unlinked"

On May 11, 2018, at 07:38, Colin King wrote: > > From: Colin Ian King > > Trivial fix to spelling mistake in DEBUG_REQ message text > > Signed-off-by: Colin Ian King Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lustre/ptlrpc/client.c | 2 +- > 1 file changed, 1 insertion(+),

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

On May 3, 2018, at 22:19, Wenwen Wang wrote: > > On Tue, May 1, 2018 at 3:46 AM, Dan Carpenter > wrote: >> On Mon, Apr 30, 2018 at 05:56:10PM -0500, Wenwen Wang wrote: >>> However, given that the user data resides in the user space, a malicious >>>

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

On May 3, 2018, at 22:19, Wenwen Wang wrote: > > On Tue, May 1, 2018 at 3:46 AM, Dan Carpenter > wrote: >> On Mon, Apr 30, 2018 at 05:56:10PM -0500, Wenwen Wang wrote: >>> However, given that the user data resides in the user space, a malicious >>> user-space process can race to change the

Re: [PATCH 1/4] staging: lustre: obdclass: change spinlock of key to rwlock

On May 3, 2018, at 07:50, David Laight wrote: > > From: James Simmons >> Sent: 02 May 2018 19:22 >> From: Li Xi >> >> Most of the time, keys are never changed. So rwlock might be >> better for the concurrency of key read. > > OTOH unless there is

Re: [PATCH 1/4] staging: lustre: obdclass: change spinlock of key to rwlock

On May 3, 2018, at 07:50, David Laight wrote: > > From: James Simmons >> Sent: 02 May 2018 19:22 >> From: Li Xi >> >> Most of the time, keys are never changed. So rwlock might be >> better for the concurrency of key read. > > OTOH unless there is contention on the spin lock during reads the >

Re: [lustre-devel] [PATCH 04/10] staging: lustre: lu_object: move retry logic inside htable_lookup

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > The current retry logic, to wait when a 'dying' object is found, > spans multiple functions. The process is attached to a waitqueue > and set TASK_UNINTERRUPTIBLE in htable_lookup, and this status > is passed back through

Re: [lustre-devel] [PATCH 04/10] staging: lustre: lu_object: move retry logic inside htable_lookup

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > The current retry logic, to wait when a 'dying' object is found, > spans multiple functions. The process is attached to a waitqueue > and set TASK_UNINTERRUPTIBLE in htable_lookup, and this status > is passed back through lu_object_find_try() to

Re: [PATCH 03/10] staging: lustre: lu_object: discard extra lru count.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > lu_object maintains 2 lru counts. > One is a per-bucket lsb_lru_len. > The other is the per-cpu ls_lru_len_counter. > > The only times the per-bucket counters are use are: > - a debug message when an object is added > - in

Re: [PATCH 03/10] staging: lustre: lu_object: discard extra lru count.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > lu_object maintains 2 lru counts. > One is a per-bucket lsb_lru_len. > The other is the per-cpu ls_lru_len_counter. > > The only times the per-bucket counters are use are: > - a debug message when an object is added > - in lu_site_stats_get when

Re: [lustre-devel] [PATCH 02/10] staging: lustre: make struct lu_site_bkt_data private

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > This data structure only needs to be public so that > various modules can access a wait queue to wait for object > destruction. > If we provide a function to get the wait queue, rather than the > whole bucket, the structure can be

Re: [lustre-devel] [PATCH 02/10] staging: lustre: make struct lu_site_bkt_data private

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > This data structure only needs to be public so that > various modules can access a wait queue to wait for object > destruction. > If we provide a function to get the wait queue, rather than the > whole bucket, the structure can be made private. >

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

On Apr 30, 2018, at 16:56, Wenwen Wang wrote: > > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space > using Its address, i.e., lumv1 = If the lmm_magic field of lumv3 is > LOV_USER_MAGIC_V3, lumv3 will be modified by the second copy from the user >

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

On Apr 30, 2018, at 16:56, Wenwen Wang wrote: > > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space > using Its address, i.e., lumv1 = If the lmm_magic field of lumv3 is > LOV_USER_MAGIC_V3, lumv3 will be modified by the second copy from the user > space. The second copy

Re: [PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > Rather than storing the name of a namespace in the > hash table, store it directly in the namespace. > This will allow the hashtable to be changed to use > rhashtable. > > Signed-off-by: NeilBrown Reviewed-by:

Re: [PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > Rather than storing the name of a namespace in the > hash table, store it directly in the namespace. > This will allow the hashtable to be changed to use > rhashtable. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

Re: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv

On Apr 29, 2018, at 07:20, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > > On Sat, Apr 28, 2018 at 04:04:25PM +0000, Dilger, Andreas wrote: >> On Apr 27, 2018, at 17:45, Wenwen Wang <wang6...@umn.edu> wrote: >>> [PATCH] staging: luster: llite: fix

Re: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv

On Apr 29, 2018, at 07:20, Greg Kroah-Hartman wrote: > > On Sat, Apr 28, 2018 at 04:04:25PM +, Dilger, Andreas wrote: >> On Apr 27, 2018, at 17:45, Wenwen Wang wrote: >>> [PATCH] staging: luster: llite: fix potential missing-check bug when >>> copying lumv

Re: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv

On Apr 27, 2018, at 17:45, Wenwen Wang wrote: > [PATCH] staging: luster: llite: fix potential missing-check bug when copying > lumv (typo) s/luster/lustre/ > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space > using Its address, i.e., lumv1 = If the

Re: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv

On Apr 27, 2018, at 17:45, Wenwen Wang wrote: > [PATCH] staging: luster: llite: fix potential missing-check bug when copying > lumv (typo) s/luster/lustre/ > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space > using Its address, i.e., lumv1 = If the lmm_magic field of

Re: [lustre-devel] [PATCH 1/6] staging: lustre: move stack-check macros to libcfs_debug.h

On Apr 16, 2018, at 16:48, Doug Oucharek wrote: > >> >> On Apr 16, 2018, at 3:42 PM, James Simmons wrote: >> >> >>> James, >>> >>> If I understand correctly, you're saying you want to be able to build >>> without debug support...? I'm not

Re: [lustre-devel] [PATCH 1/6] staging: lustre: move stack-check macros to libcfs_debug.h

On Apr 16, 2018, at 16:48, Doug Oucharek wrote: > >> >> On Apr 16, 2018, at 3:42 PM, James Simmons wrote: >> >> >>> James, >>> >>> If I understand correctly, you're saying you want to be able to build >>> without debug support...? I'm not convinced that building a client without >>>

Re: [lustre-devel] [PATCH 11/17] staging: lustre: libcfs: discard cfs_time_shift().

On Apr 2, 2018, at 16:26, NeilBrown <ne...@suse.com> wrote: > On Mon, Apr 02 2018, Dilger, Andreas wrote: >> On Mar 30, 2018, at 13:02, James Simmons <jsimm...@infradead.org> wrote: >>>> This function simply multiplies by HZ and adds jiffies. >>>> Thi

Re: [lustre-devel] [PATCH 11/17] staging: lustre: libcfs: discard cfs_time_shift().

On Apr 2, 2018, at 16:26, NeilBrown wrote: > On Mon, Apr 02 2018, Dilger, Andreas wrote: >> On Mar 30, 2018, at 13:02, James Simmons wrote: >>>> This function simply multiplies by HZ and adds jiffies. >>>> This is simple enough to be opencoded, and doing so &

Re: [PATCH 13/17] staging: lustre: libcfs: remove cfs_timeout_cap()

On Mar 28, 2018, at 22:26, NeilBrown wrote: > > This wrapper is only used once, so open-code it as max(). > > This allows us to remove the libcfs_time.h include file. > > Signed-off-by: NeilBrown > --- > .../staging/lustre/include/linux/libcfs/libcfs.h |1

Re: [PATCH 13/17] staging: lustre: libcfs: remove cfs_timeout_cap()

On Mar 28, 2018, at 22:26, NeilBrown wrote: > > This wrapper is only used once, so open-code it as max(). > > This allows us to remove the libcfs_time.h include file. > > Signed-off-by: NeilBrown > --- > .../staging/lustre/include/linux/libcfs/libcfs.h |1 >

Re: [PATCH 11/17] staging: lustre: libcfs: discard cfs_time_shift().

> On Mar 30, 2018, at 13:02, James Simmons wrote: > > >> This function simply multiplies by HZ and adds jiffies. >> This is simple enough to be opencoded, and doing so >> makes the code easier to read. >> >> Same for cfs_time_shift_64() > > Reviewed-by: James Simmons

Re: [PATCH 11/17] staging: lustre: libcfs: discard cfs_time_shift().

> On Mar 30, 2018, at 13:02, James Simmons wrote: > > >> This function simply multiplies by HZ and adds jiffies. >> This is simple enough to be opencoded, and doing so >> makes the code easier to read. >> >> Same for cfs_time_shift_64() > > Reviewed-by: James Simmons Hmm, I thought we were

Re: [lustre-devel] [PATCH v2] staging: lustre: Remove VLA usage

On Mar 7, 2018, at 13:54, Kees Cook wrote: > > The kernel would like to have all stack VLA usage removed[1]. This switches > to a simple kasprintf() instead, and in the process fixes an off-by-one > between the allocation and the sprintf (allocation did not include NULL >

Re: [lustre-devel] [PATCH v2] staging: lustre: Remove VLA usage

On Mar 7, 2018, at 13:54, Kees Cook wrote: > > The kernel would like to have all stack VLA usage removed[1]. This switches > to a simple kasprintf() instead, and in the process fixes an off-by-one > between the allocation and the sprintf (allocation did not include NULL > byte in calculation). >

Re: [PATCH 17/17] Revert "staging: Disable lustre file system for MIPS, SH, and XTENSA"

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > This reverts commit 16f1eeb660bd2bfd223704ee6350706b39c55a7a. > > The reason for this patch was that lustre used copy_from_user_page. > Commit 76133e66b141 ("staging/lustre: Replace jobid acquiring with per > node setting") removed

Re: [PATCH 17/17] Revert "staging: Disable lustre file system for MIPS, SH, and XTENSA"

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > This reverts commit 16f1eeb660bd2bfd223704ee6350706b39c55a7a. > > The reason for this patch was that lustre used copy_from_user_page. > Commit 76133e66b141 ("staging/lustre: Replace jobid acquiring with per > node setting") removed that usage. > So

Re: [PATCH 16/17] staging: lustre: allow monolithic builds

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Remove restriction the lustre must be built > as modules. It now works as a monolithic build. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

Re: [PATCH 16/17] staging: lustre: allow monolithic builds

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Remove restriction the lustre must be built > as modules. It now works as a monolithic build. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lnet/Kconfig |2 +- >

Re: [PATCH 15/17] staging: lustre: ptlrpc: move thread creation out of module initialization

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > When the ptlrpc module is loaded, it starts the pinger thread and > calls LNetNIInit which starts various threads. > > We don't need these threads until the module is actually being > used, such as when a lustre filesystem is

Re: [PATCH 15/17] staging: lustre: ptlrpc: move thread creation out of module initialization

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > When the ptlrpc module is loaded, it starts the pinger thread and > calls LNetNIInit which starts various threads. > > We don't need these threads until the module is actually being > used, such as when a lustre filesystem is mounted. > > So move

Re: [PATCH 14/17] staging: lustre: change sai_thread to sai_task.

> On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Rather than allocating a ptlrpc_thread for the > stat-ahead thread, just use the task_struct provided > by kthreads directly. > > As nothing ever waits for the sai_task, it must call do_exit() > directly rather than simply return

Re: [PATCH 14/17] staging: lustre: change sai_thread to sai_task.

> On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Rather than allocating a ptlrpc_thread for the > stat-ahead thread, just use the task_struct provided > by kthreads directly. > > As nothing ever waits for the sai_task, it must call do_exit() > directly rather than simply return from the

Re: [PATCH 13/17] staging: lustre: remove 'ptlrpc_thread usage' for sai_agl_thread

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Lustre has a 'struct ptlrpc_thread' which provides > control functionality wrapped around kthreads. > None of the functionality used in statahead.c requires > ptlrcp_thread - it can all be done directly with kthreads. > > So discard

Re: [PATCH 13/17] staging: lustre: remove 'ptlrpc_thread usage' for sai_agl_thread

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Lustre has a 'struct ptlrpc_thread' which provides > control functionality wrapped around kthreads. > None of the functionality used in statahead.c requires > ptlrcp_thread - it can all be done directly with kthreads. > > So discard the

Re: [PATCH 12/17] staging: lustre: remove unused flag from ptlrpc_thread

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > SVC_EVENT is no longer used. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lustre/include/lustre_net.h | 11 --- > 1 file changed, 11

Re: [PATCH 12/17] staging: lustre: remove unused flag from ptlrpc_thread

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > SVC_EVENT is no longer used. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lustre/include/lustre_net.h | 11 --- > 1 file changed, 11 deletions(-) > > diff --git

Re: [PATCH 11/17] staging: lustre: ptlrpc: use workqueue for pinger

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > lustre has a "Pinger" kthread which periodically pings peers > to ensure all hosts are functioning. > > This can more easily be done using a work queue. > > As maintaining contact with other peers is import for > keeping the

Re: [PATCH 11/17] staging: lustre: ptlrpc: use workqueue for pinger

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > lustre has a "Pinger" kthread which periodically pings peers > to ensure all hosts are functioning. > > This can more easily be done using a work queue. > > As maintaining contact with other peers is import for > keeping the filesystem running,

Re: [PATCH 10/17] staging: lustre: ptlrpc: use delayed_work in sec_gc

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > The garbage collection for security contexts currently > has a dedicated kthread which wakes up every 30 minutes > to discard old garbage. > > Replace this with a simple delayed_work item on the > system work queue. > >

Re: [PATCH 10/17] staging: lustre: ptlrpc: use delayed_work in sec_gc

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > The garbage collection for security contexts currently > has a dedicated kthread which wakes up every 30 minutes > to discard old garbage. > > Replace this with a simple delayed_work item on the > system work queue. > > Signed-off-by: NeilBrown

Re: [PATCH 09/17] staging: lustre: ldlm: use delayed_work for pools_recalc

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > ldlm currenty has a kthread which wakes up every so often > and calls ldlm_pools_recalc(). > The thread is started and stopped, but no other external interactions > happen. > > This can trivially be replaced by a delayed_work if we

Re: [PATCH 09/17] staging: lustre: ldlm: use delayed_work for pools_recalc

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > ldlm currenty has a kthread which wakes up every so often > and calls ldlm_pools_recalc(). > The thread is started and stopped, but no other external interactions > happen. > > This can trivially be replaced by a delayed_work if we have >

Re: [PATCH 08/17] staging: lustre: obdclass: use workqueue for zombie management.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > obdclass currently maintains two lists of data structures > (imports and exports), and a kthread which will free > anything on either list. The thread is woken whenever > anything is added to either list. > > This is exactly the

Re: [PATCH 08/17] staging: lustre: obdclass: use workqueue for zombie management.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > obdclass currently maintains two lists of data structures > (imports and exports), and a kthread which will free > anything on either list. The thread is woken whenever > anything is added to either list. > > This is exactly the sort of thing that

Re: [PATCH 07/17] staging: lustre: ptlrpc: change GFP_NOFS to GFP_KERNEL

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > These allocations are performed during initialization, > so they don't need GFP_NOFS. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

Re: [PATCH 07/17] staging: lustre: ptlrpc: change GFP_NOFS to GFP_KERNEL

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > These allocations are performed during initialization, > so they don't need GFP_NOFS. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c |2 +- >

Re: [PATCH 06/17] staging: lustre: get entropy from nid when nid set.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > When the 'lustre' module is loaded, it gets a list of > net devices and uses the node ids to add entropy > to the prng. This means that the network interfaces need > to be configured before the module is loaded, which prevents >

Re: [PATCH 06/17] staging: lustre: get entropy from nid when nid set.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > When the 'lustre' module is loaded, it gets a list of > net devices and uses the node ids to add entropy > to the prng. This means that the network interfaces need > to be configured before the module is loaded, which prevents > the module from

Re: [PATCH 05/17] staging: lustre: lnet: keep ln_nportals consistent

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > ln_nportals should be zero when no portals have > been allocated. This ensures that memory allocation failure > is handled correctly elsewhere. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger

Re: [PATCH 05/17] staging: lustre: lnet: keep ln_nportals consistent

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > ln_nportals should be zero when no portals have > been allocated. This ensures that memory allocation failure > is handled correctly elsewhere. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

Re: [PATCH 04/17] staging: lustre: obdclass: don't require lct_owner to be non-NULL.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Some places in lu_object.c allow lct_owner to be NULL, implying > that the code is built in to the kernel (not a module), but > two places don't. This prevents us from building lustre into > the kernel. > > So remove the

Re: [PATCH 04/17] staging: lustre: obdclass: don't require lct_owner to be non-NULL.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Some places in lu_object.c allow lct_owner to be NULL, implying > that the code is built in to the kernel (not a module), but > two places don't. This prevents us from building lustre into > the kernel. > > So remove the requirement and always

Re: [PATCH 03/17] staging: lustre: statahead: remove incorrect test on agl_list_empty()

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Including agl_list_empty() in the wait_event_idle() condition > is pointless as the body of the loop doesn't do anything > about the agl list. > So if the list wasn't empty, the while loop would spin > indefinitely. > > The test was

Re: [PATCH 03/17] staging: lustre: statahead: remove incorrect test on agl_list_empty()

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Including agl_list_empty() in the wait_event_idle() condition > is pointless as the body of the loop doesn't do anything > about the agl list. > So if the list wasn't empty, the while loop would spin > indefinitely. > > The test was removed in the

Re: [PATCH 02/17] staging: lustre: fix bug in osc_enter_cache_try

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > The lustre-release patch commit bdc5bb52c554 ("LU-4933 osc: > Automatically increase the max_dirty_mb") changed > > - if (cli->cl_dirty + PAGE_CACHE_SIZE <= cli->cl_dirty_max && > + if (cli->cl_dirty_pages <

Re: [PATCH 02/17] staging: lustre: fix bug in osc_enter_cache_try

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > The lustre-release patch commit bdc5bb52c554 ("LU-4933 osc: > Automatically increase the max_dirty_mb") changed > > - if (cli->cl_dirty + PAGE_CACHE_SIZE <= cli->cl_dirty_max && > + if (cli->cl_dirty_pages < cli->cl_dirty_max_pages && >

Re: [PATCH 01/17] staging: lustre: obd_mount: use correct niduuid suffix.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Commit 4f016420d368 ("Staging: lustre: obdclass: Use kasprintf") moved > some sprintf() calls earlier in the code to combine them with > memory allocation and create kasprintf() calls. > > In one case, this code movement moved the

Re: [PATCH 01/17] staging: lustre: obd_mount: use correct niduuid suffix.

On Mar 1, 2018, at 16:31, NeilBrown wrote: > > Commit 4f016420d368 ("Staging: lustre: obdclass: Use kasprintf") moved > some sprintf() calls earlier in the code to combine them with > memory allocation and create kasprintf() calls. > > In one case, this code movement moved the sprintf to a

Re: [PATCH] staging: lustre: llite: replace variable length array

On Jan 27, 2018, at 14:42, Sven Dziadek wrote: > > The functionality of the removed variable length array is already > implemented by the function xattr_full_name in fs/xattr.c > > This fixes the sparse warning: > warning: Variable length array is used. > > Signed-off-by:

Re: [PATCH] staging: lustre: llite: replace variable length array

On Jan 27, 2018, at 14:42, Sven Dziadek wrote: > > The functionality of the removed variable length array is already > implemented by the function xattr_full_name in fs/xattr.c > > This fixes the sparse warning: > warning: Variable length array is used. > > Signed-off-by: Sven Dziadek > --- >

Re: [PATCH] staging: lustre: lnet: return of an error code should be negative

On Jan 27, 2018, at 22:24, Sumit Pundir wrote: > > Return value of error codes should typically be negative. > Issue reported by checkpatch.pl > > Signed-off-by: Sumit Pundir Reviewed-by: Andreas Dilger > --- >

Re: [PATCH] staging: lustre: lnet: return of an error code should be negative

On Jan 27, 2018, at 22:24, Sumit Pundir wrote: > > Return value of error codes should typically be negative. > Issue reported by checkpatch.pl > > Signed-off-by: Sumit Pundir Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lnet/selftest/framework.c | 2 +- > 1 file changed, 1

Re: [PATCH] staging: lustre: lnet/selftest: fix compile error on UP build

On Jan 22, 2018, at 23:27, NeilBrown wrote: > > When compiled without CONFIG_SMP, we get a compile error > as ->ctb_parts is not defined. > > There is already a function, cfs_cpt_cpumask(), which will get the > cpumask we need, and which handles the UP case by returning a NULL

Re: [PATCH] staging: lustre: lnet/selftest: fix compile error on UP build

On Jan 22, 2018, at 23:27, NeilBrown wrote: > > When compiled without CONFIG_SMP, we get a compile error > as ->ctb_parts is not defined. > > There is already a function, cfs_cpt_cpumask(), which will get the > cpumask we need, and which handles the UP case by returning a NULL pointer. > So use

Re: [PATCH v4] staging: lustre: separate a connection destroy from free struct kib_conn

On Jan 25, 2018, at 06:51, Eremin, Dmitry wrote: > > The logic of the original commit 4d99b2581eff ("staging: lustre: avoid > intensive reconnecting for ko2iblnd") was assumed conditional free of > struct kib_conn if the second argument free_conn in function >

Re: [PATCH v4] staging: lustre: separate a connection destroy from free struct kib_conn

On Jan 25, 2018, at 06:51, Eremin, Dmitry wrote: > > The logic of the original commit 4d99b2581eff ("staging: lustre: avoid > intensive reconnecting for ko2iblnd") was assumed conditional free of > struct kib_conn if the second argument free_conn in function > kiblnd_destroy_conn(struct kib_conn

Re: [PATCH 6/8] staging: lustre: Fix overlong lines

On Jan 11, 2018, at 10:17, Fabian Huegel wrote: > > Fixed four lines that went over the 80 character limit > to reduce checkpatch warnings. > > Signed-off-by: Fabian Huegel > Signed-off-by: Christoph Volkert > --- >

Re: [PATCH 6/8] staging: lustre: Fix overlong lines

On Jan 11, 2018, at 10:17, Fabian Huegel wrote: > > Fixed four lines that went over the 80 character limit > to reduce checkpatch warnings. > > Signed-off-by: Fabian Huegel > Signed-off-by: Christoph Volkert > --- > drivers/staging/lustre/lustre/include/obd_class.h | 14 ++ > 1

Re: [PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch

> On Jan 16, 2018, at 09:56, Greg Kroah-Hartman > wrote: > > On Tue, Jan 16, 2018 at 03:01:49PM +, Eremin, Dmitry wrote: >> In the original commit 4d99b2581effe115376402e710fbcb1c3c073769 > > Please use the documented way to write this: > 4d99b2581eff

Re: [PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch

> On Jan 16, 2018, at 09:56, Greg Kroah-Hartman > wrote: > > On Tue, Jan 16, 2018 at 03:01:49PM +, Eremin, Dmitry wrote: >> In the original commit 4d99b2581effe115376402e710fbcb1c3c073769 > > Please use the documented way to write this: > 4d99b2581eff ("staging: lustre: avoid

Re: [PATCH 1/2] staging: lustre: use strim instead of cfs_trimwhite.

On Dec 18, 2017, at 16:01, NeilBrown wrote: > > Linux lib provides identical functionality to cfs_trimwhite, > so discard that code and use the standard. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

Re: [PATCH 1/2] staging: lustre: use strim instead of cfs_trimwhite.

On Dec 18, 2017, at 16:01, NeilBrown wrote: > > Linux lib provides identical functionality to cfs_trimwhite, > so discard that code and use the standard. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- > .../lustre/include/linux/libcfs/libcfs_string.h|1 - >

Re: [PATCH 2/2] staging: lustre: disable preempt while sampling processor id.

On Dec 18, 2017, at 16:01, NeilBrown wrote: > > Calling smp_processor_id() without disabling preemption > triggers a warning (if CONFIG_DEBUG_PREEMPT). > I think the result of cfs_cpt_current() is only used as a hint for > load balancing, rather than as a precise and stable

Re: [PATCH 2/2] staging: lustre: disable preempt while sampling processor id.

On Dec 18, 2017, at 16:01, NeilBrown wrote: > > Calling smp_processor_id() without disabling preemption > triggers a warning (if CONFIG_DEBUG_PREEMPT). > I think the result of cfs_cpt_current() is only used as a hint for > load balancing, rather than as a precise and stable indicator of > the

Re: [lustre-devel] [PATCH 02/16] staging: lustre: replace simple cases of l_wait_event() with wait_event().

On Dec 18, 2017, at 11:03, Patrick Farrell wrote: > > The wait calls in ll_statahead_thread are done in a service thread, and > should probably *not* contribute to load. > > The one in osc_extent_wait is perhaps tough - It is called both from user > threads & daemon threads

Re: [lustre-devel] [PATCH 02/16] staging: lustre: replace simple cases of l_wait_event() with wait_event().

On Dec 18, 2017, at 11:03, Patrick Farrell wrote: > > The wait calls in ll_statahead_thread are done in a service thread, and > should probably *not* contribute to load. > > The one in osc_extent_wait is perhaps tough - It is called both from user > threads & daemon threads depending on the

Re: [lustre-devel] [PATCH SERIES 4: 0/4] staging: lustre: use standard prng

On Dec 17, 2017, at 18:41, NeilBrown wrote: > > Lustre has its own internal PRNG code. > This adds nothing of value to the Linux standard prng code, > so switch over to using the standard interfaces. > This adds a few callers to add_device_randomness(), which > helps everyone,

Re: [lustre-devel] [PATCH SERIES 4: 0/4] staging: lustre: use standard prng

On Dec 17, 2017, at 18:41, NeilBrown wrote: > > Lustre has its own internal PRNG code. > This adds nothing of value to the Linux standard prng code, > so switch over to using the standard interfaces. > This adds a few callers to add_device_randomness(), which > helps everyone, and removes

Re: [PATCH] staging: lustre: Fix sparse, using plain integer as NULL pointer in lov_object_fiemap()

> On Nov 30, 2017, at 11:30, Andrii Vladyka wrote: > > Change 0 to NULL in lov_object_fiemap() in order to fix warning produced by > sparse > > Signed-off-by: Andrii Vladyka Patches should be inline rather than in an attachment. That said, the patch looks

Re: [PATCH] staging: lustre: Fix sparse, using plain integer as NULL pointer in lov_object_fiemap()

> On Nov 30, 2017, at 11:30, Andrii Vladyka wrote: > > Change 0 to NULL in lov_object_fiemap() in order to fix warning produced by > sparse > > Signed-off-by: Andrii Vladyka Patches should be inline rather than in an attachment. That said, the patch looks correct, so you can add:

Re: [lustre-devel] [PATCH 9/9] staging: lustre: ldlm: remove unused field 'fwd_generation'

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > With this field gone, we don't need local variables 'imp' or 'obd' > any more. > > Signed-off-by: NeilBrown Thanks for the patches. Reviewed-by: Andreas Dilger > --- >

Re: [lustre-devel] [PATCH 9/9] staging: lustre: ldlm: remove unused field 'fwd_generation'

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > With this field gone, we don't need local variables 'imp' or 'obd' > any more. > > Signed-off-by: NeilBrown Thanks for the patches. Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 21

Re: [PATCH 8/9] staging: lustre: ldlm: remove unnecessary 'ownlocks' variable.

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > Now that the code has been simplified, 'ownlocks' is not > necessary. > > The loop which sets it exits with 'lock' having the same value as > 'ownlocks', or pointing to the head of the list if ownlocks is NULL. > > The current

Re: [PATCH 8/9] staging: lustre: ldlm: remove unnecessary 'ownlocks' variable.

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > Now that the code has been simplified, 'ownlocks' is not > necessary. > > The loop which sets it exits with 'lock' having the same value as > 'ownlocks', or pointing to the head of the list if ownlocks is NULL. > > The current code then tests

Re: [PATCH 7/9] staging: lustre: ldlm: tidy list walking in ldlm_flock()

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > Use list_for_each_entry variants to > avoid the explicit list_entry() calls. > This allows us to use list_for_each_entry_safe_from() > instread of adding a local list-walking macro. > > Also improve some comments so that it is more

Re: [PATCH 7/9] staging: lustre: ldlm: tidy list walking in ldlm_flock()

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > Use list_for_each_entry variants to > avoid the explicit list_entry() calls. > This allows us to use list_for_each_entry_safe_from() > instread of adding a local list-walking macro. > > Also improve some comments so that it is more obvious > that

Re: [PATCH 6/9] staging: lustre: ldlm: remove 'flags' arg from ldlm_flock_destroy()

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > The only value ever passed in LDLM_FL_WAIT_NOREPROC, so assume that > instead of passing it. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

Re: [PATCH 6/9] staging: lustre: ldlm: remove 'flags' arg from ldlm_flock_destroy()

On Oct 22, 2017, at 18:53, NeilBrown wrote: > > The only value ever passed in LDLM_FL_WAIT_NOREPROC, so assume that > instead of passing it. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- > drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 36 ++- > 1

  1   2   3   4   >