xenbus_mkdir("/tools", "name") fails

xenbus_mkdir("/tools", "name") fails

[Anton Korenyushkin]

Hi,

I wrote subj in my module and i get instant reboot after calling this 
function. It doesn't depend on were xenstored started or not.

Please, explain me this thing: can i write back/front end drivers in the next 
manner: backend creates directory mydir in xenstore. Then frontends write 
files mydir/file-<domid> by xenbus_printf where they put grant reference to 
the shared frame and event chanel's port. Then backend reads this information 
and communicate with frontends. If it is right way for what reason xenbus 
drivers exist? And in what path in xenstore should i put mydir?

If it is not a right way, how to use xenbus drivers? I tryed to make simple 
front/back end drivers. They register only probe function in xenbus_driver 
struct and in this function do simple printk and return 0, but this function 
is never called. Backend module registers its driver by 
xenbus_register_backend, frontend by xenbus_register_device.

-- 
Best regards,
Anton Korenyushkin
mailto:tiger@swsoft.mipt.ru

Re: xenbus_mkdir("/tools", "name") fails

[NAHieu]

On 9/28/05, Anton Korenyushkin <tiger@swsoft.mipt.ru> wrote:
> Hi,
>
> I wrote subj in my module and i get instant reboot after calling this
> function. It doesn't depend on were xenstored started or not.
>

I guess something wrong with your code. I wrote some kernel code uses
xenbus, and see no problem.

Why dont you post your code here and let people comment on it?

Hieu

Re: xenbus_mkdir("/tools", "name") fails

[Anton Korenyushkin]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Wednesday 28 September 2005 07:47, NAHieu wrote:
> On 9/28/05, Anton Korenyushkin <tiger@swsoft.mipt.ru> wrote:
> > Hi,
> >
> > I wrote subj in my module and i get instant reboot after calling this
> > function. It doesn't depend on were xenstored started or not.
>
> I guess something wrong with your code. I wrote some kernel code uses
> xenbus, and see no problem.
>
> Why dont you post your code here and let people comment on it?
>
> Hieu
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

I have attached module's code. There are a lot of proc fs stuff in it, 
xenbus_mkdir is called when root writes something into /proc/xen/prmigr. I 
execute commands xend start && echo 'hi' >/proc/xen/prmigr. And then i get 
reboot.

-- 
Best regards,
Anton Korenyushkin
mailto:tiger@swsoft.mipt.ru

[-- Attachment #2: prmigr_back.c --]
[-- Type: text/x-csrc, Size: 2240 bytes --]

/******************************************************************************
 * prmigr_back.c
 * 
 * XenLinux process migration tool
 * 
 * Copyright (c) 2005 Anton Korenyushkin tiger@swsoft.mipt.ru
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <asm/uaccess.h>
#include <asm-xen/xen_proc.h>
#include <asm-xen/gnttab.h>
#include <asm-xen/evtchn.h>
#include <asm-xen/xenbus.h>

#define PRMIGR_PROC_FNAME "prmigr"
#define PRMIGR_DIR "/tools"

/* proc file system stuff */

static struct proc_dir_entry *prmigr_proc_file;

static ssize_t prmigr_input(struct file *filp,
			    const char *buff,
			    size_t len,
			    loff_t * off)
{
	int err;

 	err = xenbus_mkdir(PRMIGR_DIR, "prmigr");
	if (err)
		printk(">>>prmigr_back: mkdir failed with %d\n", err);
	else
		printk(">>>prmigr_back: mkdir succeded\n");

	return len;
}


static int prmigr_permission(struct inode *inode, int op, struct nameidata *foo)
{
	if (op == 2 && current->euid == 0)
		return 0;
	return -EACCES;
}

int prmigr_open(struct inode *inode, struct file *file)
{
	try_module_get(THIS_MODULE);
	return 0;
}

int prmigr_close(struct inode *inode, struct file *file)
{
	module_put(THIS_MODULE);
	return 0;		/* success */
}

static struct file_operations prmigr_fops = {
	.write = prmigr_input,
	.open = prmigr_open,
	.release = prmigr_close,
};

static struct inode_operations prmigr_iops = {
	.permission = prmigr_permission,
};


/* Initialisation stuff */

static int __init prmigr_back_init(void)
{
	int ret = 0;

	prmigr_proc_file = create_xen_proc_entry(PRMIGR_PROC_FNAME, 0200);
	prmigr_proc_file->owner = THIS_MODULE;
	prmigr_proc_file->proc_iops = &prmigr_iops;
	prmigr_proc_file->proc_fops = &prmigr_fops;
	prmigr_proc_file->mode = S_IWUSR;
	prmigr_proc_file->uid = 0;
	prmigr_proc_file->gid = 0;
	prmigr_proc_file->size = 0;

	if (prmigr_proc_file == NULL) {
		ret = -ENOMEM;
		remove_xen_proc_entry(PRMIGR_PROC_FNAME);
		/* FIXME */
		printk(KERN_INFO "Error: Could not initialize %s/%s",
		       "/proc/xen",
		       PRMIGR_PROC_FNAME);
	}

	return ret;
}

__initcall(prmigr_back_init);

/*
 * Local variables:
 *  c-file-style: "linux"
 *  indent-tabs-mode: t
 *  c-indent-level: 8
 *  c-basic-offset: 8
 *  tab-width: 8
 * End:
 */

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: xenbus_mkdir("/tools", "name") fails

[Keir Fraser]

On 28 Sep 2005, at 14:07, Anton Korenyushkin wrote:

> I have attached module's code. There are a lot of proc fs stuff in it,
> xenbus_mkdir is called when root writes something into 
> /proc/xen/prmigr. I
> execute commands xend start && echo 'hi' >/proc/xen/prmigr. And then i 
> get
> reboot.

Most obvious problem I can see is that the entire access isn;t 
protected by xenbus_lock. Given the current interface you would need to 
manually acquire and release the lock around your mkdir call. Actually 
I think that is pretty gross for singleton accesses like this. I'll 
change the interface to internally do the locking it requires -- 
exposing xenbus_lock outside xenbus is not really on. Especially since 
we hope to improve the locking strategy in future!

I'll check somethign appropriate in and let you know to give your 
driver another spin.

  -- Keir