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.
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