All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt.fleming@intel.com>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: mdroth@linux.vnet.ibm.com, rjones@redhat.com,
	jordan.l.justen@intel.com, "Gabriel L. Somlo" <somlo@cmu.edu>,
	qemu-devel@nongnu.org, gleb@cloudius-systems.com,
	kraxel@redhat.com, pbonzini@redhat.com,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file
Date: Wed, 15 Jul 2015 13:00:45 +0100	[thread overview]
Message-ID: <1436961645.25906.20.camel@intel.com> (raw)
In-Reply-To: <20150713200936.GK1606@HEDWIG.INI.CMU.EDU>

On Mon, 2015-07-13 at 16:09 -0400, Gabriel L. Somlo wrote:
> 
> 3. I'm currently only handling x86 and I/O ports. I could drop the
>    fw_cfg_dmi_whitelist and just check the signature, using mmio where
>    appropriate, but I don't have a handy-dandy set of VMs for those
>    architectures on which I could test. Wondering if that's something
>    we should have before I officially try to submit this to the kernel,
>    or whether it could wait for a second iteration.
> 
>    Speaking of the kernel: My default plan is to subscribe to
>    kernelnewbies@kernelnewbies.org and submit it there (this is after
>    all baby's first kernel module :) but if there's a better route for
>    pushing it upstream, please feel free to suggest it to me.

Congrats on your first kernel patch! Cc'ing kernelnewbies is OK but this
patches warrants a wider audience. Cc Greg Kroah-Hartman
(gregkh@linuxfoundation.org) since he polices things related to sysfs,
the x86 maintainers (x86@kernel.org), and linux-kernel@vger.kernel.org.
The closest thing we have to a Linux system firmware list is probably
linux-efi@vger.kernel.org.

By all means, mention that it's your first kernel patch when submitting
this.

Oh, you're also going to want to add documentation under
Documentation/ABI/testing/sysfs-firmware-fw_cfg as part of your patch
series.


> /* provide atomic read access to hardware fw_cfg device
>  * (critical section involves potentially lengthy i/o, using mutex) */
> static DEFINE_MUTEX(fw_cfg_dev_lock);

Just a very small nitpick, but,

	/*
	 * Multi-line comments should look like this
	 * in the kernel.
	 */


> static int __init fw_cfg_sysfs_init(void)
> {
> 	int ret = 0;
> 	uint32_t count, i;
> 	char sig[FW_CFG_SIG_SIZE];
> 	struct fw_cfg_sysfs_entry *entry;
> 
> 	/* only install on matching "hardware" */
> 	if (!dmi_check_system(fw_cfg_whitelist)) {
> 		pr_warn("Supported QEMU Standard PC hardware not found!\n");
> 		return -ENODEV;
> 	}

I would suggest deleting this warning because it's just noise if I build
this code into my kernel and boot it on non-qemu hardware.

> 	/* verify fw_cfg device signature */
> 	fw_cfg_read_blob(FW_CFG_SIGNATURE, sig, 0, FW_CFG_SIG_SIZE);
> 	if (memcmp(sig, "QEMU", FW_CFG_SIG_SIZE) != 0) {
> 		pr_warn("QEMU fw_cfg signature not found!\n");
> 		return -ENODEV;
> 	}
> 
> 	/* create fw_cfg folder in sysfs */
> 	fw_cfg_kset = kset_create_and_add("fw_cfg", NULL, firmware_kobj);
> 	if (!fw_cfg_kset)
> 		return -ENOMEM;
> 
> 	/* process fw_cfg file directory entry */
> 	mutex_lock(&fw_cfg_dev_lock);
> 	outw(FW_CFG_FILE_DIR, FW_CFG_PORT_CTL);	/* select fw_cfg directory */
> 	insb(FW_CFG_PORT_DATA, &count, sizeof(count)); /* get file count */
> 	count = be32_to_cpu(count);
> 	/* create & register a sysfs node for each file in the directory */
> 	for (i = 0; i < count; i++) {
> 		/* allocate new entry */
> 		entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> 		if (!entry) {
> 			ret = -ENOMEM;
> 			break;
> 		}
> 
> 		/* acquire file information from directory */
> 		insb(FW_CFG_PORT_DATA, &entry->f, sizeof(struct fw_cfg_file));
> 		entry->f.size = be32_to_cpu(entry->f.size);
> 		entry->f.select = be16_to_cpu(entry->f.select);
> 
> 		/* register sysfs entry for this file */
> 		entry->kobj.kset = fw_cfg_kset;
> 		ret = kobject_init_and_add(&entry->kobj,
> 					   &fw_cfg_sysfs_entry_ktype, NULL,
> 					   /* NOTE: '/' represented as '!' */
> 					   "%s", entry->f.name);
> 		if (ret)
> 			break;

If you take this error path, aren't you leaking 'entry'? It isn't yet on
the 'fw_cfg_entry_cache' list and so won't be freed in
fw_cfg_sysfs_cache_cleanup().

  parent reply	other threads:[~2015-07-15 12:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13 20:09 [Qemu-devel] RFC: guest-side retrieval of fw_cfg file Gabriel L. Somlo
2015-07-13 23:03 ` Eric Blake
2015-07-14 17:00   ` Gabriel L. Somlo
2015-07-15 11:06     ` Matt Fleming
2015-07-15 11:15       ` Laszlo Ersek
2015-07-14  9:43 ` Richard W.M. Jones
2015-07-14 18:23   ` Gabriel L. Somlo
2015-07-14 18:31     ` Gabriel L. Somlo
2015-07-14 18:48     ` Richard W.M. Jones
2015-07-14 18:51       ` Richard W.M. Jones
2015-07-14 19:16       ` Peter Maydell
2015-07-14 19:24       ` Gabriel L. Somlo
2015-07-14 19:24     ` Gerd Hoffmann
2015-07-16  0:43   ` Gabriel L. Somlo
2015-07-16 19:27     ` Eric Blake
2015-07-16 20:42       ` Gabriel L. Somlo
2015-07-14 11:38 ` Laszlo Ersek
2015-07-15 12:00 ` Matt Fleming [this message]
2015-07-20 21:19   ` Gabriel L. Somlo
2015-07-20 22:07     ` Laszlo Ersek
2015-07-25 23:21       ` Gabriel L. Somlo
2015-07-26  9:37         ` Laszlo Ersek
2015-07-15 14:08 ` Michael S. Tsirkin
2015-07-15 16:01   ` Igor Mammedov
2015-07-15 16:24     ` Michael S. Tsirkin
2015-07-16  1:21       ` Gabriel L. Somlo
2015-07-16  6:57       ` Igor Mammedov
2015-07-16  7:30         ` Michael S. Tsirkin
2015-07-16  9:50           ` Igor Mammedov
2015-07-16 10:25             ` Michael S. Tsirkin
2015-07-16 11:15               ` Igor Mammedov

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=1436961645.25906.20.camel@intel.com \
    --to=matt.fleming@intel.com \
    --cc=gleb@cloudius-systems.com \
    --cc=gsomlo@gmail.com \
    --cc=jordan.l.justen@intel.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=somlo@cmu.edu \
    /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.