Hi Keir, thanks for merging the Linux patches we''ve been discussing. Please pull PowerPC Xen Linux support from http://xenbits.xensource.com/ext/ppc/linux-2.6.18-xen.hg Then, please pull from http://xenbits.xensource.com/ext/ppc/xen-unstable.hg Among other things, it includes changes necessary to run the new Linux 2.6.18 kernel. Thanks! -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Changes inside powerpc files are fine. Obviously powerpc-specific changes inside common files are usually fine. Changes to locking protocols in common files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please post patches for that kind of thing. -- Keir On 6/7/07 22:29, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:> Hi Keir, thanks for merging the Linux patches we''ve been discussing. > > Please pull PowerPC Xen Linux support from > http://xenbits.xensource.com/ext/ppc/linux-2.6.18-xen.hg > > Then, please pull from > http://xenbits.xensource.com/ext/ppc/xen-unstable.hg > Among other things, it includes changes necessary to run the new Linux > 2.6.18 kernel. > > Thanks!_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hollis Blanchard
2007-Jul-09 15:45 UTC
[Xen-devel] [PATCH] Take a writer lock for mmap_sem.
On Sat, 2007-07-07 at 10:20 +0100, Keir Fraser wrote:> Changes inside powerpc files are fine. Obviously powerpc-specific changes > inside common files are usually fine. Changes to locking protocols in common > files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please > post patches for that kind of thing.My mistake, I meant to send this separately. In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In the current Linux tree though, the locking is done in privcmd_ioctl(). However, since direct_remap_pfn_range() is modifying the mm_struct, shouldn''t that be a a write lock rather than a read lock? [XEN][LINUX] Take a writer lock for mmap_sem. direct_remap_pfn_range() will be modifying the mm. Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> diff -r e5f633c33025 drivers/xen/privcmd/privcmd.c --- a/drivers/xen/privcmd/privcmd.c Fri Jul 06 17:35:53 2007 +0100 +++ b/drivers/xen/privcmd/privcmd.c Mon Jul 09 10:07:32 2007 -0500 @@ -111,7 +112,7 @@ static int privcmd_ioctl(struct inode *i if (copy_from_user(&msg, p, sizeof(msg))) return -EFAULT; - down_read(&mm->mmap_sem); + down_write(&mm->mmap_sem); vma = find_vma(mm, msg.va); rc = -EINVAL; @@ -153,7 +154,7 @@ static int privcmd_ioctl(struct inode *i rc = 0; mmap_out: - up_read(&mm->mmap_sem); + up_write(&mm->mmap_sem); ret = rc; } break; @@ -176,14 +177,14 @@ static int privcmd_ioctl(struct inode *i if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT))) return -EINVAL; - down_read(&mm->mmap_sem); + down_write(&mm->mmap_sem); vma = find_vma(mm, m.addr); if (!vma || (m.addr != vma->vm_start) || ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) || !privcmd_enforce_singleshot_mapping(vma)) { - up_read(&mm->mmap_sem); + up_write(&mm->mmap_sem); return -EINVAL; } @@ -191,7 +192,7 @@ static int privcmd_ioctl(struct inode *i addr = m.addr; for (i = 0; i < nr_pages; i++, addr += PAGE_SIZE, p++) { if (get_user(mfn, p)) { - up_read(&mm->mmap_sem); + up_write(&mm->mmap_sem); return -EFAULT; } @@ -202,7 +203,7 @@ static int privcmd_ioctl(struct inode *i put_user(0xF0000000 | mfn, p); } - up_read(&mm->mmap_sem); + up_write(&mm->mmap_sem); ret = 0; } break; -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jul-09 16:18 UTC
Re: [Xen-devel] [PATCH] Take a writer lock for mmap_sem.
On 9/7/07 16:45, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:> > My mistake, I meant to send this separately. > > In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In > the current Linux tree though, the locking is done in privcmd_ioctl(). > > However, since direct_remap_pfn_range() is modifying the mm_struct, > shouldn''t that be a a write lock rather than a read lock?Ah yes, agreed. All other callers seem to get this implicitly because they are ->mmap handlers. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Keir, please pull from both http://xenbits.xensource.com/ext/ppc/linux-2.6.18-xen.hg and http://xenbits.xensource.com/ext/ppc/xen-unstable.hg Along with a couple build fixes, we now support in-guest profiling and support for the ACM hypercalls (thanks Stefan!). -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel