Re: Kernel Oops with shm namespace cleanups
On Thu, 2007-03-01 at 16:08 -0800, Bill Irwin wrote: >> Looks like I should grab these testcases for the sake of due diligence >> (not to say I intend to alter maintenance style from primarily review, >> approval, and bugfixing, not that I've been doing as much of any of those >> as I should). To which architectures and/or distributions have the >> userspace bits been ported, or otherwise run/tested on? A quick sniff >> test on an Altix suggests SLES and/or ia64 may trip up the scripts: On Fri, Mar 02, 2007 at 10:29:16AM -0600, Adam Litke wrote: > Right now we support x86, powerpc, and x86_64. Segment remapping and > hugetlb malloc won't work on ia64 until long format vhpt is supported (I > suspect). But the test framework should be adaptable to other > architectures. Those patches have been around for a while. I'll ping Tony Luck et al about that since I'm not entirely aware of what their issues might be. I should probably get some testing in on sparc64 at some point, too. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with shm namespace cleanups
On Thu, 2007-03-01 at 16:08 -0800, Bill Irwin wrote: > On Wed, Feb 28, 2007 at 02:13:29PM -0600, Adam Litke wrote: > > Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case > > causes the kernel to oops. To reproduce: Execute 'make check' in the > > latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages > > allocated. Using fewer huge pages will likely also trigger the oops. > > Libhugetlbfs can be downloaded from: > > http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz > > Looks like I should grab these testcases for the sake of due diligence > (not to say I intend to alter maintenance style from primarily review, > approval, and bugfixing, not that I've been doing as much of any of those > as I should). To which architectures and/or distributions have the > userspace bits been ported, or otherwise run/tested on? A quick sniff > test on an Altix suggests SLES and/or ia64 may trip up the scripts: Right now we support x86, powerpc, and x86_64. Segment remapping and hugetlb malloc won't work on ia64 until long format vhpt is supported (I suspect). But the test framework should be adaptable to other architectures. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with shm namespace cleanups
On Thu, 2007-03-01 at 16:08 -0800, Bill Irwin wrote: On Wed, Feb 28, 2007 at 02:13:29PM -0600, Adam Litke wrote: Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case causes the kernel to oops. To reproduce: Execute 'make check' in the latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages allocated. Using fewer huge pages will likely also trigger the oops. Libhugetlbfs can be downloaded from: http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz Looks like I should grab these testcases for the sake of due diligence (not to say I intend to alter maintenance style from primarily review, approval, and bugfixing, not that I've been doing as much of any of those as I should). To which architectures and/or distributions have the userspace bits been ported, or otherwise run/tested on? A quick sniff test on an Altix suggests SLES and/or ia64 may trip up the scripts: Right now we support x86, powerpc, and x86_64. Segment remapping and hugetlb malloc won't work on ia64 until long format vhpt is supported (I suspect). But the test framework should be adaptable to other architectures. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with shm namespace cleanups
On Thu, 2007-03-01 at 16:08 -0800, Bill Irwin wrote: Looks like I should grab these testcases for the sake of due diligence (not to say I intend to alter maintenance style from primarily review, approval, and bugfixing, not that I've been doing as much of any of those as I should). To which architectures and/or distributions have the userspace bits been ported, or otherwise run/tested on? A quick sniff test on an Altix suggests SLES and/or ia64 may trip up the scripts: On Fri, Mar 02, 2007 at 10:29:16AM -0600, Adam Litke wrote: Right now we support x86, powerpc, and x86_64. Segment remapping and hugetlb malloc won't work on ia64 until long format vhpt is supported (I suspect). But the test framework should be adaptable to other architectures. Those patches have been around for a while. I'll ping Tony Luck et al about that since I'm not entirely aware of what their issues might be. I should probably get some testing in on sparc64 at some point, too. -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with shm namespace cleanups
On Wed, Feb 28, 2007 at 02:13:29PM -0600, Adam Litke wrote: > Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case > causes the kernel to oops. To reproduce: Execute 'make check' in the > latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages > allocated. Using fewer huge pages will likely also trigger the oops. > Libhugetlbfs can be downloaded from: > http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz Looks like I should grab these testcases for the sake of due diligence (not to say I intend to alter maintenance style from primarily review, approval, and bugfixing, not that I've been doing as much of any of those as I should). To which architectures and/or distributions have the userspace bits been ported, or otherwise run/tested on? A quick sniff test on an Altix suggests SLES and/or ia64 may trip up the scripts: $ su -c "make check" Password: VERSION ./run_tests.sh: line 1: get_hugetlbfs_path: command not found run_tests.sh: unable to find hugetlbfs mountpoint make: *** [check] Error 1 -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with shm namespace cleanups
On Wed, Feb 28, 2007 at 02:13:29PM -0600, Adam Litke wrote: Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case causes the kernel to oops. To reproduce: Execute 'make check' in the latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages allocated. Using fewer huge pages will likely also trigger the oops. Libhugetlbfs can be downloaded from: http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz Looks like I should grab these testcases for the sake of due diligence (not to say I intend to alter maintenance style from primarily review, approval, and bugfixing, not that I've been doing as much of any of those as I should). To which architectures and/or distributions have the userspace bits been ported, or otherwise run/tested on? A quick sniff test on an Altix suggests SLES and/or ia64 may trip up the scripts: $ su -c make check Password: VERSION ./run_tests.sh: line 1: get_hugetlbfs_path: command not found run_tests.sh: unable to find hugetlbfs mountpoint make: *** [check] Error 1 -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with shm namespace cleanups
Adam Litke <[EMAIL PROTECTED]> writes:
> Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case
> causes the kernel to oops. To reproduce: Execute 'make check' in the
> latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages
> allocated. Using fewer huge pages will likely also trigger the oops.
> Libhugetlbfs can be downloaded from:
> http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz
>
> I have collected the following information:
Thanks. I'm going to be offline starting early tomorrow so I'm
unfortunately not going to be timely in tracing this one down.
Ok. Looking at the code I have a clue what is going on. I think
I must have been out of it the day I wrote this patch. I don't have
fsync or get_unmapped_area methods appropriately wrapped. I clearly
did not do a close audit of the filesystem methods that hugetlbfs
inodes use. I may have just gotten luck on other architectures.
get_unmapped_area looks like it will be a bit of a trick.
If it is just failing to wrap the methods a couple of file methods
then the patch below should fix it or come close. That's the best
I can do before I leave.
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index a60995a..44f1f05 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -168,7 +168,9 @@ void hugetlb_put_quota(struct address_space *mapping);
static inline int is_file_hugepages(struct file *file)
{
- return file->f_op == _file_operations;
+ return (file->f_op == _file_operations) ||
+ is_file_shm_hugepages(file);
+
}
static inline void set_file_hugepages(struct file *file)
diff --git a/include/linux/shm.h b/include/linux/shm.h
index a2c896a..ad2e3af 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -96,12 +96,17 @@ struct shmid_kernel /* private to the kernel */
#ifdef CONFIG_SYSVIPC
long do_shmat(int shmid, char __user *shmaddr, int shmflg, unsigned long
*addr);
+extern int is_file_shm_hugepages(struct file *file);
#else
static inline long do_shmat(int shmid, char __user *shmaddr,
int shmflg, unsigned long *addr)
{
return -ENOSYS;
}
+static inline int is_file_shm_hugepages(struct file *file)
+{
+ return 0;
+}
#endif
#endif /* __KERNEL__ */
diff --git a/ipc/shm.c b/ipc/shm.c
index 26b935b..93cfa35 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -235,7 +235,7 @@ struct page *shm_nopage(struct vm_area_struct *vma,
unsigned long address, int *
}
#ifdef CONFIG_NUMA
-int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
+static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
struct file *file = vma->vm_file;
struct shm_file_data *sfd = shm_file_data(file);
@@ -245,7 +245,7 @@ int shm_set_policy(struct vm_area_struct *vma, struct
mempolicy *new)
return err;
}
-struct mempolicy *shm_get_policy(struct vm_area_struct *vma, unsigned long
addr)
+static struct mempolicy *shm_get_policy(struct vm_area_struct *vma, unsigned
long addr)
{
struct file *file = vma->vm_file;
struct shm_file_data *sfd = shm_file_data(file);
@@ -284,21 +284,41 @@ static int shm_release(struct inode *ino, struct file
*file)
return 0;
}
-#ifndef CONFIG_MMU
+static int shm_fsync(struct file *file, struct dentry *dentry, int datasync)
+{
+ int (*fsync) (struct file *, struct dentry *, int datasync);
+ struct shm_file_data *sfd;
+ int ret;
+ ret = -EINVAL;
+ sfd = shm_file_data(file);
+ fsync = sfd->file->f_op->fsync;
+ if (fsync)
+ ret = fsync(sfd->file, sfd->file->f_path.dentry, datasync);
+ return ret;
+}
+
static unsigned long shm_get_unmapped_area(struct file *file,
unsigned long addr, unsigned long len, unsigned long pgoff,
unsigned long flags)
{
struct shm_file_data *sfd = shm_file_data(file);
- return sfd->file->f_op->get_unmapped_area(sfd->file, addr, len, pgoff,
- flags);
+ return get_unmapped_area(file, addr, len, pgoff, flags);
+}
+
+int is_file_shm_hugepages(struct file *file)
+{
+ int ret = 0;
+ if (file->f_op == _file_operations) {
+ struct shm_file_data *sfd;
+ sfd = shm_file_data(file);
+ ret = is_file_hugepages(file);
+ }
+ return ret;
}
-#else
-#define shm_get_unmapped_area NULL
-#endif
static struct file_operations shm_file_operations = {
.mmap = shm_mmap,
+ .fsync = shm_fsync,
.release= shm_release,
.get_unmapped_area = shm_get_unmapped_area,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel Oops with shm namespace cleanups
Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case causes the kernel to oops. To reproduce: Execute 'make check' in the latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages allocated. Using fewer huge pages will likely also trigger the oops. Libhugetlbfs can be downloaded from: http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz I have collected the following information: bc56bba8f31bd99f350a5ebfd43d50f411b620c7 is first bad commit commit bc56bba8f31bd99f350a5ebfd43d50f411b620c7 Author: Eric W. Biederman <[EMAIL PROTECTED]> Date: Tue Feb 20 13:57:53 2007 -0800 [PATCH] shm: make sysv ipc shared memory use stacked files [ cut here ] Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=32 NUMA Modules linked in: NIP: C002EA80 LR: C00A3F70 CTR: 6400 REGS: c0077967b770 TRAP: 0700 Not tainted (2.6.20-g1df49008) MSR: 80029032 CR: 28000448 XER: TASK = c0002f6737d0[3042] 'shm-fork' THREAD: c00779678000 CPU: 1 GPR00: C0077967B9F0 C06725A0 C0002F94EC00 GPR04: 93FD1000 93FD1000 0200 93FD1000 GPR08: 0001 0001 0001 GPR12: 48000444 C058BE00 FFEE8094 GPR16: 0200 100AC5E8 100A 1008 GPR20: 93FD1000 C0077FDBD088 C0002F94EC00 GPR24: C0077FDBD088 0200 C0002F94EC00 93FD1000 GPR28: C0077967BEA0 93FD1000 C05A2F58 C0077FDBD088 NIP [C002EA80] .huge_pte_alloc+0x7c/0x1dc LR [C00A3F70] .hugetlb_fault+0x48/0x150 Call Trace: [C0077967B9F0] [C0077967BA80] 0xc0077967ba80 (unreliable) [C0077967BAA0] [C00A3F70] .hugetlb_fault+0x48/0x150 [C0077967BB50] [C0094254] .__handle_mm_fault+0xa8/0x119c [C0077967BC50] [C002A1E0] .do_page_fault+0x3a8/0x57c [C0077967BE30] [C0004AFC] handle_page_fault+0x20/0x58 Instruction dump: 7820 7fa40040 409d0010 a00302be 7889c220 480c a00302bc 78892702 7c004e30 780907e1 40820008 3961 <0b0b> e922adb8 3800 ebda0048 [ cut here ] kernel BUG at /home/aglitke/git/linux-2.6/mm/hugetlb.c:375! Oops: Exception in kernel mode, sig: 5 [#2] SMP NR_CPUS=32 NUMA Modules linked in: NIP: C00A3518 LR: C00A376C CTR: C006B348 REGS: c0077967ace0 TRAP: 0700 Not tainted (2.6.20-g1df49008) MSR: 80029032 CR: 42022442 XER: TASK = c0002f6737d0[3042] 'shm-fork' THREAD: c00779678000 CPU: 1 GPR00: 0018 C0077967AF60 C06725A0 C0077FDBD088 GPR04: 93FD1000 F7FD1000 C0077FFA5A83 C0077FFEF6E0 GPR08: 10013000 00FD1000 10013000 C0697EB0 GPR12: 2200 C058BE00 10013000 10013000 GPR16: 10013000 C0077967B120 GPR20: F7FD1000 C40DBDD0 C0077FDBD088 GPR24: 00EF9C340793 10013000 C0002F94EC00 C0077967AFD0 GPR28: F7FD1000 93FD1000 C05A2F58 C0002F94EC00 NIP [C00A3518] .__unmap_hugepage_range+0x68/0x264 LR [C00A376C] .unmap_hugepage_range+0x58/0xa0 Call Trace: [C0077967AF60] [0001] 0x1 (unreliable) [C0077967B020] [C00A376C] .unmap_hugepage_range+0x58/0xa0 [C0077967B0B0] [C0091464] .unmap_vmas+0x17c/0x954 [C0077967B210] [C0099488] .exit_mmap+0xa4/0x17c [C0077967B2C0] [C004CB08] .mmput+0x60/0x160 [C0077967B360] [C0052E4C] .exit_mm+0x130/0x154 [C0077967B400] [C00535D8] .do_exit+0x238/0x964 [C0077967B4C0] [C0022AC4] .die+0x150/0x154 [C0077967B550] [C0022B10] ._exception+0x48/0x138 [C0077967B660] [C0023634] .program_check_exception+0x5cc/0x5e4 [C0077967B700] [C00046F4] program_check_common+0xf4/0x100 --- Exception: 700 at .huge_pte_alloc+0x7c/0x1dc LR = .hugetlb_fault+0x48/0x150 [C0077967B9F0] [C0077967BA80] 0xc0077967ba80 (unreliable) [C0077967BAA0] [C00A3F70] .hugetlb_fault+0x48/0x150 [C0077967BB50] [C0094254] .__handle_mm_fault+0xa8/0x119c [C0077967BC50] [C002A1E0] .do_page_fault+0x3a8/0x57c [C0077967BE30] [C0004AFC] handle_page_fault+0x20/0x58 Instruction dump: fb610078 780957e3 ebe3 7c26 54001ffe 0b00 e97e8030 3921 800b 7d290036 3929 7c894838 <0b09> 800b 3921 7d290036 Fixing recursive fault but reboot is needed! BUG: soft lockup detected on CPU#0! Call Trace: [C00779AD74C0] [C000F588] .show_stack+0x68/0x1b4 (unreliable) [C00779AD7570] [C007C5E0] .softlockup_tick+0xec/0x140 [C00779AD7630]
Kernel Oops with shm namespace cleanups
Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case causes the kernel to oops. To reproduce: Execute 'make check' in the latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages allocated. Using fewer huge pages will likely also trigger the oops. Libhugetlbfs can be downloaded from: http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz I have collected the following information: bc56bba8f31bd99f350a5ebfd43d50f411b620c7 is first bad commit commit bc56bba8f31bd99f350a5ebfd43d50f411b620c7 Author: Eric W. Biederman [EMAIL PROTECTED] Date: Tue Feb 20 13:57:53 2007 -0800 [PATCH] shm: make sysv ipc shared memory use stacked files [ cut here ] Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=32 NUMA Modules linked in: NIP: C002EA80 LR: C00A3F70 CTR: 6400 REGS: c0077967b770 TRAP: 0700 Not tainted (2.6.20-g1df49008) MSR: 80029032 EE,ME,IR,DR CR: 28000448 XER: TASK = c0002f6737d0[3042] 'shm-fork' THREAD: c00779678000 CPU: 1 GPR00: C0077967B9F0 C06725A0 C0002F94EC00 GPR04: 93FD1000 93FD1000 0200 93FD1000 GPR08: 0001 0001 0001 GPR12: 48000444 C058BE00 FFEE8094 GPR16: 0200 100AC5E8 100A 1008 GPR20: 93FD1000 C0077FDBD088 C0002F94EC00 GPR24: C0077FDBD088 0200 C0002F94EC00 93FD1000 GPR28: C0077967BEA0 93FD1000 C05A2F58 C0077FDBD088 NIP [C002EA80] .huge_pte_alloc+0x7c/0x1dc LR [C00A3F70] .hugetlb_fault+0x48/0x150 Call Trace: [C0077967B9F0] [C0077967BA80] 0xc0077967ba80 (unreliable) [C0077967BAA0] [C00A3F70] .hugetlb_fault+0x48/0x150 [C0077967BB50] [C0094254] .__handle_mm_fault+0xa8/0x119c [C0077967BC50] [C002A1E0] .do_page_fault+0x3a8/0x57c [C0077967BE30] [C0004AFC] handle_page_fault+0x20/0x58 Instruction dump: 7820 7fa40040 409d0010 a00302be 7889c220 480c a00302bc 78892702 7c004e30 780907e1 40820008 3961 0b0b e922adb8 3800 ebda0048 [ cut here ] kernel BUG at /home/aglitke/git/linux-2.6/mm/hugetlb.c:375! Oops: Exception in kernel mode, sig: 5 [#2] SMP NR_CPUS=32 NUMA Modules linked in: NIP: C00A3518 LR: C00A376C CTR: C006B348 REGS: c0077967ace0 TRAP: 0700 Not tainted (2.6.20-g1df49008) MSR: 80029032 EE,ME,IR,DR CR: 42022442 XER: TASK = c0002f6737d0[3042] 'shm-fork' THREAD: c00779678000 CPU: 1 GPR00: 0018 C0077967AF60 C06725A0 C0077FDBD088 GPR04: 93FD1000 F7FD1000 C0077FFA5A83 C0077FFEF6E0 GPR08: 10013000 00FD1000 10013000 C0697EB0 GPR12: 2200 C058BE00 10013000 10013000 GPR16: 10013000 C0077967B120 GPR20: F7FD1000 C40DBDD0 C0077FDBD088 GPR24: 00EF9C340793 10013000 C0002F94EC00 C0077967AFD0 GPR28: F7FD1000 93FD1000 C05A2F58 C0002F94EC00 NIP [C00A3518] .__unmap_hugepage_range+0x68/0x264 LR [C00A376C] .unmap_hugepage_range+0x58/0xa0 Call Trace: [C0077967AF60] [0001] 0x1 (unreliable) [C0077967B020] [C00A376C] .unmap_hugepage_range+0x58/0xa0 [C0077967B0B0] [C0091464] .unmap_vmas+0x17c/0x954 [C0077967B210] [C0099488] .exit_mmap+0xa4/0x17c [C0077967B2C0] [C004CB08] .mmput+0x60/0x160 [C0077967B360] [C0052E4C] .exit_mm+0x130/0x154 [C0077967B400] [C00535D8] .do_exit+0x238/0x964 [C0077967B4C0] [C0022AC4] .die+0x150/0x154 [C0077967B550] [C0022B10] ._exception+0x48/0x138 [C0077967B660] [C0023634] .program_check_exception+0x5cc/0x5e4 [C0077967B700] [C00046F4] program_check_common+0xf4/0x100 --- Exception: 700 at .huge_pte_alloc+0x7c/0x1dc LR = .hugetlb_fault+0x48/0x150 [C0077967B9F0] [C0077967BA80] 0xc0077967ba80 (unreliable) [C0077967BAA0] [C00A3F70] .hugetlb_fault+0x48/0x150 [C0077967BB50] [C0094254] .__handle_mm_fault+0xa8/0x119c [C0077967BC50] [C002A1E0] .do_page_fault+0x3a8/0x57c [C0077967BE30] [C0004AFC] handle_page_fault+0x20/0x58 Instruction dump: fb610078 780957e3 ebe3 7c26 54001ffe 0b00 e97e8030 3921 800b 7d290036 3929 7c894838 0b09 800b 3921 7d290036 Fixing recursive fault but reboot is needed! BUG: soft lockup detected on CPU#0! Call Trace: [C00779AD74C0] [C000F588] .show_stack+0x68/0x1b4 (unreliable) [C00779AD7570] [C007C5E0] .softlockup_tick+0xec/0x140
Re: Kernel Oops with shm namespace cleanups
Adam Litke [EMAIL PROTECTED] writes:
Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case
causes the kernel to oops. To reproduce: Execute 'make check' in the
latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages
allocated. Using fewer huge pages will likely also trigger the oops.
Libhugetlbfs can be downloaded from:
http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz
I have collected the following information:
Thanks. I'm going to be offline starting early tomorrow so I'm
unfortunately not going to be timely in tracing this one down.
Ok. Looking at the code I have a clue what is going on. I think
I must have been out of it the day I wrote this patch. I don't have
fsync or get_unmapped_area methods appropriately wrapped. I clearly
did not do a close audit of the filesystem methods that hugetlbfs
inodes use. I may have just gotten luck on other architectures.
get_unmapped_area looks like it will be a bit of a trick.
If it is just failing to wrap the methods a couple of file methods
then the patch below should fix it or come close. That's the best
I can do before I leave.
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index a60995a..44f1f05 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -168,7 +168,9 @@ void hugetlb_put_quota(struct address_space *mapping);
static inline int is_file_hugepages(struct file *file)
{
- return file-f_op == hugetlbfs_file_operations;
+ return (file-f_op == hugetlbfs_file_operations) ||
+ is_file_shm_hugepages(file);
+
}
static inline void set_file_hugepages(struct file *file)
diff --git a/include/linux/shm.h b/include/linux/shm.h
index a2c896a..ad2e3af 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -96,12 +96,17 @@ struct shmid_kernel /* private to the kernel */
#ifdef CONFIG_SYSVIPC
long do_shmat(int shmid, char __user *shmaddr, int shmflg, unsigned long
*addr);
+extern int is_file_shm_hugepages(struct file *file);
#else
static inline long do_shmat(int shmid, char __user *shmaddr,
int shmflg, unsigned long *addr)
{
return -ENOSYS;
}
+static inline int is_file_shm_hugepages(struct file *file)
+{
+ return 0;
+}
#endif
#endif /* __KERNEL__ */
diff --git a/ipc/shm.c b/ipc/shm.c
index 26b935b..93cfa35 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -235,7 +235,7 @@ struct page *shm_nopage(struct vm_area_struct *vma,
unsigned long address, int *
}
#ifdef CONFIG_NUMA
-int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
+static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
struct file *file = vma-vm_file;
struct shm_file_data *sfd = shm_file_data(file);
@@ -245,7 +245,7 @@ int shm_set_policy(struct vm_area_struct *vma, struct
mempolicy *new)
return err;
}
-struct mempolicy *shm_get_policy(struct vm_area_struct *vma, unsigned long
addr)
+static struct mempolicy *shm_get_policy(struct vm_area_struct *vma, unsigned
long addr)
{
struct file *file = vma-vm_file;
struct shm_file_data *sfd = shm_file_data(file);
@@ -284,21 +284,41 @@ static int shm_release(struct inode *ino, struct file
*file)
return 0;
}
-#ifndef CONFIG_MMU
+static int shm_fsync(struct file *file, struct dentry *dentry, int datasync)
+{
+ int (*fsync) (struct file *, struct dentry *, int datasync);
+ struct shm_file_data *sfd;
+ int ret;
+ ret = -EINVAL;
+ sfd = shm_file_data(file);
+ fsync = sfd-file-f_op-fsync;
+ if (fsync)
+ ret = fsync(sfd-file, sfd-file-f_path.dentry, datasync);
+ return ret;
+}
+
static unsigned long shm_get_unmapped_area(struct file *file,
unsigned long addr, unsigned long len, unsigned long pgoff,
unsigned long flags)
{
struct shm_file_data *sfd = shm_file_data(file);
- return sfd-file-f_op-get_unmapped_area(sfd-file, addr, len, pgoff,
- flags);
+ return get_unmapped_area(file, addr, len, pgoff, flags);
+}
+
+int is_file_shm_hugepages(struct file *file)
+{
+ int ret = 0;
+ if (file-f_op == shm_file_operations) {
+ struct shm_file_data *sfd;
+ sfd = shm_file_data(file);
+ ret = is_file_hugepages(file);
+ }
+ return ret;
}
-#else
-#define shm_get_unmapped_area NULL
-#endif
static struct file_operations shm_file_operations = {
.mmap = shm_mmap,
+ .fsync = shm_fsync,
.release= shm_release,
.get_unmapped_area = shm_get_unmapped_area,
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
