ia64/xen-unstable
changeset 574:0ddcd1aeb420
bitkeeper revision 1.317 (3f0c0840dkPeEx-FKvCNpuxOGrbQAw)
Why was this a spinlock? We're protecting against other userspace
processes trying to open /proc/xeno/domains, not the kernel.
Switch to using a semaphore.
Why was this a spinlock? We're protecting against other userspace
processes trying to open /proc/xeno/domains, not the kernel.
Switch to using a semaphore.
author | sos22@labyrinth.cl.cam.ac.uk |
---|---|
date | Wed Jul 09 12:19:12 2003 +0000 (2003-07-09) |
parents | 4761636414af |
children | 956f93d4092c |
files | xenolinux-2.4.21-sparse/arch/xeno/drivers/dom0/dom0_core.c |
line diff
1.1 --- a/xenolinux-2.4.21-sparse/arch/xeno/drivers/dom0/dom0_core.c Wed Jul 09 11:33:55 2003 +0000 1.2 +++ b/xenolinux-2.4.21-sparse/arch/xeno/drivers/dom0/dom0_core.c Wed Jul 09 12:19:12 2003 +0000 1.3 @@ -189,7 +189,7 @@ static int dom0_cmd_write(struct file *f 1.4 1.5 static dom0_op_t proc_domains_op; 1.6 static int proc_domains_finished; 1.7 -static rwlock_t proc_xeno_domains_lock = RW_LOCK_UNLOCKED; 1.8 +static DECLARE_MUTEX(proc_xeno_domains_lock); 1.9 1.10 static void *xeno_domains_next(struct seq_file *s, void *v, loff_t *pos) 1.11 { 1.12 @@ -213,7 +213,7 @@ static void *xeno_domains_start(struct s 1.13 { 1.14 loff_t pos = *ppos; 1.15 1.16 - write_lock (&proc_xeno_domains_lock); 1.17 + down (&proc_xeno_domains_lock); 1.18 proc_domains_op.cmd = DOM0_GETDOMAININFO; 1.19 proc_domains_op.u.getdominfo.domain = 0; 1.20 (void)HYPERVISOR_dom0_op(&proc_domains_op); 1.21 @@ -229,7 +229,7 @@ static void *xeno_domains_start(struct s 1.22 1.23 static void xeno_domains_stop(struct seq_file *s, void *v) 1.24 { 1.25 - write_unlock (&proc_xeno_domains_lock); 1.26 + up(&proc_xeno_domains_lock); 1.27 } 1.28 1.29 static int xeno_domains_show(struct seq_file *s, void *v) 1.30 @@ -327,7 +327,6 @@ static unsigned long handle_dom0_cmd_map 1.31 return -EFAULT; 1.32 /* This seems to be assuming that the root of the page table is in 1.33 the first frame of the new domain's physical memory? */ 1.34 - /* XXX what happens if userspace forgets to do the unmap? */ 1.35 1.36 addr = direct_mmap(argbuf.start_pfn << PAGE_SHIFT, 1.37 argbuf.tot_pages << PAGE_SHIFT, 1.38 @@ -357,14 +356,14 @@ static int handle_dom0_cmd_dopgupdates(u 1.39 return -EFAULT; 1.40 1.41 /* argbuf.pgt_update_arr had better be direct mapped... */ 1.42 - return HYPERVISOR_pt_update(argbuf.pgt_update_arr, 1.43 + /* XXX check this */ 1.44 + return HYPERVISOR_pt_update((void *)argbuf.pgt_update_arr, 1.45 argbuf.num_pgt_updates); 1.46 } 1.47 1.48 static int dom0_cmd_ioctl(struct inode *inode, struct file *file, 1.49 unsigned int cmd, unsigned long data) 1.50 { 1.51 - printk("dom0_cmd ioctl command %x\n", cmd); 1.52 switch (cmd) { 1.53 case IOCTL_DOM0_CREATEDOMAIN: 1.54 return handle_dom0_cmd_createdomain(data); 1.55 @@ -375,8 +374,10 @@ static int dom0_cmd_ioctl(struct inode * 1.56 case IOCTL_DOM0_DOPGUPDATES: 1.57 return handle_dom0_cmd_dopgupdates(data); 1.58 default: 1.59 - printk("Unknown dom0_cmd ioctl!\n"); 1.60 - return -EINVAL; 1.61 + return -ENOTTY; /* It isn't obvious why this is the correct error 1.62 + code when an ioctl isn't recognised, but it 1.63 + does appear to be what's used in the rest of 1.64 + the kernel. */ 1.65 } 1.66 } 1.67