qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).