Re: [PATCH v2 1/6] xen: xensyms support

[David Vrabel <david.vrabel@citrix.com>]

On 06/06/14 18:44, Boris Ostrovsky wrote:
> Export Xen symbols to dom0 via /proc/xen/xensyms (similar to /proc/kallsyms).
[...]
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -240,4 +240,9 @@ config XEN_MCE_LOG
>  config XEN_HAVE_PVMMU
>         bool
>  
> +config XEN_SYMS
> +       bool "Xen symbols"
> +       depends on XEN_DOM0 && XENFS
> +       default y if KALLSYMS

This needs documentation.

> --- /dev/null
> +++ b/drivers/xen/xenfs/xensyms.c
> @@ -0,0 +1,124 @@
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/seq_file.h>
> +#include <linux/fs.h>
> +#include <linux/mm.h>
> +#include <linux/proc_fs.h>
> +#include <linux/slab.h>
> +#include <xen/interface/platform.h>
> +#include <asm/xen/hypercall.h>
> +#include <xen/xen-ops.h>
> +#include "xenfs.h"
> +
> +
> +#define XEN_KSYM_NAME_LEN 127 /* Hypervisor may have different name length */

Shouldn't this be exported in the hypervisor headers then?

> +static int xensyms_release(struct inode *inode, struct file *file)
> +{
> +	struct seq_file *m = file->private_data;
> +	struct xen_platform_op *op = (struct xen_platform_op *)m->private;
> +
> +	kfree(op->u.symdata.name);

Isn't op->u.symdata.name a guest handle?  I think you need to extract
the pointer here?

David