[PATCH] drivers/staging/rtl8192u/r8192U_wx.c: fix warnings issued by sparse
This minor patch motivated by eudyptula challenge fixes the following warnings
issued
by `sparse' in drivers/staging/rtl8192u/r8192U_wx.c:
.../r8192U_wx.c:27:5: warning: symbol 'rtl8180_rates' was not declared. Should
it be static?
.../r8192U_wx.c:961:22: warning: symbol 'r8192_get_wireless_stats' was not
declared. Should it be static?
.../r8192U_wx.c:990:24: warning: symbol 'r8192_wx_handlers_def' was not
declared. Should it be static?
Signed-off-by: Ovidiu Toader
---
drivers/staging/rtl8192u/r8192U_wx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
b/drivers/staging/rtl8192u/r8192U_wx.c
index 6808e87..0a751d9 100644
--- a/drivers/staging/rtl8192u/r8192U_wx.c
+++ b/drivers/staging/rtl8192u/r8192U_wx.c
@@ -22,9 +22,10 @@
#include "r8192U_hw.h"
#include "dot11d.h"
+#include "r8192U_wx.h"
#define RATE_COUNT 12
-u32 rtl8180_rates[] = {100, 200, 550, 1100,
+static u32 rtl8180_rates[] = {100, 200, 550, 1100,
600, 900, 1200, 1800, 2400, 3600, 4800,
5400};
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Fri, Aug 8, 2014 at 1:32 PM, Greg Kroah-Hartman wrote: > On Fri, Aug 08, 2014 at 01:06:15AM -0400, Oleg Drokin wrote: >> >> On Aug 8, 2014, at 12:42 AM, Greg Kroah-Hartman wrote: >> >> > On Fri, Aug 08, 2014 at 12:03:20AM -0400, Oleg Drokin wrote: >> >> Hello! >> >> >> >> On Aug 7, 2014, at 11:49 PM, Greg Kroah-Hartman wrote: >> >> This is not a critical bug and in the worst case the code here may >> cause miss of statistics counter increase. >> This is why I think it is not worth to backport the patch at all. >> >>> You are right, and if this is just for some random "statistics" file, >> >>> can we just delete the whole function? >> >> >> >> I hope not! >> >> This is used all around the client to tally up various operations >> >> executed counts. >> > Why would you do that? Why would they care? >> >> We would do that to provide information on the client operations performed. >> They would care because they are interested in what particular clients might >> be doing. >> >> >> The statistic is then used by various userspace monitoring tools. >> > Why not use the in-kernel monitoring tools instead of creating your own? >> > What does userspace do with that information? >> >> We don't really control the userspace tools. People write tools to suit >> their needs >> to monitor loads, see odd things the end users are doing or possibly for some >> debugging even. >> Correlating these numbers with what server sees also proves useful at times >> (write combining for example). >> >> Here's a sample of output of a recently mounted client that I poked on a bit >> (the lines starting with # are my comments): >> # cat /proc/fs/lustre/llite/lustre-88008dde27f0/stats >> snapshot_time 1407473168.466102 secs.usecs >> read_bytes1 samples [bytes] 0 0 0 >> write_bytes 4 samples [bytes] 2 7 19 >> osc_write 4 samples [bytes] 2 7 19 >> # The bytes counts show you minimum, maximum of writes seen and total number >> of bytes read-written. >> # Lustre (and many other network filesystems) is very sensitive to small IO, >> esp. reads so it's good >> # to know if you have a lot of it. >> open 6 samples [regs] >> # The "regs" type just shows you how many of given type operations were >> performed since last statistic reset. >> # Frequently that allows people to guess where does high load come from on a >> particular client when >> # it's otherwise not obvious because not a lot of cpu is used. >> # Some operations are heavier than others too. >> close 6 samples [regs] >> readdir 4 samples [regs] >> setattr 1 samples [regs] >> truncate 4 samples [regs] >> getattr 7 samples [regs] >> create1 samples [regs] >> alloc_inode 1 samples [regs] >> getxattr 8 samples [regs] >> inode_permission 28 samples [regs] >> >> As more operations types are seen the list grows. >> Then there are also specific stats for readahead (data and metadata) so that >> interested people can make informed >> decisions on the tuning there should they be unsatisfied with default >> settings. >> >> I am not sure there's a similar mechanism in the kernel already that >> would allow us to get this sort of data easily all in one place? > > perf should show you this, if not, please add the functionality there. > A filesystem is not the place to have performance monitoring code, this > needs to be removed before it can be moved out of staging. Please work > with the trace/perf developers on this if there is something lacking > there. > nfs and nfsd track rpc ops statistics and export them via /proc/self/mountstats, e.g., device 192.168.214.141:/d9691564-432b-11e2-8e5d-8b7acf882df3 mounted on /mnt/pnfsd with fstype nfs4 statvers=1.1 opts: rw,vers=4.1,rsize=262144,wsize=262144,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.214.128,local_lock=none age:15426 impl_id:name='',domain='',date='0,0' caps: caps=0x3,wtmult=512,dtsize=32768,bsize=0,namlen=255 nfsv4: bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions sec:flavor=1,pseudoflavor=1 events: 82474 12159573 9527 109202 7574 10119 16289648 3634869 10938 108551 2084272 182492 13646 7700 52594 60832 8829 48985 0 6564 1459053 66 0 0 0 289315 376376 bytes: 11526471786 9942294760 3280371712 3278274560 14578366831 11710126268 2782400 2084272 RPC iostats version: 1.0 p/v: 13/4 (nfs) xprt: tcp 859 0 2 0 12 408031 407999 29 2169734 0 32 2496 310753 per-op statistics NULL: 0 0 0 0 0 0 0 0 READ: 289327 289326 0 35877640 14615129136 63609 187 1893161 WRITE: 376352 376360 0 11759732976 51184768 6698277 2246445 8978314
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Sat, Aug 09, 2014 at 07:05:46PM +0800, Peng Tao wrote: > On Fri, Aug 8, 2014 at 1:32 PM, Greg Kroah-Hartman > wrote: > > On Fri, Aug 08, 2014 at 01:06:15AM -0400, Oleg Drokin wrote: > >> > >> On Aug 8, 2014, at 12:42 AM, Greg Kroah-Hartman wrote: > >> > >> > On Fri, Aug 08, 2014 at 12:03:20AM -0400, Oleg Drokin wrote: > >> >> Hello! > >> >> > >> >> On Aug 7, 2014, at 11:49 PM, Greg Kroah-Hartman wrote: > >> > >> This is not a critical bug and in the worst case the code here may > >> cause miss of statistics counter increase. > >> This is why I think it is not worth to backport the patch at all. > >> >>> You are right, and if this is just for some random "statistics" file, > >> >>> can we just delete the whole function? > >> >> > >> >> I hope not! > >> >> This is used all around the client to tally up various operations > >> >> executed counts. > >> > Why would you do that? Why would they care? > >> > >> We would do that to provide information on the client operations performed. > >> They would care because they are interested in what particular clients > >> might be doing. > >> > >> >> The statistic is then used by various userspace monitoring tools. > >> > Why not use the in-kernel monitoring tools instead of creating your own? > >> > What does userspace do with that information? > >> > >> We don't really control the userspace tools. People write tools to suit > >> their needs > >> to monitor loads, see odd things the end users are doing or possibly for > >> some > >> debugging even. > >> Correlating these numbers with what server sees also proves useful at times > >> (write combining for example). > >> > >> Here's a sample of output of a recently mounted client that I poked on a > >> bit (the lines starting with # are my comments): > >> # cat /proc/fs/lustre/llite/lustre-88008dde27f0/stats > >> snapshot_time 1407473168.466102 secs.usecs > >> read_bytes1 samples [bytes] 0 0 0 > >> write_bytes 4 samples [bytes] 2 7 19 > >> osc_write 4 samples [bytes] 2 7 19 > >> # The bytes counts show you minimum, maximum of writes seen and total > >> number of bytes read-written. > >> # Lustre (and many other network filesystems) is very sensitive to small > >> IO, esp. reads so it's good > >> # to know if you have a lot of it. > >> open 6 samples [regs] > >> # The "regs" type just shows you how many of given type operations were > >> performed since last statistic reset. > >> # Frequently that allows people to guess where does high load come from on > >> a particular client when > >> # it's otherwise not obvious because not a lot of cpu is used. > >> # Some operations are heavier than others too. > >> close 6 samples [regs] > >> readdir 4 samples [regs] > >> setattr 1 samples [regs] > >> truncate 4 samples [regs] > >> getattr 7 samples [regs] > >> create1 samples [regs] > >> alloc_inode 1 samples [regs] > >> getxattr 8 samples [regs] > >> inode_permission 28 samples [regs] > >> > >> As more operations types are seen the list grows. > >> Then there are also specific stats for readahead (data and metadata) so > >> that interested people can make informed > >> decisions on the tuning there should they be unsatisfied with default > >> settings. > >> > >> I am not sure there's a similar mechanism in the kernel already that > >> would allow us to get this sort of data easily all in one place? > > > > perf should show you this, if not, please add the functionality there. > > A filesystem is not the place to have performance monitoring code, this > > needs to be removed before it can be moved out of staging. Please work > > with the trace/perf developers on this if there is something lacking > > there. > > > nfs and nfsd track rpc ops statistics and export them via > /proc/self/mountstats, e.g., > > device 192.168.214.141:/d9691564-432b-11e2-8e5d-8b7acf882df3 mounted > on /mnt/pnfsd with fstype nfs4 statvers=1.1 > opts: > rw,vers=4.1,rsize=262144,wsize=262144,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.214.128,local_lock=none > age:15426 > impl_id:name='',domain='',date='0,0' > caps: caps=0x3,wtmult=512,dtsize=32768,bsize=0,namlen=255 > nfsv4: bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions > sec:flavor=1,pseudoflavor=1 > events: 82474 12159573 9527 109202 7574 10119 16289648 3634869 > 10938 108551 2084272 182492 13646 7700 52594 60832 8829 48985 0 6564 > 1459053 66 0 0 0 289315 376376 > bytes: 11526471786 9942294760 3280371712 3278274560 > 14578366831 11710126268 2782400 2084272 > RPC iostats version: 1.0 p/v: 13/4 (nfs) > xprt: tcp 859 0 2 0 12 408031 407999
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field
> Because maybe these stats preceed the introduction of perf and other > tracing/debug tools? I don't know, it's really low down on the list of > reasons why lustre can't be merged out of staging at the moment, you all > have much bigger issues to address first. I wonder what is the prioritized list you have in mind? Bye, Oleg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote: > > > Because maybe these stats preceed the introduction of perf and other > > tracing/debug tools? I don't know, it's really low down on the list of > > reasons why lustre can't be merged out of staging at the moment, you all > > have much bigger issues to address first. > > I wonder what is the prioritized list you have in mind? Do I really have to spell out what is wrong with that codebase that needs to be fixed up? It took me 50+ patches for 3.17-rc1 to just fix up a _portion_ of the include file mess that is in there. Now is the first time the code actually _builds_ properly in the kernel tree (i.e. no magic header file include path modifications in Makefiles preventing individual files from being built correctly.) If you all don't know what needs to be done here, then I might as well just delete the drivers/staging/lustre/ tree right now. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: dgnc: Encapsulate global variables in a structure
This commit binds global variables of dgnc driver in a structure so
that it is logically consistent. The structure is accessed via getter
function and as a result the externing of globals is removed. The names
of the variables are also changed to be more eye friendly.
Signed-off-by: Konrad Zapalowicz
---
This patch applies on top of my two previous patch series. In case it
is an issue I can resubmit the whole series for dgnc driver as one
patch set - just let me know.
drivers/staging/dgnc/dgnc_driver.c | 82 +++---
drivers/staging/dgnc/dgnc_driver.h | 20 ++
drivers/staging/dgnc/dgnc_mgmt.c | 48 --
drivers/staging/dgnc/dgnc_sysfs.c | 31 ++
4 files changed, 102 insertions(+), 79 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 724e4ab..9a23e9a 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -83,17 +83,11 @@ static const struct file_operations dgnc_BoardFops = {
.release= dgnc_mgmt_close
};
-
-/*
- * Globals
- */
-uint dgnc_NumBoards;
-struct dgnc_board *dgnc_Board[MAXBOARDS];
-DEFINE_SPINLOCK(dgnc_global_lock);
-intdgnc_driver_state = DRIVER_INITIALIZED;
-ulong dgnc_poll_counter;
-uint dgnc_Major;
-intdgnc_poll_tick = 20;/* Poll interval - 20 ms */
+static struct dgnc_driver driver = {
+ .lock = __SPIN_LOCK_UNLOCKED(driver.lock),
+ .state = DRIVER_INITIALIZED,
+ .poll_tick = 20,
+};
/*
* Static vars.
@@ -207,20 +201,20 @@ static void __exit dgnc_cleanup_module(void)
dgnc_remove_driver_sysfiles(&dgnc_driver);
if (dgnc_Major_Control_Registered) {
- device_destroy(dgnc_class, MKDEV(dgnc_Major, 0));
+ device_destroy(dgnc_class, MKDEV(driver.major, 0));
class_destroy(dgnc_class);
- unregister_chrdev(dgnc_Major, "dgnc");
+ unregister_chrdev(driver.major, "dgnc");
}
- for (i = 0; i < dgnc_NumBoards; ++i) {
- dgnc_remove_ports_sysfiles(dgnc_Board[i]);
- dgnc_tty_uninit(dgnc_Board[i]);
- dgnc_cleanup_board(dgnc_Board[i]);
+ for (i = 0; i < driver.num_boards; ++i) {
+ dgnc_remove_ports_sysfiles(driver.board[i]);
+ dgnc_tty_uninit(driver.board[i]);
+ dgnc_cleanup_board(driver.board[i]);
}
dgnc_tty_post_uninit();
- if (dgnc_NumBoards)
+ if (driver.num_boards)
pci_unregister_driver(&dgnc_driver);
}
@@ -253,7 +247,7 @@ static int __init dgnc_init_module(void)
*/
if (rc < 0) {
/* Only unregister the pci driver if it was actually
registered. */
- if (dgnc_NumBoards)
+ if (driver.num_boards)
pci_unregister_driver(&dgnc_driver);
else
pr_warn("WARNING: dgnc driver load failed. No Digi Neo
or Classic boards found.\n");
@@ -301,11 +295,11 @@ static int dgnc_start(void)
APR(("Can't register dgnc driver device (%d)\n", rc));
return -ENXIO;
}
- dgnc_Major = rc;
+ driver.major = rc;
dgnc_class = class_create(THIS_MODULE, "dgnc_mgmt");
device_create(dgnc_class, NULL,
- MKDEV(dgnc_Major, 0),
+ MKDEV(driver.major, 0),
NULL, "dgnc_mgmt");
dgnc_Major_Control_Registered = TRUE;
}
@@ -325,13 +319,13 @@ static int dgnc_start(void)
init_timer(&dgnc_poll_timer);
dgnc_poll_timer.function = dgnc_poll_handler;
dgnc_poll_timer.data = 0;
- dgnc_poll_time = jiffies + dgnc_jiffies_from_ms(dgnc_poll_tick);
+ dgnc_poll_time = jiffies + dgnc_jiffies_from_ms(driver.poll_tick);
dgnc_poll_timer.expires = dgnc_poll_time;
DGNC_UNLOCK(dgnc_poll_lock, flags);
add_timer(&dgnc_poll_timer);
- dgnc_driver_state = DRIVER_READY;
+ driver.state = DRIVER_READY;
return rc;
}
@@ -349,8 +343,9 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
} else {
rc = dgnc_found_board(pdev, ent->driver_data);
if (rc == 0) {
- dgnc_NumBoards++;
- DPR_INIT(("Incrementing numboards to %d\n",
dgnc_NumBoards));
+ driver.num_boards++;
+ DPR_INIT(("Incrementing numboards to %d\n",
+ driver.num_boards));
}
}
return rc;
@@ -395,12 +390,12 @@ static void dgnc_cleanup_board(struct dgnc_board *brd)
if (brd->msgbuf_head) {
unsigned long flags;
-
[PATCH] [next-20140808] [staging] [lustre] Fix coding style in llite/remote_perm.c
Sorry for the noise, this is part of task 10 of the Eudyptula Challenge. Signed-off-by: Junien Fridrick --- drivers/staging/lustre/lustre/llite/remote_perm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/llite/remote_perm.c b/drivers/staging/lustre/lustre/llite/remote_perm.c index f61fefc..3a9c8e8 100644 --- a/drivers/staging/lustre/lustre/llite/remote_perm.c +++ b/drivers/staging/lustre/lustre/llite/remote_perm.c @@ -100,7 +100,7 @@ void free_rmtperm_hash(struct hlist_head *hash) struct ll_remote_perm *lrp; struct hlist_node *next; - if(!hash) + if (!hash) return; for (i = 0; i < REMOTE_PERM_HASHSIZE; i++) -- 2.0.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [next-20140808] [staging] [lustre] Fix coding style in llite/remote_perm.c
On Sat, Aug 09, 2014 at 08:22:48PM +, Junien Fridrick wrote: > Sorry for the noise, this is part of task 10 of the Eudyptula Challenge. Nothing wrong with the patch itself, but maybe in the future you could put such comments after the "---" line so that they won't be included in the git commit logs when the patch is applied (and will end up being "noise"). A. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: lustre: libcfs: workitem.c: Cleaning up missing null-terminate after strncpy call
Added a guaranteed null-terminate after call to strncpy. Signed-off-by: Rickard Strandqvist --- drivers/staging/lustre/lustre/libcfs/workitem.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/lustre/lustre/libcfs/workitem.c b/drivers/staging/lustre/lustre/libcfs/workitem.c index 0a03bf7..60326f2 100644 --- a/drivers/staging/lustre/lustre/libcfs/workitem.c +++ b/drivers/staging/lustre/lustre/libcfs/workitem.c @@ -365,6 +365,7 @@ cfs_wi_sched_create(char *name, struct cfs_cpt_table *cptab, return -ENOMEM; strncpy(sched->ws_name, name, CFS_WS_NAME_LEN); + sched->ws_name[CFS_WS_NAME_LEN - 1] = '\0'; sched->ws_cptab = cptab; sched->ws_cpt = cpt; -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: lustre: obdclass: genops.c: Cleaning up missing null-terminate after strncpy call
Added a guaranteed null-terminate after call to strncpy. Signed-off-by: Rickard Strandqvist --- drivers/staging/lustre/lustre/obdclass/genops.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c b/drivers/staging/lustre/lustre/obdclass/genops.c index 3210ad8..082b5b9 100644 --- a/drivers/staging/lustre/lustre/obdclass/genops.c +++ b/drivers/staging/lustre/lustre/obdclass/genops.c @@ -328,6 +328,7 @@ struct obd_device *class_newdev(const char *type_name, const char *name) result->obd_type = type; strncpy(result->obd_name, name, sizeof(result->obd_name) - 1); + result->obd_name[sizeof(result->obd_name) - 1] = '\0'; obd_devs[i] = result; } } -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: lustre: ptlrpc: nrs.c: Cleaning up missing null-terminate after strncpy call
Added a guaranteed null-terminate after call to strncpy. Signed-off-by: Rickard Strandqvist --- drivers/staging/lustre/lustre/ptlrpc/nrs.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/lustre/lustre/ptlrpc/nrs.c b/drivers/staging/lustre/lustre/ptlrpc/nrs.c index 12151aa..a914447 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/nrs.c +++ b/drivers/staging/lustre/lustre/ptlrpc/nrs.c @@ -1162,6 +1162,7 @@ int ptlrpc_nrs_policy_register(struct ptlrpc_nrs_pol_conf *conf) GOTO(fail, rc = -ENOMEM); strncpy(desc->pd_name, conf->nc_name, NRS_POL_NAME_MAX); + desc->pd_name[NRS_POL_NAME_MAX - 1] = '\0'; desc->pd_ops = conf->nc_ops; desc->pd_compat = conf->nc_compat; desc->pd_compat_svc_name = conf->nc_compat_svc_name; -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers/staging/rtl8192u/r8192U_wx.c: fix warnings issued by sparse
On Sat, 2014-08-09 at 00:05 -0700, Ovidiu Toader wrote:
> This minor patch motivated by eudyptula challenge fixes the following
> warnings issued
> by `sparse' in drivers/staging/rtl8192u/r8192U_wx.c:
> .../r8192U_wx.c:27:5: warning: symbol 'rtl8180_rates' was not declared.
> Should it be static?
> .../r8192U_wx.c:961:22: warning: symbol 'r8192_get_wireless_stats' was not
> declared. Should it be static?
> .../r8192U_wx.c:990:24: warning: symbol 'r8192_wx_handlers_def' was not
> declared. Should it be static?
[]
> diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
> b/drivers/staging/rtl8192u/r8192U_wx.c
[]
> @@ -22,9 +22,10 @@
> #include "r8192U_hw.h"
>
> #include "dot11d.h"
> +#include "r8192U_wx.h"
>
> #define RATE_COUNT 12
> -u32 rtl8180_rates[] = {100, 200, 550, 1100,
> +static u32 rtl8180_rates[] = {100, 200, 550, 1100,
> 600, 900, 1200, 1800, 2400, 3600, 4800,
> 5400};
const too.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
