Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

Re: [stable] 2.6.16.6 breaks java... sort of

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


greg at kroah

Apr 19, 2006, 12:28 PM

Post #1 of 16 (3179 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of

On Wed, Apr 19, 2006 at 12:52:33PM -0600, David Wilk wrote:
> Howdy folks. thanks for the great work on the stable series, btw.
>
> I think an issue was introduced with mprotect (the first patch in
> 2.6.16.6). With 2.6.16.5, tomcat runs fine (in sun-1.5), but in
> 2.6.16.7, the JVM bails out complaining that it couldn't allocate
> enough heap space.
>
> If I remove '-Xmx768m' from JAVA_OPTS, then the JVM is able to
> startup. The machine had 1GB of RAM and 2GB of swap, so it should
> have had plenty to give the JVM the 1GB it expects to get with an Xmx
> of 768MB, and this worked in 2.6.16.5 and below.
>
> I don't know if this is expected and satisfactory behavior, but I
> figured I should give ya'll the heads up.

Odds are it isn't "expected", but Hugh would be the best judge of that.
Hugh?

thanks for letting us know about this,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hugh at veritas

Apr 19, 2006, 12:57 PM

Post #2 of 16 (3123 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

On Wed, 19 Apr 2006, Greg KH wrote:
> On Wed, Apr 19, 2006 at 12:52:33PM -0600, David Wilk wrote:
> >
> > I think an issue was introduced with mprotect (the first patch in
> > 2.6.16.6). With 2.6.16.5, tomcat runs fine (in sun-1.5), but in
> > 2.6.16.7, the JVM bails out complaining that it couldn't allocate
> > enough heap space.
> >
> > If I remove '-Xmx768m' from JAVA_OPTS, then the JVM is able to
> > startup. The machine had 1GB of RAM and 2GB of swap, so it should
> > have had plenty to give the JVM the 1GB it expects to get with an Xmx
> > of 768MB, and this worked in 2.6.16.5 and below.
> >
> > I don't know if this is expected and satisfactory behavior, but I
> > figured I should give ya'll the heads up.
>
> Odds are it isn't "expected", but Hugh would be the best judge of that.
> Hugh?

Neither expected nor satisfactory. Sorry about that. We were hoping
the straightforward shm/mprotect fix would be good enough, but it
appears not. JVM is probably doing something we can allow with a
more complicated patch, but it _might_ turn out to be doing something
we simply cannot allow: I'll hope for the first and work out a patch
for that; but won't be ready to post it until tomorrow.

If you can get an strace of what it's doing, David, please mail that
to me; but I'm guessing that it may be hard to get, and dispiritingly
large: so don't worry unless it's easy for you.

> thanks for letting us know about this,

Indeed, and sorry for the inconvenience.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hugh at veritas

Apr 20, 2006, 9:24 AM

Post #3 of 16 (3113 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

On Wed, 19 Apr 2006, Hugh Dickins wrote:
> On Wed, 19 Apr 2006, Greg KH wrote:
> > On Wed, Apr 19, 2006 at 12:52:33PM -0600, David Wilk wrote:
> > >
> > > I think an issue was introduced with mprotect (the first patch in
> > > 2.6.16.6). With 2.6.16.5, tomcat runs fine (in sun-1.5), but in
> > > 2.6.16.7, the JVM bails out complaining that it couldn't allocate
> > > enough heap space.
>
> Neither expected nor satisfactory. Sorry about that. We were hoping
> the straightforward shm/mprotect fix would be good enough, but it
> appears not. JVM is probably doing something we can allow with a
> more complicated patch, but it _might_ turn out to be doing something
> we simply cannot allow: I'll hope for the first and work out a patch
> for that; but won't be ready to post it until tomorrow.

David, would you please try this patch on top of your 2.6.16.7 or later.
The first hunk undoes the problematic patch, the remainder does it in a
more permissive way. Aesthetically, not as satisfactory as the previous
patch; but it's important that we not break userspace, unless security
absolutely demands. Please let us know how this fares: thanks.

Hugh

--- 2.6.16.9/ipc/shm.c 2006-04-20 11:59:03.000000000 +0100
+++ linux/ipc/shm.c 2006-04-20 16:57:36.000000000 +0100
@@ -161,8 +161,6 @@ static int shm_mmap(struct file * file,
ret = shmem_mmap(file, vma);
if (ret == 0) {
vma->vm_ops = &shm_vm_ops;
- if (!(vma->vm_flags & VM_WRITE))
- vma->vm_flags &= ~VM_MAYWRITE;
shm_inc(file->f_dentry->d_inode->i_ino);
}

@@ -677,6 +675,8 @@ out:
*/
long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
{
+ struct mm_struct *mm = current->mm;
+ struct vm_area_struct *vma;
struct shmid_kernel *shp;
unsigned long addr;
unsigned long size;
@@ -684,7 +684,7 @@ long do_shmat(int shmid, char __user *sh
int err;
unsigned long flags;
unsigned long prot;
- unsigned long o_flags;
+ int maywrite;
int acc_mode;
void *user_addr;

@@ -711,11 +711,11 @@ long do_shmat(int shmid, char __user *sh

if (shmflg & SHM_RDONLY) {
prot = PROT_READ;
- o_flags = O_RDONLY;
+ maywrite = 0;
acc_mode = S_IRUGO;
} else {
prot = PROT_READ | PROT_WRITE;
- o_flags = O_RDWR;
+ maywrite = 1;
acc_mode = S_IRUGO | S_IWUGO;
}
if (shmflg & SHM_EXEC) {
@@ -748,30 +748,43 @@ long do_shmat(int shmid, char __user *sh
shm_unlock(shp);
return err;
}
-
+
+ if (!maywrite && !ipcperms_dac(&shp->shm_perm, S_IWUGO))
+ maywrite = 1;
+
file = shp->shm_file;
size = i_size_read(file->f_dentry->d_inode);
shp->shm_nattch++;
shm_unlock(shp);

- down_write(&current->mm->mmap_sem);
+ down_write(&mm->mmap_sem);
if (addr && !(shmflg & SHM_REMAP)) {
user_addr = ERR_PTR(-EINVAL);
- if (find_vma_intersection(current->mm, addr, addr + size))
+ if (find_vma_intersection(mm, addr, addr + size))
goto invalid;
/*
* If shm segment goes below stack, make sure there is some
* space left for the stack to grow (at least 4 pages).
*/
- if (addr < current->mm->start_stack &&
- addr > current->mm->start_stack - size - PAGE_SIZE * 5)
+ if (addr < mm->start_stack &&
+ addr > mm->start_stack - size - PAGE_SIZE * 5)
goto invalid;
}
-
+
user_addr = (void*) do_mmap (file, addr, size, prot, flags, 0);

+ if (!maywrite && !IS_ERR(user_addr)) {
+ /*
+ * Prevent mprotect from giving write permission later on.
+ * We would prefer just to clear VM_MAYWRITE from a readonly
+ * attachment in shm_mmap, but it seems that JVM has got into
+ * the habit of attaching readonly then mprotecting to write.
+ */
+ vma = find_vma(mm, (unsigned long) user_addr);
+ vma->vm_flags &= ~VM_MAYWRITE;
+ }
invalid:
- up_write(&current->mm->mmap_sem);
+ up_write(&mm->mmap_sem);

down (&shm_ids.sem);
if(!(shp = shm_lock(shmid)))
--- 2.6.16.9/ipc/util.c 2006-03-20 05:53:29.000000000 +0000
+++ linux/ipc/util.c 2006-04-20 16:57:36.000000000 +0100
@@ -464,7 +464,7 @@ void ipc_rcu_putref(void *ptr)
* to ipc resources. return 0 if allowed
*/

-int ipcperms (struct kern_ipc_perm *ipcp, short flag)
+int ipcperms_dac(struct kern_ipc_perm *ipcp, short flag)
{ /* flag will most probably be 0 or S_...UGO from <linux/stat.h> */
int requested_mode, granted_mode;

@@ -478,7 +478,13 @@ int ipcperms (struct kern_ipc_perm *ipcp
if ((requested_mode & ~granted_mode & 0007) &&
!capable(CAP_IPC_OWNER))
return -1;
+ return 0;
+}

+int ipcperms(struct kern_ipc_perm *ipcp, short flag)
+{
+ if (ipcperms_dac(ipcp, flag))
+ return -1;
return security_ipc_permission(ipcp, flag);
}

--- 2.6.16.9/ipc/util.h 2006-03-20 05:53:29.000000000 +0000
+++ linux/ipc/util.h 2006-04-20 16:57:36.000000000 +0100
@@ -47,7 +47,8 @@ int ipc_addid(struct ipc_ids* ids, struc
/* must be called with both locks acquired. */
struct kern_ipc_perm* ipc_rmid(struct ipc_ids* ids, int id);

-int ipcperms (struct kern_ipc_perm *ipcp, short flg);
+int ipcperms_dac(struct kern_ipc_perm *ipcp, short flag);
+int ipcperms(struct kern_ipc_perm *ipcp, short flag);

/* for rare, potentially huge allocations.
* both function can sleep
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davidwilk at gmail

Apr 20, 2006, 10:10 AM

Post #4 of 16 (3096 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

Yes, absolutely. I'd love to help test.

I feel obligated to point out that this problem only occured when I
had the Xmx set to 768MB on a machine with only 1GB of ram (3GB total
VM), although it might have caused problems when the JVM eventually
requested more heap space (without the initial grab that Xmx=768m
forces).

I applaud all efforts to secure the kernel, and wouldn't want to
stifle that effort in any way.

I'll give this a whirl and get right back to you.

thanks,
Dave

On 4/20/06, Hugh Dickins <hugh [at] veritas> wrote:
> On Wed, 19 Apr 2006, Hugh Dickins wrote:
> > On Wed, 19 Apr 2006, Greg KH wrote:
> > > On Wed, Apr 19, 2006 at 12:52:33PM -0600, David Wilk wrote:
> > > >
> > > > I think an issue was introduced with mprotect (the first patch in
> > > > 2.6.16.6). With 2.6.16.5, tomcat runs fine (in sun-1.5), but in
> > > > 2.6.16.7, the JVM bails out complaining that it couldn't allocate
> > > > enough heap space.
> >
> > Neither expected nor satisfactory. Sorry about that. We were hoping
> > the straightforward shm/mprotect fix would be good enough, but it
> > appears not. JVM is probably doing something we can allow with a
> > more complicated patch, but it _might_ turn out to be doing something
> > we simply cannot allow: I'll hope for the first and work out a patch
> > for that; but won't be ready to post it until tomorrow.
>
> David, would you please try this patch on top of your 2.6.16.7 or later.
> The first hunk undoes the problematic patch, the remainder does it in a
> more permissive way. Aesthetically, not as satisfactory as the previous
> patch; but it's important that we not break userspace, unless security
> absolutely demands. Please let us know how this fares: thanks.
>
> Hugh
>
> --- 2.6.16.9/ipc/shm.c 2006-04-20 11:59:03.000000000 +0100
> +++ linux/ipc/shm.c 2006-04-20 16:57:36.000000000 +0100
> @@ -161,8 +161,6 @@ static int shm_mmap(struct file * file,
> ret = shmem_mmap(file, vma);
> if (ret == 0) {
> vma->vm_ops = &shm_vm_ops;
> - if (!(vma->vm_flags & VM_WRITE))
> - vma->vm_flags &= ~VM_MAYWRITE;
> shm_inc(file->f_dentry->d_inode->i_ino);
> }
>
> @@ -677,6 +675,8 @@ out:
> */
> long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
> {
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma;
> struct shmid_kernel *shp;
> unsigned long addr;
> unsigned long size;
> @@ -684,7 +684,7 @@ long do_shmat(int shmid, char __user *sh
> int err;
> unsigned long flags;
> unsigned long prot;
> - unsigned long o_flags;
> + int maywrite;
> int acc_mode;
> void *user_addr;
>
> @@ -711,11 +711,11 @@ long do_shmat(int shmid, char __user *sh
>
> if (shmflg & SHM_RDONLY) {
> prot = PROT_READ;
> - o_flags = O_RDONLY;
> + maywrite = 0;
> acc_mode = S_IRUGO;
> } else {
> prot = PROT_READ | PROT_WRITE;
> - o_flags = O_RDWR;
> + maywrite = 1;
> acc_mode = S_IRUGO | S_IWUGO;
> }
> if (shmflg & SHM_EXEC) {
> @@ -748,30 +748,43 @@ long do_shmat(int shmid, char __user *sh
> shm_unlock(shp);
> return err;
> }
> -
> +
> + if (!maywrite && !ipcperms_dac(&shp->shm_perm, S_IWUGO))
> + maywrite = 1;
> +
> file = shp->shm_file;
> size = i_size_read(file->f_dentry->d_inode);
> shp->shm_nattch++;
> shm_unlock(shp);
>
> - down_write(&current->mm->mmap_sem);
> + down_write(&mm->mmap_sem);
> if (addr && !(shmflg & SHM_REMAP)) {
> user_addr = ERR_PTR(-EINVAL);
> - if (find_vma_intersection(current->mm, addr, addr + size))
> + if (find_vma_intersection(mm, addr, addr + size))
> goto invalid;
> /*
> * If shm segment goes below stack, make sure there is some
> * space left for the stack to grow (at least 4 pages).
> */
> - if (addr < current->mm->start_stack &&
> - addr > current->mm->start_stack - size - PAGE_SIZE * 5)
> + if (addr < mm->start_stack &&
> + addr > mm->start_stack - size - PAGE_SIZE * 5)
> goto invalid;
> }
> -
> +
> user_addr = (void*) do_mmap (file, addr, size, prot, flags, 0);
>
> + if (!maywrite && !IS_ERR(user_addr)) {
> + /*
> + * Prevent mprotect from giving write permission later on.
> + * We would prefer just to clear VM_MAYWRITE from a readonly
> + * attachment in shm_mmap, but it seems that JVM has got into
> + * the habit of attaching readonly then mprotecting to write.
> + */
> + vma = find_vma(mm, (unsigned long) user_addr);
> + vma->vm_flags &= ~VM_MAYWRITE;
> + }
> invalid:
> - up_write(&current->mm->mmap_sem);
> + up_write(&mm->mmap_sem);
>
> down (&shm_ids.sem);
> if(!(shp = shm_lock(shmid)))
> --- 2.6.16.9/ipc/util.c 2006-03-20 05:53:29.000000000 +0000
> +++ linux/ipc/util.c 2006-04-20 16:57:36.000000000 +0100
> @@ -464,7 +464,7 @@ void ipc_rcu_putref(void *ptr)
> * to ipc resources. return 0 if allowed
> */
>
> -int ipcperms (struct kern_ipc_perm *ipcp, short flag)
> +int ipcperms_dac(struct kern_ipc_perm *ipcp, short flag)
> { /* flag will most probably be 0 or S_...UGO from <linux/stat.h> */
> int requested_mode, granted_mode;
>
> @@ -478,7 +478,13 @@ int ipcperms (struct kern_ipc_perm *ipcp
> if ((requested_mode & ~granted_mode & 0007) &&
> !capable(CAP_IPC_OWNER))
> return -1;
> + return 0;
> +}
>
> +int ipcperms(struct kern_ipc_perm *ipcp, short flag)
> +{
> + if (ipcperms_dac(ipcp, flag))
> + return -1;
> return security_ipc_permission(ipcp, flag);
> }
>
> --- 2.6.16.9/ipc/util.h 2006-03-20 05:53:29.000000000 +0000
> +++ linux/ipc/util.h 2006-04-20 16:57:36.000000000 +0100
> @@ -47,7 +47,8 @@ int ipc_addid(struct ipc_ids* ids, struc
> /* must be called with both locks acquired. */
> struct kern_ipc_perm* ipc_rmid(struct ipc_ids* ids, int id);
>
> -int ipcperms (struct kern_ipc_perm *ipcp, short flg);
> +int ipcperms_dac(struct kern_ipc_perm *ipcp, short flag);
> +int ipcperms(struct kern_ipc_perm *ipcp, short flag);
>
> /* for rare, potentially huge allocations.
> * both function can sleep
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davidwilk at gmail

Apr 21, 2006, 12:08 PM

Post #5 of 16 (3103 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

Ok, on my first test system (lowest amount of ram) a 2.6.16.9 kernel
patched with the patch you provided works fine. I'll throw it on some
other systems and we'll see how it does.

On 4/20/06, Hugh Dickins <hugh [at] veritas> wrote:
> On Wed, 19 Apr 2006, Hugh Dickins wrote:
> > On Wed, 19 Apr 2006, Greg KH wrote:
> > > On Wed, Apr 19, 2006 at 12:52:33PM -0600, David Wilk wrote:
> > > >
> > > > I think an issue was introduced with mprotect (the first patch in
> > > > 2.6.16.6). With 2.6.16.5, tomcat runs fine (in sun-1.5), but in
> > > > 2.6.16.7, the JVM bails out complaining that it couldn't allocate
> > > > enough heap space.
> >
> > Neither expected nor satisfactory. Sorry about that. We were hoping
> > the straightforward shm/mprotect fix would be good enough, but it
> > appears not. JVM is probably doing something we can allow with a
> > more complicated patch, but it _might_ turn out to be doing something
> > we simply cannot allow: I'll hope for the first and work out a patch
> > for that; but won't be ready to post it until tomorrow.
>
> David, would you please try this patch on top of your 2.6.16.7 or later.
> The first hunk undoes the problematic patch, the remainder does it in a
> more permissive way. Aesthetically, not as satisfactory as the previous
> patch; but it's important that we not break userspace, unless security
> absolutely demands. Please let us know how this fares: thanks.
>
> Hugh
>
> --- 2.6.16.9/ipc/shm.c 2006-04-20 11:59:03.000000000 +0100
> +++ linux/ipc/shm.c 2006-04-20 16:57:36.000000000 +0100
> @@ -161,8 +161,6 @@ static int shm_mmap(struct file * file,
> ret = shmem_mmap(file, vma);
> if (ret == 0) {
> vma->vm_ops = &shm_vm_ops;
> - if (!(vma->vm_flags & VM_WRITE))
> - vma->vm_flags &= ~VM_MAYWRITE;
> shm_inc(file->f_dentry->d_inode->i_ino);
> }
>
> @@ -677,6 +675,8 @@ out:
> */
> long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr)
> {
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma;
> struct shmid_kernel *shp;
> unsigned long addr;
> unsigned long size;
> @@ -684,7 +684,7 @@ long do_shmat(int shmid, char __user *sh
> int err;
> unsigned long flags;
> unsigned long prot;
> - unsigned long o_flags;
> + int maywrite;
> int acc_mode;
> void *user_addr;
>
> @@ -711,11 +711,11 @@ long do_shmat(int shmid, char __user *sh
>
> if (shmflg & SHM_RDONLY) {
> prot = PROT_READ;
> - o_flags = O_RDONLY;
> + maywrite = 0;
> acc_mode = S_IRUGO;
> } else {
> prot = PROT_READ | PROT_WRITE;
> - o_flags = O_RDWR;
> + maywrite = 1;
> acc_mode = S_IRUGO | S_IWUGO;
> }
> if (shmflg & SHM_EXEC) {
> @@ -748,30 +748,43 @@ long do_shmat(int shmid, char __user *sh
> shm_unlock(shp);
> return err;
> }
> -
> +
> + if (!maywrite && !ipcperms_dac(&shp->shm_perm, S_IWUGO))
> + maywrite = 1;
> +
> file = shp->shm_file;
> size = i_size_read(file->f_dentry->d_inode);
> shp->shm_nattch++;
> shm_unlock(shp);
>
> - down_write(&current->mm->mmap_sem);
> + down_write(&mm->mmap_sem);
> if (addr && !(shmflg & SHM_REMAP)) {
> user_addr = ERR_PTR(-EINVAL);
> - if (find_vma_intersection(current->mm, addr, addr + size))
> + if (find_vma_intersection(mm, addr, addr + size))
> goto invalid;
> /*
> * If shm segment goes below stack, make sure there is some
> * space left for the stack to grow (at least 4 pages).
> */
> - if (addr < current->mm->start_stack &&
> - addr > current->mm->start_stack - size - PAGE_SIZE * 5)
> + if (addr < mm->start_stack &&
> + addr > mm->start_stack - size - PAGE_SIZE * 5)
> goto invalid;
> }
> -
> +
> user_addr = (void*) do_mmap (file, addr, size, prot, flags, 0);
>
> + if (!maywrite && !IS_ERR(user_addr)) {
> + /*
> + * Prevent mprotect from giving write permission later on.
> + * We would prefer just to clear VM_MAYWRITE from a readonly
> + * attachment in shm_mmap, but it seems that JVM has got into
> + * the habit of attaching readonly then mprotecting to write.
> + */
> + vma = find_vma(mm, (unsigned long) user_addr);
> + vma->vm_flags &= ~VM_MAYWRITE;
> + }
> invalid:
> - up_write(&current->mm->mmap_sem);
> + up_write(&mm->mmap_sem);
>
> down (&shm_ids.sem);
> if(!(shp = shm_lock(shmid)))
> --- 2.6.16.9/ipc/util.c 2006-03-20 05:53:29.000000000 +0000
> +++ linux/ipc/util.c 2006-04-20 16:57:36.000000000 +0100
> @@ -464,7 +464,7 @@ void ipc_rcu_putref(void *ptr)
> * to ipc resources. return 0 if allowed
> */
>
> -int ipcperms (struct kern_ipc_perm *ipcp, short flag)
> +int ipcperms_dac(struct kern_ipc_perm *ipcp, short flag)
> { /* flag will most probably be 0 or S_...UGO from <linux/stat.h> */
> int requested_mode, granted_mode;
>
> @@ -478,7 +478,13 @@ int ipcperms (struct kern_ipc_perm *ipcp
> if ((requested_mode & ~granted_mode & 0007) &&
> !capable(CAP_IPC_OWNER))
> return -1;
> + return 0;
> +}
>
> +int ipcperms(struct kern_ipc_perm *ipcp, short flag)
> +{
> + if (ipcperms_dac(ipcp, flag))
> + return -1;
> return security_ipc_permission(ipcp, flag);
> }
>
> --- 2.6.16.9/ipc/util.h 2006-03-20 05:53:29.000000000 +0000
> +++ linux/ipc/util.h 2006-04-20 16:57:36.000000000 +0100
> @@ -47,7 +47,8 @@ int ipc_addid(struct ipc_ids* ids, struc
> /* must be called with both locks acquired. */
> struct kern_ipc_perm* ipc_rmid(struct ipc_ids* ids, int id);
>
> -int ipcperms (struct kern_ipc_perm *ipcp, short flg);
> +int ipcperms_dac(struct kern_ipc_perm *ipcp, short flag);
> +int ipcperms(struct kern_ipc_perm *ipcp, short flag);
>
> /* for rare, potentially huge allocations.
> * both function can sleep
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


chrisw at sous-sol

Apr 21, 2006, 12:27 PM

Post #6 of 16 (3126 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

* David Wilk (davidwilk [at] gmail) wrote:
> Ok, on my first test system (lowest amount of ram) a 2.6.16.9 kernel
> patched with the patch you provided works fine. I'll throw it on some
> other systems and we'll see how it does.

Was that same (lowest amount of ram) system failing before Hugh's patch
with vanilla 2.6.16.9? What we're looking for is to see if the app
was doing:

1) shmget(0444) [RDONLY], shmat(SHM_RDONLY), mprotect(PROT_WRITE)
or
2) shmget(0666) [RDWR], shmat(SHM_RDONLY), mprotect(PROT_WRITE)

The first is definitely a bug, and that's what the original patch
was closing. The second is technically (as in POSIX) undefined, and
the original patch treated it as a bug as well. Hugh's additional
patch allows this behaviour, as it's vaguely similar to open(RDWR),
mmap(PROT_READ), mprotect(PROT_WRITE), which is legitimate. So we're
trying to determine if that's what your app is doing. strace output
may be unwieldy, but that (or using syscall audit) would be helpful
to clarify.

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davidwilk at gmail

Apr 21, 2006, 1:43 PM

Post #7 of 16 (3116 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

right, sorry, I forgot to try strace. let me see what I can do.

On 4/21/06, Chris Wright <chrisw [at] sous-sol> wrote:
> * David Wilk (davidwilk [at] gmail) wrote:
> > Ok, on my first test system (lowest amount of ram) a 2.6.16.9 kernel
> > patched with the patch you provided works fine. I'll throw it on some
> > other systems and we'll see how it does.
>
> Was that same (lowest amount of ram) system failing before Hugh's patch
> with vanilla 2.6.16.9? What we're looking for is to see if the app
> was doing:
>
> 1) shmget(0444) [RDONLY], shmat(SHM_RDONLY), mprotect(PROT_WRITE)
> or
> 2) shmget(0666) [RDWR], shmat(SHM_RDONLY), mprotect(PROT_WRITE)
>
> The first is definitely a bug, and that's what the original patch
> was closing. The second is technically (as in POSIX) undefined, and
> the original patch treated it as a bug as well. Hugh's additional
> patch allows this behaviour, as it's vaguely similar to open(RDWR),
> mmap(PROT_READ), mprotect(PROT_WRITE), which is legitimate. So we're
> trying to determine if that's what your app is doing. strace output
> may be unwieldy, but that (or using syscall audit) would be helpful
> to clarify.
>
> thanks,
> -chris
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davidwilk at gmail

Apr 21, 2006, 2:56 PM

Post #8 of 16 (3099 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

I finally got strace into the tomcat startup scripts properly and
grabbed the attached output. I don't see any of the two lines you
propose. I hope you guys can find this useful.

On 4/21/06, Chris Wright <chrisw [at] sous-sol> wrote:
> * David Wilk (davidwilk [at] gmail) wrote:
> > Ok, on my first test system (lowest amount of ram) a 2.6.16.9 kernel
> > patched with the patch you provided works fine. I'll throw it on some
> > other systems and we'll see how it does.
>
> Was that same (lowest amount of ram) system failing before Hugh's patch
> with vanilla 2.6.16.9? What we're looking for is to see if the app
> was doing:
>
> 1) shmget(0444) [RDONLY], shmat(SHM_RDONLY), mprotect(PROT_WRITE)
> or
> 2) shmget(0666) [RDWR], shmat(SHM_RDONLY), mprotect(PROT_WRITE)
>
> The first is definitely a bug, and that's what the original patch
> was closing. The second is technically (as in POSIX) undefined, and
> the original patch treated it as a bug as well. Hugh's additional
> patch allows this behaviour, as it's vaguely similar to open(RDWR),
> mmap(PROT_READ), mprotect(PROT_WRITE), which is legitimate. So we're
> trying to determine if that's what your app is doing. strace output
> may be unwieldy, but that (or using syscall audit) would be helpful
> to clarify.
>
> thanks,
> -chris
>
Attachments: tomcat5_strace.txt (32.3 KB)


hugh at veritas

Apr 23, 2006, 5:41 AM

Post #9 of 16 (3114 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

On Fri, 21 Apr 2006, David Wilk wrote:
> I finally got strace into the tomcat startup scripts properly and
> grabbed the attached output. I don't see any of the two lines you
> propose. I hope you guys can find this useful.

Thanks for getting that, David. As you observe, it doesn't involve
shm at all, and the only mprotect is PROT_NONE. Do the abbreviated
messages in the final lines of the trace fit with the errors you
were originally reporting? (I think so.) Or is this particular
trace failing for some other reason, earlier than before, and we
need to try something else to identify the problem?

> mmap2(NULL, 872415232, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> write(1, "Error occurred during initializa"..., 43) = 43
> write(1, "Could not reserve enough space f"..., 46) = 46
> write(1, "\n", 1) = 1
> unlink("/tmp/hsperfdata_tomcat/12273") = 0
> write(2, "Could not create the Java virtua"..., 43) = 43

To judge by this trace, I'd have to say that your problem has
nothing whatever to do with the shm/mprotect fix in 2.6.16.6,
and we've no evidence yet to complicate that fix. Interestingly,
nobody else has so far reported any problem with it.

Judging by the mmap addresses throughout the trace (top down, from
0x37f2e000), it looks like you've got CONFIG_VMSPLIT_1G (not a good
choice for a box with only 1G of RAM: whereas CONFIG_VMSPLIT_3G_OPT
would maximize your userspace while avoiding the need for HIGHMEM);
and with the above 832M mmap, the remaining hole in user address
space is just too small to hold it.

But that leaves me quite unable to explain why you should have
thought the shm/mprotect patch responsible, and why you should
find the more complicated version works. Stack randomization
changes the numbers a little, but I think not enough to explain
how it sometimes could fit 832M in there, sometimes not.

Tell me I'm talking nonsense and we'll have another go:
I guess adding some printks on top of the "replacement"
patch, so it can tell us when it's having an effect.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davidwilk at gmail

Apr 24, 2006, 1:59 PM

Post #10 of 16 (3112 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

On 4/23/06, Hugh Dickins <hugh [at] veritas> wrote:
> On Fri, 21 Apr 2006, David Wilk wrote:
> > I finally got strace into the tomcat startup scripts properly and
> > grabbed the attached output. I don't see any of the two lines you
> > propose. I hope you guys can find this useful.
>
> Thanks for getting that, David. As you observe, it doesn't involve
> shm at all, and the only mprotect is PROT_NONE. Do the abbreviated
> messages in the final lines of the trace fit with the errors you
> were originally reporting? (I think so.) Or is this particular
> trace failing for some other reason, earlier than before, and we
> need to try something else to identify the problem?

I think this trace was taken while java was doing exactly what it was
doing before. I actually restarted java many, many times with
2.6.16.9 and watched in amazement as it failed each and every time,
with the exact same error message. This is tomcat, specifically, and
it would die immediately after startup and it was started the exact
same way with the init script. So, yeah, I think this trace is
representative. I have no idea why it doesn't contain what you would
consider relevant. I'm no programmer, unfortunately. However, I
would like to help out any way that I can.
>
> > mmap2(NULL, 872415232, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> > write(1, "Error occurred during initializa"..., 43) = 43
> > write(1, "Could not reserve enough space f"..., 46) = 46
> > write(1, "\n", 1) = 1
> > unlink("/tmp/hsperfdata_tomcat/12273") = 0
> > write(2, "Could not create the Java virtua"..., 43) = 43
>
> To judge by this trace, I'd have to say that your problem has
> nothing whatever to do with the shm/mprotect fix in 2.6.16.6,
> and we've no evidence yet to complicate that fix. Interestingly,
> nobody else has so far reported any problem with it.

bizaar. I must say that this patch 'fixing' the problem just cannot
be coincidental. Tomcat will never start without it, and never fails
with it.
>
> Judging by the mmap addresses throughout the trace (top down, from
> 0x37f2e000), it looks like you've got CONFIG_VMSPLIT_1G (not a good
> choice for a box with only 1G of RAM: whereas CONFIG_VMSPLIT_3G_OPT
> would maximize your userspace while avoiding the need for HIGHMEM);
> and with the above 832M mmap, the remaining hole in user address
> space is just too small to hold it.

well, this is just a test box for a system we deploy on a dual-cpu
server with 4GB of ram.

can you describe the CONFIG_VMSPLIT_3G_OPT and how I might find it in
'make menuconfig'? is it the second option (3G/1G user/kernel)? I"ve
got the first option selected which is 3G/1G user/kernel as well, but
different somehow. As this is new to 2.6.16, I'm not familiar with
the options. Perhaps my 1GB workstations would benefit from this
second 3G/1G option?
>
> But that leaves me quite unable to explain why you should have
> thought the shm/mprotect patch responsible, and why you should
> find the more complicated version works. Stack randomization
> changes the numbers a little, but I think not enough to explain
> how it sometimes could fit 832M in there, sometimes not.

Unfortunately I cannot speculate as to the cause, but experimentally
(anecdotally anyway) the patch is 100% effective.
>
> Tell me I'm talking nonsense and we'll have another go:
> I guess adding some printks on top of the "replacement"
> patch, so it can tell us when it's having an effect.

I'd never accuse you of nonsense, but I cannot refute the evidence. ; )

if there is anything else you would like me todo to try to squeeze
more data from this thing, please let me know.
>
> Hugh
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hugh at veritas

Apr 25, 2006, 10:51 AM

Post #11 of 16 (3115 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

On Mon, 24 Apr 2006, David Wilk wrote:
> On 4/23/06, Hugh Dickins <hugh [at] veritas> wrote:
>
> I think this trace was taken while java was doing exactly what it was
> doing before. I actually restarted java many, many times with
> 2.6.16.9 and watched in amazement as it failed each and every time,
> with the exact same error message. This is tomcat, specifically, and
> it would die immediately after startup and it was started the exact
> same way with the init script. So, yeah, I think this trace is
> representative. I have no idea why it doesn't contain what you would
> consider relevant. I'm no programmer, unfortunately. However, I
> would like to help out any way that I can.

Thanks for the clarification. But I remain utterly perplexed.

I've installed JRE and JDK 1.5 in 1GB box here, I've installed
Tomcat 5.0.28, I've inserted the options from your strace (notably
the -Xmx768m) in my catalina.sh, yet I see no such problem with 2.6.16.9.

> > > mmap2(NULL, 872415232, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> > > write(1, "Error occurred during initializa"..., 43) = 43
> > > write(1, "Could not reserve enough space f"..., 46) = 46
> > > write(1, "\n", 1) = 1
> > > unlink("/tmp/hsperfdata_tomcat/12273") = 0
> > > write(2, "Could not create the Java virtua"..., 43) = 43
> >
> > To judge by this trace, I'd have to say that your problem has
> > nothing whatever to do with the shm/mprotect fix in 2.6.16.6,
> > and we've no evidence yet to complicate that fix. Interestingly,
> > nobody else has so far reported any problem with it.
>
> bizaar. I must say that this patch 'fixing' the problem just cannot
> be coincidental. Tomcat will never start without it, and never fails
> with it.

Bizarre indeed. But at least you've rechecked and banished my doubts.

> > Judging by the mmap addresses throughout the trace (top down, from
> > 0x37f2e000), it looks like you've got CONFIG_VMSPLIT_1G (not a good
> > choice for a box with only 1G of RAM: whereas CONFIG_VMSPLIT_3G_OPT
> > would maximize your userspace while avoiding the need for HIGHMEM);
> > and with the above 832M mmap, the remaining hole in user address
> > space is just too small to hold it.
>
> well, this is just a test box for a system we deploy on a dual-cpu
> server with 4GB of ram.
>
> can you describe the CONFIG_VMSPLIT_3G_OPT and how I might find it in
> 'make menuconfig'? is it the second option (3G/1G user/kernel)? I"ve

The second one, that's _OPT, yes, which just shaves a little off the
3GB userspace, to avoid the need for HIGHMEM.

> got the first option selected which is 3G/1G user/kernel as well, but
> different somehow. As this is new to 2.6.16, I'm not familiar with

The first one, this is the traditional layout, the one least likely to
give you any compatibility troubles, so please do stick with it for now.

> the options. Perhaps my 1GB workstations would benefit from this
> second 3G/1G option?

They would, a little. Whether it's noticeable, I don't know.
You might prefer to keep a similar configuration for all your
machines. While we're investigating this particular mystery,
I'd prefer you to stick with what you've got.

> > But that leaves me quite unable to explain why you should have
> > thought the shm/mprotect patch responsible, and why you should
> > find the more complicated version works. Stack randomization
> > changes the numbers a little, but I think not enough to explain
> > how it sometimes could fit 832M in there, sometimes not.

Clearly I was entirely wrong to accuse you of the wrong VMSPLIT.
Yet I still can't see how either shm or mprotect write is involved.

My latest guess is that whereas my "ulimit -s" shows 8192, yours
will show something much higher, but not "unlimited". And that
high stack rlimit is pushing the roof of your userspace down, to
the point where the -Xmx868m mapping barely fits.

But though fiddling with my "ulimit -s" does change the layout,
I've not yet been able to reproduce your failure. And this has
nothing whatever to do with the shm/mprotect issue or patch.

> Unfortunately I cannot speculate as to the cause, but experimentally
> (anecdotally anyway) the patch is 100% effective.
> >
> > Tell me I'm talking nonsense and we'll have another go:
> > I guess adding some printks on top of the "replacement"
> > patch, so it can tell us when it's having an effect.
>
> I'd never accuse you of nonsense, but I cannot refute the evidence. ; )
>
> if there is anything else you would like me todo to try to squeeze
> more data from this thing, please let me know.

Well, I guess I'd like to see what "ulimit -a" and "ulimit -H -a"
show on your machine (it's really "ulimit -s" I'm interested in,
but we might as well see the whole lot). And the output from
"cat /proc/$(pidof java)/maps" while you've got Tomcat running
successfully. And what is your distro?

But it seems unlikely that any of this information will help me to
make that strange leap from my patches to your experience of them.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davidwilk at gmail

Apr 25, 2006, 11:08 AM

Post #12 of 16 (3100 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

Ok, I think I need to apologize to everyone here. I have found the
problem, and it is not with your patch, Hugh. For some reason, the
config for my 2.6.16.7 source tree had a 1G/3G user/kernel split
configured. This is very bizaar as I copy my .config from tree to
tree to avoid any changes in the configuration of my test kernels.

I imagine this is the expected behavior when you only have 1G
configured for user space? right. I will be sure to include my
/proc/config.gz in the future to prevent this from happening again.

I've tested 2.6.16.7 and 2.6.16.9 and neither of them have the mmap constraint.

again, my apologies. I thank you for your patience and your hardwork
on the kernel.

thanks,
Dave

On 4/24/06, David Wilk <davidwilk [at] gmail> wrote:
> On 4/23/06, Hugh Dickins <hugh [at] veritas> wrote:
> > On Fri, 21 Apr 2006, David Wilk wrote:
> > > I finally got strace into the tomcat startup scripts properly and
> > > grabbed the attached output. I don't see any of the two lines you
> > > propose. I hope you guys can find this useful.
> >
> > Thanks for getting that, David. As you observe, it doesn't involve
> > shm at all, and the only mprotect is PROT_NONE. Do the abbreviated
> > messages in the final lines of the trace fit with the errors you
> > were originally reporting? (I think so.) Or is this particular
> > trace failing for some other reason, earlier than before, and we
> > need to try something else to identify the problem?
>
> I think this trace was taken while java was doing exactly what it was
> doing before. I actually restarted java many, many times with
> 2.6.16.9 and watched in amazement as it failed each and every time,
> with the exact same error message. This is tomcat, specifically, and
> it would die immediately after startup and it was started the exact
> same way with the init script. So, yeah, I think this trace is
> representative. I have no idea why it doesn't contain what you would
> consider relevant. I'm no programmer, unfortunately. However, I
> would like to help out any way that I can.
> >
> > > mmap2(NULL, 872415232, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> > > write(1, "Error occurred during initializa"..., 43) = 43
> > > write(1, "Could not reserve enough space f"..., 46) = 46
> > > write(1, "\n", 1) = 1
> > > unlink("/tmp/hsperfdata_tomcat/12273") = 0
> > > write(2, "Could not create the Java virtua"..., 43) = 43
> >
> > To judge by this trace, I'd have to say that your problem has
> > nothing whatever to do with the shm/mprotect fix in 2.6.16.6,
> > and we've no evidence yet to complicate that fix. Interestingly,
> > nobody else has so far reported any problem with it.
>
> bizaar. I must say that this patch 'fixing' the problem just cannot
> be coincidental. Tomcat will never start without it, and never fails
> with it.
> >
> > Judging by the mmap addresses throughout the trace (top down, from
> > 0x37f2e000), it looks like you've got CONFIG_VMSPLIT_1G (not a good
> > choice for a box with only 1G of RAM: whereas CONFIG_VMSPLIT_3G_OPT
> > would maximize your userspace while avoiding the need for HIGHMEM);
> > and with the above 832M mmap, the remaining hole in user address
> > space is just too small to hold it.
>
> well, this is just a test box for a system we deploy on a dual-cpu
> server with 4GB of ram.
>
> can you describe the CONFIG_VMSPLIT_3G_OPT and how I might find it in
> 'make menuconfig'? is it the second option (3G/1G user/kernel)? I"ve
> got the first option selected which is 3G/1G user/kernel as well, but
> different somehow. As this is new to 2.6.16, I'm not familiar with
> the options. Perhaps my 1GB workstations would benefit from this
> second 3G/1G option?
> >
> > But that leaves me quite unable to explain why you should have
> > thought the shm/mprotect patch responsible, and why you should
> > find the more complicated version works. Stack randomization
> > changes the numbers a little, but I think not enough to explain
> > how it sometimes could fit 832M in there, sometimes not.
>
> Unfortunately I cannot speculate as to the cause, but experimentally
> (anecdotally anyway) the patch is 100% effective.
> >
> > Tell me I'm talking nonsense and we'll have another go:
> > I guess adding some printks on top of the "replacement"
> > patch, so it can tell us when it's having an effect.
>
> I'd never accuse you of nonsense, but I cannot refute the evidence. ; )
>
> if there is anything else you would like me todo to try to squeeze
> more data from this thing, please let me know.
> >
> > Hugh
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hugh at veritas

Apr 25, 2006, 11:28 AM

Post #13 of 16 (3106 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

On Tue, 25 Apr 2006, David Wilk wrote:
> Ok, I think I need to apologize to everyone here. I have found the
> problem, and it is not with your patch, Hugh. For some reason, the
> config for my 2.6.16.7 source tree had a 1G/3G user/kernel split
> configured.

Right, that's just the kind of explanation I came up with yesterday.
Phew, I'll relax! And thanks for the confession, David - absolved.

It remains the case that my patch imposes a new constraint that
could give rise to problems somewhere: but it closes the hole,
and there have been no other reports of problems so far.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ak at suse

Apr 25, 2006, 10:12 PM

Post #14 of 16 (3112 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

"David Wilk" <davidwilk [at] gmail> writes:

> Ok, I think I need to apologize to everyone here. I have found the
> problem, and it is not with your patch, Hugh. For some reason, the
> config for my 2.6.16.7 source tree had a 1G/3G user/kernel split
> configured. This is very bizaar as I copy my .config from tree to
> tree to avoid any changes in the configuration of my test kernels.

This just shows this dreaded VMSPLIT config was a bad idea in the first
place. There was a reason we didn't have it for such a long time (too
many users get it wrong) and such occurrences just show again that this
is still true.

IMHO it would be best to just remove that option again and require
users who really want to change this to patch their kernels again.

At the very least it should be probably made dependent on CONFIG_EMBEDDED.

-Andi

Mark VMSPLIT EMBEDDED

Too many users get it wrong.

Signed-off-by: Andi Kleen <ak [at] suse>

Index: linux/arch/i386/Kconfig
===================================================================
--- linux.orig/arch/i386/Kconfig
+++ linux/arch/i386/Kconfig
@@ -466,7 +466,7 @@ endchoice

choice
depends on EXPERIMENTAL && !X86_PAE
- prompt "Memory split"
+ prompt "Memory split" if EMBEDDED
default VMSPLIT_3G
help
Select the desired split between kernel and user memory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Apr 26, 2006, 1:03 AM

Post #15 of 16 (3107 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

On Wed, Apr 26, 2006 at 07:12:43AM +0200, Andi Kleen wrote:
> "David Wilk" <davidwilk [at] gmail> writes:
>
> > Ok, I think I need to apologize to everyone here. I have found the
> > problem, and it is not with your patch, Hugh. For some reason, the
> > config for my 2.6.16.7 source tree had a 1G/3G user/kernel split
> > configured. This is very bizaar as I copy my .config from tree to
> > tree to avoid any changes in the configuration of my test kernels.
>
> This just shows this dreaded VMSPLIT config was a bad idea in the first
> place. There was a reason we didn't have it for such a long time (too
> many users get it wrong) and such occurrences just show again that this
> is still true.
>
> IMHO it would be best to just remove that option again and require
> users who really want to change this to patch their kernels again.
>
> At the very least it should be probably made dependent on CONFIG_EMBEDDED.

NAK, EMBEDDED has a different semantics (space savings in memory limited
situations) that does not apply to this option.

> -Andi
>...

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


davidwilk at gmail

Apr 26, 2006, 2:40 PM

Post #16 of 16 (3112 views)
Permalink
Re: [stable] 2.6.16.6 breaks java... sort of [In reply to]

In defense of having that option available, this was not a case where
the user was deliberately trying to set that option, but rather that
it somehow got set accidentally (still a bit of a mystery as I was not
modifying configs at the time).

On 26 Apr 2006 07:12:43 +0200, Andi Kleen <ak [at] suse> wrote:
> "David Wilk" <davidwilk [at] gmail> writes:
>
> > Ok, I think I need to apologize to everyone here. I have found the
> > problem, and it is not with your patch, Hugh. For some reason, the
> > config for my 2.6.16.7 source tree had a 1G/3G user/kernel split
> > configured. This is very bizaar as I copy my .config from tree to
> > tree to avoid any changes in the configuration of my test kernels.
>
> This just shows this dreaded VMSPLIT config was a bad idea in the first
> place. There was a reason we didn't have it for such a long time (too
> many users get it wrong) and such occurrences just show again that this
> is still true.
>
> IMHO it would be best to just remove that option again and require
> users who really want to change this to patch their kernels again.
>
> At the very least it should be probably made dependent on CONFIG_EMBEDDED.
>
> -Andi
>
> Mark VMSPLIT EMBEDDED
>
> Too many users get it wrong.
>
> Signed-off-by: Andi Kleen <ak [at] suse>
>
> Index: linux/arch/i386/Kconfig
> ===================================================================
> --- linux.orig/arch/i386/Kconfig
> +++ linux/arch/i386/Kconfig
> @@ -466,7 +466,7 @@ endchoice
>
> choice
> depends on EXPERIMENTAL && !X86_PAE
> - prompt "Memory split"
> + prompt "Memory split" if EMBEDDED
> default VMSPLIT_3G
> help
> Select the desired split between kernel and user memory.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.