From: Jakub Kicinski <kuba@kernel•org>
To: Paul M Stillwell Jr <paul.m.stillwell.jr@intel•com>
Cc: Tony Nguyen <anthony.l.nguyen@intel•com>, <davem@davemloft•net>,
<pabeni@redhat•com>, <edumazet@google•com>,
<netdev@vger•kernel.org>, <jacob.e.keller@intel•com>,
<vaishnavi.tipireddy@intel•com>, <horms@kernel•org>,
<leon@kernel•org>,
"Pucha Himasekhar Reddy" <himasekharx.reddy.pucha@intel•com>
Subject: Re: [PATCH net-next v5 2/5] ice: configure FW logging
Date: Thu, 7 Dec 2023 18:19:41 -0800 [thread overview]
Message-ID: <20231207181941.2b16a380@kernel.org> (raw)
In-Reply-To: <75bc978a-8184-ffa3-911e-cceacf8adcd0@intel.com>
On Thu, 7 Dec 2023 16:28:27 -0800 Paul M Stillwell Jr wrote:
> On 12/6/2023 7:53 PM, Jakub Kicinski wrote:
> > On Tue, 5 Dec 2023 13:12:45 -0800 Tony Nguyen wrote:
> >> +/**
> >> + * ice_debugfs_parse_cmd_line - Parse the command line that was passed in
> >> + * @src: pointer to a buffer holding the command line
> >> + * @len: size of the buffer in bytes
> >> + * @argv: pointer to store the command line items
> >> + * @argc: pointer to store the number of command line items
> >> + */
> >> +static ssize_t ice_debugfs_parse_cmd_line(const char __user *src, size_t len,
> >> + char ***argv, int *argc)
> >> +{
> >> + char *cmd_buf, *cmd_buf_tmp;
> >> +
> >> + cmd_buf = memdup_user(src, len);
> >> + if (IS_ERR(cmd_buf))
> >> + return PTR_ERR(cmd_buf);
> >> + cmd_buf[len] = '\0';
> >> +
> >> + /* the cmd_buf has a newline at the end of the command so
> >> + * remove it
> >> + */
> >> + cmd_buf_tmp = strchr(cmd_buf, '\n');
> >> + if (cmd_buf_tmp) {
> >> + *cmd_buf_tmp = '\0';
> >> + len = (size_t)cmd_buf_tmp - (size_t)cmd_buf;
> >> + }
> >> +
> >> + *argv = argv_split(GFP_KERNEL, cmd_buf, argc);
> >> + kfree(cmd_buf);
> >> + if (!*argv)
> >> + return -ENOMEM;
> >
> > I haven't spotted a single caller wanting this full argc/argv parsing.
> > Can we please not add this complexity until its really needed?
> >
>
> I can remove it, but I use it in all the _write functions. I use the
> argc to make sure I'm only getting one value to a write and I use
> argv[0] to deal with the value.
>
> Honestly I'm not sure how valuable it is to check for a single argument,
> but I'm fairly certain our validation team will file a bug if they pass
> more than one argument and something happens :)
Just eyeballing the code - you'd still accept
echo -e 'val1\0val2' > file
right? :) Perhaps less like that validation would come up with that
but even the standard debugfs implementations don't seem to care too
much (example of bool file in netdevsim):
# cat bpf_bind_accept
Y
# echo 'nbla' > bpf_bind_accept
# echo $?
0
# cat bpf_bind_accept
N
> Examples of using argv are on lines 358 and 466 of ice_debugfs.c
>
> I'm open to changing it, just not sure to what
>
> >> +/**
> >> + * ice_debugfs_module_read - read from 'module' file
> >> + * @filp: the opened file
> >> + * @buffer: where to write the data for the user to read
> >> + * @count: the size of the user's buffer
> >> + * @ppos: file position offset
> >> + */
> >> +static ssize_t ice_debugfs_module_read(struct file *filp, char __user *buffer,
> >> + size_t count, loff_t *ppos)
> >> +{
> >> + struct dentry *dentry = filp->f_path.dentry;
> >> + struct ice_pf *pf = filp->private_data;
> >> + int status, module;
> >> + char *data = NULL;
> >> +
> >> + /* don't allow commands if the FW doesn't support it */
> >> + if (!ice_fwlog_supported(&pf->hw))
> >> + return -EOPNOTSUPP;
> >> +
> >> + module = ice_find_module_by_dentry(pf, dentry);
> >> + if (module < 0) {
> >> + dev_info(ice_pf_to_dev(pf), "unknown module\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + data = vzalloc(ICE_AQ_MAX_BUF_LEN);
> >> + if (!data) {
> >> + dev_warn(ice_pf_to_dev(pf), "Unable to allocate memory for FW configuration!\n");
> >> + return -ENOMEM;
> >
> > Can we use seq_print() here? It should simplify the reading quite a bit,
> > not sure how well it works with files that can also be written, tho.
> >
>
> I'm probably missing something here, but how do we get more simple than
> snprintf? I have a function (ice_fwlog_print_module_cfg) that handles
> whether the user has passed a single module ID or they want data on all
> the modules, but it all boils down to snprintf.
You need to vzalloc() and worry about it overflowing.
> I could get rid of ice_fwlog_print_module_cfg() and replace it inline
> with the if/else code if that would be clearer, but I'm not sure
> seq_printf() is helpful because each file is a single quantum of
> information (with the exception of the file that represents all the
> modules). I created a special file to represent all the modules, but
> maybe it's more confusing and I should get rid of it and just make the
> users specify all of the modules in a script.
>
> Would that be easier? Then there is no if/else it's just a single snprintf.
The value of seq_print() here is the fact it will handle the memory
allocation and copying to user space for you. Ignore the "seq"
in the name.
next prev parent reply other threads:[~2023-12-08 2:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 21:12 [PATCH net-next v5 0/5][pull request] add v2 FW logging for ice driver Tony Nguyen
2023-12-05 21:12 ` [PATCH net-next v5 1/5] ice: remove FW logging code Tony Nguyen
2023-12-05 21:12 ` [PATCH net-next v5 2/5] ice: configure FW logging Tony Nguyen
2023-12-07 3:53 ` Jakub Kicinski
2023-12-08 0:28 ` Paul M Stillwell Jr
2023-12-08 2:19 ` Jakub Kicinski [this message]
2023-12-10 0:09 ` Paul M Stillwell Jr
2023-12-11 16:30 ` Jakub Kicinski
2023-12-11 17:04 ` Paul M Stillwell Jr
2023-12-05 21:12 ` [PATCH net-next v5 3/5] ice: enable " Tony Nguyen
2023-12-05 21:12 ` [PATCH net-next v5 4/5] ice: add ability to read and configure FW log data Tony Nguyen
2023-12-05 21:12 ` [PATCH net-next v5 5/5] ice: add documentation for FW logging Tony Nguyen
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=20231207181941.2b16a380@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=anthony.l.nguyen@intel$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=himasekharx.reddy.pucha@intel$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=jacob.e.keller@intel$(echo .)com \
--cc=leon@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=paul.m.stillwell.jr@intel$(echo .)com \
--cc=vaishnavi.tipireddy@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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