Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1521741 > unrolled thread
| Started by | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| First post | 2016-11-14 16:20 +0100 |
| Last post | 2016-11-18 18:20 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 32/35] staging: lustre: mount: fix lmd_parse() to handle commas in expr_list Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-11-14 16:20 +0100
Re: [PATCH 32/35] staging: lustre: mount: fix lmd_parse() to handle commas in expr_list James Simmons <jsimmons@infradead.org> - 2016-11-18 18:00 +0100
Re: [PATCH 32/35] staging: lustre: mount: fix lmd_parse() to handle commas in expr_list Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-11-18 18:20 +0100
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-11-14 16:20 +0100 |
| Subject | Re: [PATCH 32/35] staging: lustre: mount: fix lmd_parse() to handle commas in expr_list |
| Message-ID | <sDrd7-eg-5@gated-at.bofh.it> |
On Thu, Nov 10, 2016 at 12:31:02PM -0500, James Simmons wrote:
> From: Jian Yu <jian.yu@intel.com>
>
> The lmd_parse() function parses mount options with comma as
> delimiter without considering commas in expr_list as follows
> is a valid LNET nid range syntax:
>
> <expr_list> :== '[' <range_expr> [ ',' <range_expr>] ']'
>
> This patch fixes the above issue by using cfs_parse_nidlist()
> to parse nid range list instead of using class_parse_nid_quiet()
> to parse only one nid.
ugh, parsing mount strings in the kernel in odd ways, what could ever go
wrong...
>
> Signed-off-by: Jian Yu <jian.yu@intel.com>
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5690
> Reviewed-on: http://review.whamcloud.com/17036
> Reviewed-by: Niu Yawei <yawei.niu@intel.com>
> Reviewed-by: Bob Glossman <bob.glossman@intel.com>
> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
> Signed-off-by: James Simmons <jsimmons@infradead.org>
> ---
> drivers/staging/lustre/lustre/obdclass/obd_mount.c | 91 ++++++++++++++++++--
> 1 files changed, 85 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/obd_mount.c b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
> index 2283e92..1eb8e71 100644
> --- a/drivers/staging/lustre/lustre/obdclass/obd_mount.c
> +++ b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
> @@ -871,6 +871,87 @@ static int lmd_parse_mgs(struct lustre_mount_data *lmd, char **ptr)
> return 0;
> }
>
> +/**
> + * Find the first comma delimiter from the specified \a buf and make \a *endh
> + * point to the string starting with the comma. The commas in expression list
> + * [...] will be skipped.
> + *
> + * \param[in] buf a comma-separated string
> + * \param[in] endh a pointer to a pointer that will point to the string
> + * starting with the comma
Please drop this mess of \param, it's not needed and is not kernel-doc
format.
> + *
> + * \retval 0 if comma delimiter is found
> + * \retval 1 if comma delimiter is not found
> + */
> +static int lmd_find_comma(char *buf, char **endh)
> +{
> + char *c = buf;
> + int skip = 0;
> +
> + if (!buf)
> + return 1;
> +
> + while (*c != '\0') {
> + if (*c == '[')
> + skip++;
> + else if (*c == ']')
> + skip--;
> +
> + if (*c == ',' && !skip) {
> + if (endh)
> + *endh = c;
> + return 0;
> + }
> + c++;
> + }
> + return 1;
> +}
Don't we have a standard string search function for finding a string in
a string already in the kernel? Why write another one?
Or better yet, why are you using such a crazy string in the first place
from userspace?
Please fix this up and resend.
thanks,
greg k-h
[toc] | [next] | [standalone]
| From | James Simmons <jsimmons@infradead.org> |
|---|---|
| Date | 2016-11-18 18:00 +0100 |
| Message-ID | <sEUG6-1ff-53@gated-at.bofh.it> |
| In reply to | #1521741 |
> > --- a/drivers/staging/lustre/lustre/obdclass/obd_mount.c > > +++ b/drivers/staging/lustre/lustre/obdclass/obd_mount.c > > @@ -871,6 +871,87 @@ static int lmd_parse_mgs(struct lustre_mount_data *lmd, char **ptr) > > return 0; > > } > > > > +/** > > + * Find the first comma delimiter from the specified \a buf and make \a *endh > > + * point to the string starting with the comma. The commas in expression list > > + * [...] will be skipped. > > + * > > + * \param[in] buf a comma-separated string > > + * \param[in] endh a pointer to a pointer that will point to the string > > + * starting with the comma > > Please drop this mess of \param, it's not needed and is not kernel-doc > format. Is it just the [in] mess that needs to be removed or does the doc style need to migrate to another format. Looking online doesn't reveal much and' I saw something about @arg format as well. I see both in tree. What is the right one to use and do clear docs on this format exist somewhere.
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-11-18 18:20 +0100 |
| Message-ID | <sEUZr-1B7-11@gated-at.bofh.it> |
| In reply to | #1525539 |
On Fri, Nov 18, 2016 at 04:54:03PM +0000, James Simmons wrote: > > > > --- a/drivers/staging/lustre/lustre/obdclass/obd_mount.c > > > +++ b/drivers/staging/lustre/lustre/obdclass/obd_mount.c > > > @@ -871,6 +871,87 @@ static int lmd_parse_mgs(struct lustre_mount_data *lmd, char **ptr) > > > return 0; > > > } > > > > > > +/** > > > + * Find the first comma delimiter from the specified \a buf and make \a *endh > > > + * point to the string starting with the comma. The commas in expression list > > > + * [...] will be skipped. > > > + * > > > + * \param[in] buf a comma-separated string > > > + * \param[in] endh a pointer to a pointer that will point to the string > > > + * starting with the comma > > > > Please drop this mess of \param, it's not needed and is not kernel-doc > > format. > > Is it just the [in] mess that needs to be removed or does the doc style > need to migrate to another format. Looking online doesn't reveal much and' > I saw something about @arg format as well. I see both in tree. What is the > right one to use and do clear docs on this format exist somewhere. @arg is the correct one, see the file Documentation/kernel-documentation.rst in the section, "How to format kernel-doc comments" for how to do this properly. thanks, greg k-h
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web