All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: davem@davemloft.net, pabeni@redhat.com, edumazet@google.com,
	netdev@vger.kernel.org,
	Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com>,
	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: Wed, 6 Dec 2023 19:53:04 -0800	[thread overview]
Message-ID: <20231206195304.6226771d@kernel.org> (raw)
In-Reply-To: <20231205211251.2122874-3-anthony.l.nguyen@intel.com>

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?

> +/**
> + * 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.

> +/**
> + * ice_debugfs_fwlog_init - setup the debugfs directory
> + * @pf: the ice that is starting up
> + */
> +void ice_debugfs_fwlog_init(struct ice_pf *pf)
> +{
> +	const char *name = pci_name(pf->pdev);
> +	struct dentry *fw_modules_dir;
> +	struct dentry **fw_modules;
> +	int i;
> +
> +	/* only support fw log commands on PF 0 */
> +	if (pf->hw.bus.func)
> +		return;
> +
> +	/* allocate space for this first because if it fails then we don't
> +	 * need to unwind
> +	 */
> +	fw_modules = kcalloc(ICE_NR_FW_LOG_MODULES, sizeof(*fw_modules),
> +			     GFP_KERNEL);
> +

nit: no new line between call and error check

> +	if (!fw_modules) {
> +		pr_info("Unable to allocate space for modules\n");

no warnings on allocation failures, there will be a splat for GFP_KERNEL
(checkpatch should catch this)

> +		return;
> +	}
> +
> +	pf->ice_debugfs_pf = debugfs_create_dir(name, ice_debugfs_root);
> +	if (IS_ERR(pf->ice_debugfs_pf)) {
> +		pr_info("init of debugfs PCI dir failed\n");
> +		kfree(fw_modules);
> +		return;
> +	}
> +
> +	pf->ice_debugfs_pf_fwlog = debugfs_create_dir("fwlog",
> +						      pf->ice_debugfs_pf);
> +	if (IS_ERR(pf->ice_debugfs_pf)) {
> +		pr_info("init of debugfs fwlog dir failed\n");

If GregKH sees all the info message on debugfs failures he may
complain, DebugFS is supposed to be completely optional.

Also - free fw_modules ?

You probably want to use goto on all error paths here
> +/**
> + * ice_fwlog_get - Get the firmware logging settings
> + * @hw: pointer to the HW structure
> + * @cfg: config to populate based on current firmware logging settings
> + */
> +int ice_fwlog_get(struct ice_hw *hw, struct ice_fwlog_cfg *cfg)
> +{
> +	if (!ice_fwlog_supported(hw))
> +		return -EOPNOTSUPP;
> +
> +	if (!cfg)
> +		return -EINVAL;

can't be, let's avoid defensive programming

> +	return ice_aq_fwlog_get(hw, cfg);


> +void ice_pf_fwlog_update_module(struct ice_pf *pf, int log_level, int module)
> +{
> +	struct ice_fwlog_module_entry *entries;
> +	struct ice_hw *hw = &pf->hw;
> +
> +	entries = (struct ice_fwlog_module_entry *)hw->fwlog_cfg.module_entries;
> +
> +	entries[module].log_level = log_level;
> +}

Isn't this just 

	hw->fwlog_cfg.module_entries[module].log_level = log_level;

? The cast specifically look alarming but unnecessary.

  reply	other threads:[~2023-12-07  3:53 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 [this message]
2023-12-08  0:28     ` Paul M Stillwell Jr
2023-12-08  2:19       ` Jakub Kicinski
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=20231206195304.6226771d@kernel.org \
    --to=kuba@kernel.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=himasekharx.reddy.pucha@intel.com \
    --cc=horms@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=leon@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paul.m.stillwell.jr@intel.com \
    --cc=vaishnavi.tipireddy@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.