From: Greg KH <gregkh@linuxfoundation.org>
To: Tristan Lelong <tristan@lelong.xyz>
Cc: oleg.drokin@intel.com, andreas.dilger@intel.com,
askb23@gmail.com, john.hammond@intel.com, gdonald@gmail.com,
anhlq2110@gmail.com, fabio.falzoi84@gmail.com, oort10@gmail.com,
agimenez@sysvalve.es, rupran@einserver.de,
surya.seetharaman9@gmail.com, Julia.Lawall@lip6.fr,
joe@perches.com, a.terekhov@gmail.com, liang.zhen@intel.com,
vthakkar1994@gmail.com, amk@cray.com, srikrishanmalik@gmail.com,
rd@radekdostal.com, bergwolf@gmail.com, dan.carpenter@oracle.com,
paul.gortmaker@windriver.com, tapaswenipathak@gmail.com,
email@christophjaeger.info, uja.ornl@gmail.com,
brilliantov@inbox.ru, dmitry.eremin@intel.com,
HPDD-discuss@ml01.01.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: lustre: fix sparse warning on LPROC_SEQ_FOPS macros
Date: Fri, 5 Dec 2014 13:27:23 -0800 [thread overview]
Message-ID: <20141205212723.GA22536@kroah.com> (raw)
In-Reply-To: <1417766627-5232-1-git-send-email-tristan@lelong.xyz>
On Fri, Dec 05, 2014 at 12:03:47AM -0800, Tristan Lelong wrote:
> This patch fix a sparse warning in lustre sources
>
> warning: incorrect type in argument 1 (different address spaces)
> expected void [noderef] <asn:1>*to
> got char *<noident>
>
> This is done by adding the missing __user attribute on userland pointers inside
> the LPROC_SEQ_FOPS-like macros:
> - LPROC_SEQ_FOPS
> - LPROC_SEQ_FOPS_RW_TYPE
> - LPROC_SEQ_FOPS_WR_ONLY
> - LDLM_POOL_PROC_WRITER
>
> The patch also updates all the functions that are used by this macro:
> - lprocfs_wr_*
> - *_seq_write
>
> as well as some helpers used by the previously modified functions (otherwise
> fixing the sparse warning add some new ones):
> - lprocfs_write_frac_helper
> - lprocfs_write_helper
> - lprocfs_write_u64_helper
>
> The patch also fixes one __user pointer direct dereference by strncmp
> in function fld_proc_hash_seq_write by adding the proper copy_from_user.
>
> Signed-off-by: Tristan Lelong <tristan@lelong.xyz>
> ---
> drivers/staging/lustre/lustre/fld/lproc_fld.c | 14 ++++--
> .../staging/lustre/lustre/include/lprocfs_status.h | 44 +++++++++--------
> drivers/staging/lustre/lustre/ldlm/ldlm_internal.h | 5 +-
> drivers/staging/lustre/lustre/ldlm/ldlm_pool.c | 4 +-
> drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 7 +--
> drivers/staging/lustre/lustre/lov/lproc_lov.c | 20 +++++---
> drivers/staging/lustre/lustre/mdc/lproc_mdc.c | 7 +--
> .../lustre/lustre/obdclass/linux/linux-module.c | 5 +-
> .../lustre/lustre/obdclass/lprocfs_status.c | 2 +-
> drivers/staging/lustre/lustre/osc/lproc_osc.c | 57 +++++++++++++---------
> .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c | 25 +++++-----
> 11 files changed, 114 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/fld/lproc_fld.c b/drivers/staging/lustre/lustre/fld/lproc_fld.c
> index 95e7de1..9f1db6c 100644
> --- a/drivers/staging/lustre/lustre/fld/lproc_fld.c
> +++ b/drivers/staging/lustre/lustre/fld/lproc_fld.c
> @@ -87,13 +87,21 @@ fld_proc_hash_seq_show(struct seq_file *m, void *unused)
> }
>
> static ssize_t
> -fld_proc_hash_seq_write(struct file *file, const char *buffer,
> - size_t count, loff_t *off)
> +fld_proc_hash_seq_write(struct file *file,
> + const char __user *buffer,
> + size_t count, loff_t *off)
> {
> struct lu_client_fld *fld;
> struct lu_fld_hash *hash = NULL;
> + char name[80];
> int i;
>
> + if (count > 80)
> + return -ENAMETOOLONG;
> +
> + if (copy_from_user(name, buffer, count) != 0)
> + return -EFAULT;
How was this code ever working before?
And I know Joe asked, but how do you know that 80 is ok? And why on the
stack?
Shouldn't you just compare count to strlen(fld_hash[i].fh_name)? like you
do later on?
> +
> fld = ((struct seq_file *)file->private_data)->private;
> LASSERT(fld != NULL);
>
> @@ -101,7 +109,7 @@ fld_proc_hash_seq_write(struct file *file, const char *buffer,
> if (count != strlen(fld_hash[i].fh_name))
> continue;
>
> - if (!strncmp(fld_hash[i].fh_name, buffer, count)) {
> + if (!strncmp(fld_hash[i].fh_name, name, count)) {
So right now the code is just accessing user memory directly?
Seriously? Ugh.
Anyway, I don't like large stack variables like this, can you make it
dynamic instead?
thanks,
greg k-h
next prev parent reply other threads:[~2014-12-05 21:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 8:03 [PATCH] staging: lustre: fix sparse warning on LPROC_SEQ_FOPS macros Tristan Lelong
2014-12-05 8:28 ` Joe Perches
2014-12-05 8:37 ` Tristan Lelong
2014-12-05 8:44 ` Joe Perches
2014-12-05 22:35 ` Tristan Lelong
2014-12-05 21:27 ` Greg KH [this message]
2014-12-05 22:41 ` Tristan Lelong
2014-12-06 17:05 ` Dilger, Andreas
2014-12-06 22:34 ` Tristan Lelong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141205212723.GA22536@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=HPDD-discuss@ml01.01.org \
--cc=Julia.Lawall@lip6.fr \
--cc=a.terekhov@gmail.com \
--cc=agimenez@sysvalve.es \
--cc=amk@cray.com \
--cc=andreas.dilger@intel.com \
--cc=anhlq2110@gmail.com \
--cc=askb23@gmail.com \
--cc=bergwolf@gmail.com \
--cc=brilliantov@inbox.ru \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=dmitry.eremin@intel.com \
--cc=email@christophjaeger.info \
--cc=fabio.falzoi84@gmail.com \
--cc=gdonald@gmail.com \
--cc=joe@perches.com \
--cc=john.hammond@intel.com \
--cc=liang.zhen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg.drokin@intel.com \
--cc=oort10@gmail.com \
--cc=paul.gortmaker@windriver.com \
--cc=rd@radekdostal.com \
--cc=rupran@einserver.de \
--cc=srikrishanmalik@gmail.com \
--cc=surya.seetharaman9@gmail.com \
--cc=tapaswenipathak@gmail.com \
--cc=tristan@lelong.xyz \
--cc=uja.ornl@gmail.com \
--cc=vthakkar1994@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox