* TMPFS over NFSv4 @ 2010-05-21 13:47 Tharindu Rukshan Bamunuarachchi 2010-05-21 20:55 ` Hugh Dickins 0 siblings, 1 reply; 12+ messages in thread From: Tharindu Rukshan Bamunuarachchi @ 2010-05-21 13:47 UTC (permalink / raw) To: linux-mm; +Cc: hugh.dickins dear All, I tried to export tmpfs file system over NFS and got followin oops .... this kernel is provided with SLES 11 and tainted due to OFED installation. I am using NFSv4. Please help me to find the root cause if you feel free .... BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 IP: __vm_enough_memory+0xf9/0x14e PGD 0 Oops: 0000 [1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:09.0/0000:24:00.0/infiniband/mlx4_1/node_desc CPU 0 Modules linked in: md5 mmfs26(X) mmfslinux(X) tracedev(X) nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs bonding binfmt_misc microcode rdma_ucm(N) ib_sdp(N) rdma_cm(N) iw_cm(N) ib_addr(N) ib_ipoib(N) ib_cm(N) ib_sa(N) ipv6 ib_uverbs(N) ib_umad(N) mlx4_en(N) mlx4_ib(N) ib_mthca(N) ib_mad(N) ib_core(N) fuse ext2 xfs loop dm_mod cdc_ether usbnet i2c_i801 rtc_cmos shpchp button joydev mlx4_core(N) rtc_core pcspkr pci_hotplug sr_mod rtc_lib mii bnx2 i2c_core cdrom sg usbhid hid ff_memless uhci_hcd ehci_hcd sd_mod crc_t10dif usbcore edd ext3 mbcache jbd fan thermal processor thermal_sys hwmon ide_pci_generic ide_core ata_generic ata_piix libata dock megaraid_sas scsi_mod [last unloaded: tracedev] Supported: No, Unsupported modules are loaded Pid: 8855, comm: nfsd Tainted: G 2.6.27.45-0.1-default #1 RIP: 0010: __vm_enough_memory+0xf9/0x14e RSP: 0018:ffff8803642cd780 EFLAGS: 00010202 RAX: 00000000002f151c RBX: 0000000012643f22 RCX: 0000000000400293 RDX: 0000000000000032 RSI: 0000000000000001 RDI: 00000000002f151c RBP: 0000000000000001 R08: 00000000ffffffe5 R09: 0000000000000000 R10: ffffffff806eb5c8 R11: ffffffff80317108 R12: 0000000000000001 R13: 0000000000000000 R14: 0000000000001000 R15: ffff88037b93b738 FS: 0000000000000000(0000) GS:ffffffff80a43080(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000000000000b0 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process nfsd (pid: 8855, threadinfo ffff8803642cc000, task ffff88036f140380) Stack: ffff88037b93b668 ffff88037009de40 ffff88037b93b668 0000000000000000 ffff88037b93b601 ffffffff802a8573 ffffffff80a33680 ffffffff80a30730 0000000000000000 0000000300000002 ffff8803642cd930 0000000000000000 Call Trace: shmem_getpage+0x4d8/0x764 generic_perform_write+0xae/0x1b5 generic_file_buffered_write+0x80/0x130 __generic_file_aio_write_nolock+0x349/0x37d generic_file_aio_write+0x64/0xc4 do_sync_readv_writev+0xc0/0x107 do_readv_writev+0xb2/0x18b nfsd_vfs_write+0x10a/0x328 [nfsd] nfsd_write+0x79/0xe2 [nfsd] nfsd4_write+0xd9/0x10d [nfsd] nfsd4_proc_compound+0x1bd/0x2c7 [nfsd] nfsd_dispatch+0xdd/0x1b9 [nfsd] svc_process+0x3d8/0x700 [sunrpc] nfsd+0x1b1/0x27e [nfsd] kthread+0x47/0x73 child_rip+0xa/0x11 Code: 00 48 29 c3 48 63 05 49 1a 45 00 48 0f af d8 48 89 d8 48 f7 f1 45 85 e4 48 89 c7 75 07 48 c1 e8 05 48 29 c7 48 8b 0d b9 2f 86 00 <49> 8b b5 b0 00 00 00 48 8b 15 43 2f 86 00 b8 01 00 00 00 48 85 RIP __vm_enough_memory+0xf9/0x14e RSP <ffff8803642cd780> CR2: 00000000000000b0 ---[ end trace ca3d7c15970cb4b6 ]--- __ tharindu.info "those that can, do. Those that can’t, complain." -- Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-21 13:47 TMPFS over NFSv4 Tharindu Rukshan Bamunuarachchi @ 2010-05-21 20:55 ` Hugh Dickins 2010-05-24 9:26 ` Tharindu Rukshan Bamunuarachchi 0 siblings, 1 reply; 12+ messages in thread From: Hugh Dickins @ 2010-05-21 20:55 UTC (permalink / raw) To: Tharindu Rukshan Bamunuarachchi; +Cc: linux-mm, linux-nfs, Alan Cox On Fri, 21 May 2010, Tharindu Rukshan Bamunuarachchi wrote: > > I tried to export tmpfs file system over NFS and got followin oops .... > this kernel is provided with SLES 11 and tainted due to OFED installation. > > I am using NFSv4. Please help me to find the root cause if you feel free .... > > > BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 > IP: __vm_enough_memory+0xf9/0x14e > PGD 0 > Oops: 0000 [1] SMP > last sysfs file: > /sys/devices/pci0000:00/0000:00:09.0/0000:24:00.0/infiniband/mlx4_1/node_desc > CPU 0 > Modules linked in: blah blah blah > Supported: No, Unsupported modules are loaded > Pid: 8855, comm: nfsd Tainted: G 2.6.27.45-0.1-default #1 > RIP: 0010: __vm_enough_memory+0xf9/0x14e ... > Process nfsd (pid: 8855, threadinfo ffff8803642cc000, task ffff88036f140380) > Stack: ffff88037b93b668 ffff88037009de40 ffff88037b93b668 0000000000000000 > ffff88037b93b601 ffffffff802a8573 ffffffff80a33680 ffffffff80a30730 > 0000000000000000 0000000300000002 ffff8803642cd930 0000000000000000 > Call Trace: > shmem_getpage+0x4d8/0x764 > generic_perform_write+0xae/0x1b5 > generic_file_buffered_write+0x80/0x130 > __generic_file_aio_write_nolock+0x349/0x37d > generic_file_aio_write+0x64/0xc4 > do_sync_readv_writev+0xc0/0x107 > do_readv_writev+0xb2/0x18b > nfsd_vfs_write+0x10a/0x328 [nfsd] > nfsd_write+0x79/0xe2 [nfsd] > nfsd4_write+0xd9/0x10d [nfsd] > nfsd4_proc_compound+0x1bd/0x2c7 [nfsd] > nfsd_dispatch+0xdd/0x1b9 [nfsd] > svc_process+0x3d8/0x700 [sunrpc] > nfsd+0x1b1/0x27e [nfsd] > kthread+0x47/0x73 > child_rip+0xa/0x11 I believe that was fixed in 2.6.28 by the patch below: please would you try it, and if it works for you, then I'll ask for it to be included in the next 2.6.27-stable, which I expect SLES 11 will include in an update later. Strange that more people haven't suffered from it... Hugh commit 731572d39fcd3498702eda4600db4c43d51e0b26 Author: Alan Cox <alan@redhat.com> Date: Wed Oct 29 14:01:20 2008 -0700 nfsd: fix vm overcommit crash Junjiro R. Okajima reported a problem where knfsd crashes if you are using it to export shmemfs objects and run strict overcommit. In this situation the current->mm based modifier to the overcommit goes through a NULL pointer. We could simply check for NULL and skip the modifier but we've caught other real bugs in the past from mm being NULL here - cases where we did need a valid mm set up (eg the exec bug about a year ago). To preserve the checks and get the logic we want shuffle the checking around and add a new helper to the vm_ security wrappers Also fix a current->mm reference in nommu that should use the passed mm [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix build] Reported-by: Junjiro R. Okajima <hooanon05@yahoo.co.jp> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> diff --git a/include/linux/security.h b/include/linux/security.h index f5c4a51..c13f1ce 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -1585,6 +1585,7 @@ int security_syslog(int type); int security_settime(struct timespec *ts, struct timezone *tz); int security_vm_enough_memory(long pages); int security_vm_enough_memory_mm(struct mm_struct *mm, long pages); +int security_vm_enough_memory_kern(long pages); int security_bprm_alloc(struct linux_binprm *bprm); void security_bprm_free(struct linux_binprm *bprm); void security_bprm_apply_creds(struct linux_binprm *bprm, int unsafe); @@ -1820,6 +1821,11 @@ static inline int security_vm_enough_memory(long pages) return cap_vm_enough_memory(current->mm, pages); } +static inline int security_vm_enough_memory_kern(long pages) +{ + return cap_vm_enough_memory(current->mm, pages); +} + static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) { return cap_vm_enough_memory(mm, pages); diff --git a/mm/mmap.c b/mm/mmap.c index 74f4d15..de14ac2 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -175,7 +175,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) /* Don't let a single process grow too big: leave 3% of the size of this process for other processes */ - allowed -= mm->total_vm / 32; + if (mm) + allowed -= mm->total_vm / 32; /* * cast `allowed' as a signed long because vm_committed_space diff --git a/mm/nommu.c b/mm/nommu.c index 2696b24..7695dc8 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -1454,7 +1454,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) /* Don't let a single process grow too big: leave 3% of the size of this process for other processes */ - allowed -= current->mm->total_vm / 32; + if (mm) + allowed -= mm->total_vm / 32; /* * cast `allowed' as a signed long because vm_committed_space diff --git a/mm/shmem.c b/mm/shmem.c index d38d7e6..0ed0752 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -161,8 +161,8 @@ static inline struct shmem_sb_info *SHMEM_SB(struct super_block *sb) */ static inline int shmem_acct_size(unsigned long flags, loff_t size) { - return (flags & VM_ACCOUNT)? - security_vm_enough_memory(VM_ACCT(size)): 0; + return (flags & VM_ACCOUNT) ? + security_vm_enough_memory_kern(VM_ACCT(size)) : 0; } static inline void shmem_unacct_size(unsigned long flags, loff_t size) @@ -179,8 +179,8 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size) */ static inline int shmem_acct_block(unsigned long flags) { - return (flags & VM_ACCOUNT)? - 0: security_vm_enough_memory(VM_ACCT(PAGE_CACHE_SIZE)); + return (flags & VM_ACCOUNT) ? + 0 : security_vm_enough_memory_kern(VM_ACCT(PAGE_CACHE_SIZE)); } static inline void shmem_unacct_blocks(unsigned long flags, long pages) diff --git a/security/security.c b/security/security.c index 255b085..c0acfa7 100644 --- a/security/security.c +++ b/security/security.c @@ -198,14 +198,23 @@ int security_settime(struct timespec *ts, struct timezone *tz) int security_vm_enough_memory(long pages) { + WARN_ON(current->mm == NULL); return security_ops->vm_enough_memory(current->mm, pages); } int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) { + WARN_ON(mm == NULL); return security_ops->vm_enough_memory(mm, pages); } +int security_vm_enough_memory_kern(long pages) +{ + /* If current->mm is a kernel thread then we will pass NULL, + for this specific case that is fine */ + return security_ops->vm_enough_memory(current->mm, pages); +} + int security_bprm_alloc(struct linux_binprm *bprm) { return security_ops->bprm_alloc_security(bprm); -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-21 20:55 ` Hugh Dickins @ 2010-05-24 9:26 ` Tharindu Rukshan Bamunuarachchi 2010-05-24 9:57 ` Hugh Dickins 2010-05-24 10:02 ` Alan Cox 0 siblings, 2 replies; 12+ messages in thread From: Tharindu Rukshan Bamunuarachchi @ 2010-05-24 9:26 UTC (permalink / raw) To: Hugh Dickins; +Cc: linux-mm, linux-nfs, Alan Cox thankx a lot Hugh ... I will try this out ... (bit harder patch already patched SLES kernel :-p ) .... BTW, what does Alan means by "strict overcommit" ? e.g. i did not see this issues with "0 > /proc/sys/vm/overcommit_accounting" But this happened several times with "2 > /proc/sys/vm/overcommit_accounting" any clue ? we are suffering everyday ..... :-| __ tharindu.info "those that can, do. Those that can’t, complain." -- Linus On Fri, May 21, 2010 at 9:55 PM, Hugh Dickins <hughd@google.com> wrote: > On Fri, 21 May 2010, Tharindu Rukshan Bamunuarachchi wrote: >> >> I tried to export tmpfs file system over NFS and got followin oops .... >> this kernel is provided with SLES 11 and tainted due to OFED installation. >> >> I am using NFSv4. Please help me to find the root cause if you feel free .... >> >> >> BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 >> IP: __vm_enough_memory+0xf9/0x14e >> PGD 0 >> Oops: 0000 [1] SMP >> last sysfs file: >> /sys/devices/pci0000:00/0000:00:09.0/0000:24:00.0/infiniband/mlx4_1/node_desc >> CPU 0 >> Modules linked in: blah blah blah >> Supported: No, Unsupported modules are loaded >> Pid: 8855, comm: nfsd Tainted: G 2.6.27.45-0.1-default #1 >> RIP: 0010: __vm_enough_memory+0xf9/0x14e > ... >> Process nfsd (pid: 8855, threadinfo ffff8803642cc000, task ffff88036f140380) >> Stack: ffff88037b93b668 ffff88037009de40 ffff88037b93b668 0000000000000000 >> ffff88037b93b601 ffffffff802a8573 ffffffff80a33680 ffffffff80a30730 >> 0000000000000000 0000000300000002 ffff8803642cd930 0000000000000000 >> Call Trace: >> shmem_getpage+0x4d8/0x764 >> generic_perform_write+0xae/0x1b5 >> generic_file_buffered_write+0x80/0x130 >> __generic_file_aio_write_nolock+0x349/0x37d >> generic_file_aio_write+0x64/0xc4 >> do_sync_readv_writev+0xc0/0x107 >> do_readv_writev+0xb2/0x18b >> nfsd_vfs_write+0x10a/0x328 [nfsd] >> nfsd_write+0x79/0xe2 [nfsd] >> nfsd4_write+0xd9/0x10d [nfsd] >> nfsd4_proc_compound+0x1bd/0x2c7 [nfsd] >> nfsd_dispatch+0xdd/0x1b9 [nfsd] >> svc_process+0x3d8/0x700 [sunrpc] >> nfsd+0x1b1/0x27e [nfsd] >> kthread+0x47/0x73 >> child_rip+0xa/0x11 > > I believe that was fixed in 2.6.28 by the patch below: > please would you try it, and if it works for you, then > I'll ask for it to be included in the next 2.6.27-stable, > which I expect SLES 11 will include in an update later. > Strange that more people haven't suffered from it... > > Hugh > > commit 731572d39fcd3498702eda4600db4c43d51e0b26 > Author: Alan Cox <alan@redhat.com> > Date: Wed Oct 29 14:01:20 2008 -0700 > > nfsd: fix vm overcommit crash > > Junjiro R. Okajima reported a problem where knfsd crashes if you are > using it to export shmemfs objects and run strict overcommit. In this > situation the current->mm based modifier to the overcommit goes through a > NULL pointer. > > We could simply check for NULL and skip the modifier but we've caught > other real bugs in the past from mm being NULL here - cases where we did > need a valid mm set up (eg the exec bug about a year ago). > > To preserve the checks and get the logic we want shuffle the checking > around and add a new helper to the vm_ security wrappers > > Also fix a current->mm reference in nommu that should use the passed mm > > [akpm@linux-foundation.org: coding-style fixes] > [akpm@linux-foundation.org: fix build] > Reported-by: Junjiro R. Okajima <hooanon05@yahoo.co.jp> > Acked-by: James Morris <jmorris@namei.org> > Signed-off-by: Alan Cox <alan@redhat.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > diff --git a/include/linux/security.h b/include/linux/security.h > index f5c4a51..c13f1ce 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -1585,6 +1585,7 @@ int security_syslog(int type); > int security_settime(struct timespec *ts, struct timezone *tz); > int security_vm_enough_memory(long pages); > int security_vm_enough_memory_mm(struct mm_struct *mm, long pages); > +int security_vm_enough_memory_kern(long pages); > int security_bprm_alloc(struct linux_binprm *bprm); > void security_bprm_free(struct linux_binprm *bprm); > void security_bprm_apply_creds(struct linux_binprm *bprm, int unsafe); > @@ -1820,6 +1821,11 @@ static inline int security_vm_enough_memory(long pages) > return cap_vm_enough_memory(current->mm, pages); > } > > +static inline int security_vm_enough_memory_kern(long pages) > +{ > + return cap_vm_enough_memory(current->mm, pages); > +} > + > static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) > { > return cap_vm_enough_memory(mm, pages); > diff --git a/mm/mmap.c b/mm/mmap.c > index 74f4d15..de14ac2 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -175,7 +175,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) > > /* Don't let a single process grow too big: > leave 3% of the size of this process for other processes */ > - allowed -= mm->total_vm / 32; > + if (mm) > + allowed -= mm->total_vm / 32; > > /* > * cast `allowed' as a signed long because vm_committed_space > diff --git a/mm/nommu.c b/mm/nommu.c > index 2696b24..7695dc8 100644 > --- a/mm/nommu.c > +++ b/mm/nommu.c > @@ -1454,7 +1454,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) > > /* Don't let a single process grow too big: > leave 3% of the size of this process for other processes */ > - allowed -= current->mm->total_vm / 32; > + if (mm) > + allowed -= mm->total_vm / 32; > > /* > * cast `allowed' as a signed long because vm_committed_space > diff --git a/mm/shmem.c b/mm/shmem.c > index d38d7e6..0ed0752 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -161,8 +161,8 @@ static inline struct shmem_sb_info *SHMEM_SB(struct super_block *sb) > */ > static inline int shmem_acct_size(unsigned long flags, loff_t size) > { > - return (flags & VM_ACCOUNT)? > - security_vm_enough_memory(VM_ACCT(size)): 0; > + return (flags & VM_ACCOUNT) ? > + security_vm_enough_memory_kern(VM_ACCT(size)) : 0; > } > > static inline void shmem_unacct_size(unsigned long flags, loff_t size) > @@ -179,8 +179,8 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size) > */ > static inline int shmem_acct_block(unsigned long flags) > { > - return (flags & VM_ACCOUNT)? > - 0: security_vm_enough_memory(VM_ACCT(PAGE_CACHE_SIZE)); > + return (flags & VM_ACCOUNT) ? > + 0 : security_vm_enough_memory_kern(VM_ACCT(PAGE_CACHE_SIZE)); > } > > static inline void shmem_unacct_blocks(unsigned long flags, long pages) > diff --git a/security/security.c b/security/security.c > index 255b085..c0acfa7 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -198,14 +198,23 @@ int security_settime(struct timespec *ts, struct timezone *tz) > > int security_vm_enough_memory(long pages) > { > + WARN_ON(current->mm == NULL); > return security_ops->vm_enough_memory(current->mm, pages); > } > > int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) > { > + WARN_ON(mm == NULL); > return security_ops->vm_enough_memory(mm, pages); > } > > +int security_vm_enough_memory_kern(long pages) > +{ > + /* If current->mm is a kernel thread then we will pass NULL, > + for this specific case that is fine */ > + return security_ops->vm_enough_memory(current->mm, pages); > +} > + > int security_bprm_alloc(struct linux_binprm *bprm) > { > return security_ops->bprm_alloc_security(bprm); > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 9:26 ` Tharindu Rukshan Bamunuarachchi @ 2010-05-24 9:57 ` Hugh Dickins 2010-05-24 10:09 ` Alan Cox 2010-05-24 14:16 ` Tharindu Rukshan Bamunuarachchi 2010-05-24 10:02 ` Alan Cox 1 sibling, 2 replies; 12+ messages in thread From: Hugh Dickins @ 2010-05-24 9:57 UTC (permalink / raw) To: Tharindu Rukshan Bamunuarachchi; +Cc: linux-mm, linux-nfs, Alan Cox On Mon, May 24, 2010 at 2:26 AM, Tharindu Rukshan Bamunuarachchi <btharindu@gmail.com> wrote: > thankx a lot Hugh ... I will try this out ... (bit harder patch > already patched SLES kernel :-p ) .... If patch conflicts are a problem, you really only need to put in the two-liner patch to mm/mmap.c: Alan was seeking perfection in the rest of the patch, but you can get away without it. > > BTW, what does Alan means by "strict overcommit" ? Ah, that phrase, yes, it's a nonsense, but many of us do say it by mistake. Alan meant to say "strict no-overcommit". > > e.g. > i did not see this issues with "0 > /proc/sys/vm/overcommit_accounting" I assume "overcommit_accounting" is either a typo for "overcommit_memory", or SLES gives "overcommit_memory" a slightly different name. 0 means overcommit memory (let people allocate more private writable user memory than there is actually ram+swap to back), but throw in a check against really wild allocation requests. 1 omits even that check. > But this happened several times with "2 > /proc/sys/vm/overcommit_accounting" 2 means account for all private writable memory and fail any allocation which would take the system over the edge - the edge being defined roughly by overcommit_ratio * (ram+swap) (I expect there's a divisor needed in there!) i.e. 2 means strict no-overcommit. So what you see fits with what Alan was fixing. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 9:57 ` Hugh Dickins @ 2010-05-24 10:09 ` Alan Cox 2010-05-24 23:46 ` Hugh Dickins 2010-05-24 14:16 ` Tharindu Rukshan Bamunuarachchi 1 sibling, 1 reply; 12+ messages in thread From: Alan Cox @ 2010-05-24 10:09 UTC (permalink / raw) To: Hugh Dickins; +Cc: Tharindu Rukshan Bamunuarachchi, linux-mm, linux-nfs On Mon, 24 May 2010 02:57:30 -0700 Hugh Dickins <hughd@google.com> wrote: > On Mon, May 24, 2010 at 2:26 AM, Tharindu Rukshan Bamunuarachchi > <btharindu@gmail.com> wrote: > > thankx a lot Hugh ... I will try this out ... (bit harder patch > > already patched SLES kernel :-p ) .... > > If patch conflicts are a problem, you really only need to put in the > two-liner patch to mm/mmap.c: Alan was seeking perfection in > the rest of the patch, but you can get away without it. > > > > > BTW, what does Alan means by "strict overcommit" ? > > Ah, that phrase, yes, it's a nonsense, but many of us do say it by mistake. > Alan meant to say "strict no-overcommit". No I always meant to say 'strict overcommit'. It avoids excess negatives and "no noovercommit" discussions. I guess 'strict overcommit control' would have been clearer 8) Alan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 10:09 ` Alan Cox @ 2010-05-24 23:46 ` Hugh Dickins 2010-05-25 9:00 ` Tharindu Rukshan Bamunuarachchi 2010-05-25 17:00 ` Greg KH 0 siblings, 2 replies; 12+ messages in thread From: Hugh Dickins @ 2010-05-24 23:46 UTC (permalink / raw) To: Greg KH Cc: Alan Cox, Tharindu Rukshan Bamunuarachchi, linux-mm, linux-nfs, linux-kernel, stable Hi Greg, On Mon, 24 May 2010, Alan Cox wrote: > On Mon, 24 May 2010 02:57:30 -0700 > Hugh Dickins <hughd@google.com> wrote: > > On Mon, May 24, 2010 at 2:26 AM, Tharindu Rukshan Bamunuarachchi > > <btharindu@gmail.com> wrote: > > > thankx a lot Hugh ... I will try this out ... (bit harder patch > > > already patched SLES kernel :-p ) .... > > > > If patch conflicts are a problem, you really only need to put in the > > two-liner patch to mm/mmap.c: Alan was seeking perfection in > > the rest of the patch, but you can get away without it. > > > > > > > > BTW, what does Alan means by "strict overcommit" ? > > > > Ah, that phrase, yes, it's a nonsense, but many of us do say it by mistake. > > Alan meant to say "strict no-overcommit". > > No I always meant to say 'strict overcommit'. It avoids excess negatives > and "no noovercommit" discussions. > > I guess 'strict overcommit control' would have been clearer 8) > > Alan I see we've just missed 2.6.27.47-rc1, but if there's to be an -rc2, please include Alan's 2.6.28 oops fix below: which Tharindu appears to be needing - just now discussed on linux-mm and linux-nfs. Failing that, please queue it up for 2.6.27.48. Or if you'd prefer a smaller patch for -stable, then just the mm/mmap.c part of it should suffice: I think it's fair to say that the rest of the patch was more precautionary - as Alan describes, for catching other bugs, so good for an ongoing development tree, but not necessarily in -stable. (However, Alan may disagree - I've already misrepresented him once here!) Thanks, Hugh commit 731572d39fcd3498702eda4600db4c43d51e0b26 Author: Alan Cox <alan@redhat.com> Date: Wed Oct 29 14:01:20 2008 -0700 nfsd: fix vm overcommit crash Junjiro R. Okajima reported a problem where knfsd crashes if you are using it to export shmemfs objects and run strict overcommit. In this situation the current->mm based modifier to the overcommit goes through a NULL pointer. We could simply check for NULL and skip the modifier but we've caught other real bugs in the past from mm being NULL here - cases where we did need a valid mm set up (eg the exec bug about a year ago). To preserve the checks and get the logic we want shuffle the checking around and add a new helper to the vm_ security wrappers Also fix a current->mm reference in nommu that should use the passed mm [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix build] Reported-by: Junjiro R. Okajima <hooanon05@yahoo.co.jp> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> diff --git a/include/linux/security.h b/include/linux/security.h index f5c4a51..c13f1ce 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -1585,6 +1585,7 @@ int security_syslog(int type); int security_settime(struct timespec *ts, struct timezone *tz); int security_vm_enough_memory(long pages); int security_vm_enough_memory_mm(struct mm_struct *mm, long pages); +int security_vm_enough_memory_kern(long pages); int security_bprm_alloc(struct linux_binprm *bprm); void security_bprm_free(struct linux_binprm *bprm); void security_bprm_apply_creds(struct linux_binprm *bprm, int unsafe); @@ -1820,6 +1821,11 @@ static inline int security_vm_enough_memory(long pages) return cap_vm_enough_memory(current->mm, pages); } +static inline int security_vm_enough_memory_kern(long pages) +{ + return cap_vm_enough_memory(current->mm, pages); +} + static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) { return cap_vm_enough_memory(mm, pages); diff --git a/mm/mmap.c b/mm/mmap.c index 74f4d15..de14ac2 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -175,7 +175,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) /* Don't let a single process grow too big: leave 3% of the size of this process for other processes */ - allowed -= mm->total_vm / 32; + if (mm) + allowed -= mm->total_vm / 32; /* * cast `allowed' as a signed long because vm_committed_space diff --git a/mm/nommu.c b/mm/nommu.c index 2696b24..7695dc8 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -1454,7 +1454,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) /* Don't let a single process grow too big: leave 3% of the size of this process for other processes */ - allowed -= current->mm->total_vm / 32; + if (mm) + allowed -= mm->total_vm / 32; /* * cast `allowed' as a signed long because vm_committed_space diff --git a/mm/shmem.c b/mm/shmem.c index d38d7e6..0ed0752 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -161,8 +161,8 @@ static inline struct shmem_sb_info *SHMEM_SB(struct super_block *sb) */ static inline int shmem_acct_size(unsigned long flags, loff_t size) { - return (flags & VM_ACCOUNT)? - security_vm_enough_memory(VM_ACCT(size)): 0; + return (flags & VM_ACCOUNT) ? + security_vm_enough_memory_kern(VM_ACCT(size)) : 0; } static inline void shmem_unacct_size(unsigned long flags, loff_t size) @@ -179,8 +179,8 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size) */ static inline int shmem_acct_block(unsigned long flags) { - return (flags & VM_ACCOUNT)? - 0: security_vm_enough_memory(VM_ACCT(PAGE_CACHE_SIZE)); + return (flags & VM_ACCOUNT) ? + 0 : security_vm_enough_memory_kern(VM_ACCT(PAGE_CACHE_SIZE)); } static inline void shmem_unacct_blocks(unsigned long flags, long pages) diff --git a/security/security.c b/security/security.c index 255b085..c0acfa7 100644 --- a/security/security.c +++ b/security/security.c @@ -198,14 +198,23 @@ int security_settime(struct timespec *ts, struct timezone *tz) int security_vm_enough_memory(long pages) { + WARN_ON(current->mm == NULL); return security_ops->vm_enough_memory(current->mm, pages); } int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) { + WARN_ON(mm == NULL); return security_ops->vm_enough_memory(mm, pages); } +int security_vm_enough_memory_kern(long pages) +{ + /* If current->mm is a kernel thread then we will pass NULL, + for this specific case that is fine */ + return security_ops->vm_enough_memory(current->mm, pages); +} + int security_bprm_alloc(struct linux_binprm *bprm) { return security_ops->bprm_alloc_security(bprm); -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 23:46 ` Hugh Dickins @ 2010-05-25 9:00 ` Tharindu Rukshan Bamunuarachchi 2010-05-25 16:58 ` Greg KH 2010-05-25 17:00 ` Greg KH 1 sibling, 1 reply; 12+ messages in thread From: Tharindu Rukshan Bamunuarachchi @ 2010-05-25 9:00 UTC (permalink / raw) To: Hugh Dickins; +Cc: Greg KH, Alan Cox, linux-mm, linux-nfs, linux-kernel, stable hope that the 2.6.27.48 or later will be shipped with SP1 :-) __ tharindu.info "those that can, do. Those that can’t, complain." -- Linus On Tue, May 25, 2010 at 12:46 AM, Hugh Dickins <hughd@google.com> wrote: > Hi Greg, > > On Mon, 24 May 2010, Alan Cox wrote: >> On Mon, 24 May 2010 02:57:30 -0700 >> Hugh Dickins <hughd@google.com> wrote: >> > On Mon, May 24, 2010 at 2:26 AM, Tharindu Rukshan Bamunuarachchi >> > <btharindu@gmail.com> wrote: >> > > thankx a lot Hugh ... I will try this out ... (bit harder patch >> > > already patched SLES kernel :-p ) .... >> > >> > If patch conflicts are a problem, you really only need to put in the >> > two-liner patch to mm/mmap.c: Alan was seeking perfection in >> > the rest of the patch, but you can get away without it. >> > >> > > >> > > BTW, what does Alan means by "strict overcommit" ? >> > >> > Ah, that phrase, yes, it's a nonsense, but many of us do say it by mistake. >> > Alan meant to say "strict no-overcommit". >> >> No I always meant to say 'strict overcommit'. It avoids excess negatives >> and "no noovercommit" discussions. >> >> I guess 'strict overcommit control' would have been clearer 8) >> >> Alan > > I see we've just missed 2.6.27.47-rc1, but if there's to be an -rc2, > please include Alan's 2.6.28 oops fix below: which Tharindu appears > to be needing - just now discussed on linux-mm and linux-nfs. > Failing that, please queue it up for 2.6.27.48. > > Or if you'd prefer a smaller patch for -stable, then just the mm/mmap.c > part of it should suffice: I think it's fair to say that the rest of the > patch was more precautionary - as Alan describes, for catching other bugs, > so good for an ongoing development tree, but not necessarily in -stable. > (However, Alan may disagree - I've already misrepresented him once here!) > > Thanks, > Hugh > > commit 731572d39fcd3498702eda4600db4c43d51e0b26 > Author: Alan Cox <alan@redhat.com> > Date: Wed Oct 29 14:01:20 2008 -0700 > > nfsd: fix vm overcommit crash > > Junjiro R. Okajima reported a problem where knfsd crashes if you are > using it to export shmemfs objects and run strict overcommit. In this > situation the current->mm based modifier to the overcommit goes through a > NULL pointer. > > We could simply check for NULL and skip the modifier but we've caught > other real bugs in the past from mm being NULL here - cases where we did > need a valid mm set up (eg the exec bug about a year ago). > > To preserve the checks and get the logic we want shuffle the checking > around and add a new helper to the vm_ security wrappers > > Also fix a current->mm reference in nommu that should use the passed mm > > [akpm@linux-foundation.org: coding-style fixes] > [akpm@linux-foundation.org: fix build] > Reported-by: Junjiro R. Okajima <hooanon05@yahoo.co.jp> > Acked-by: James Morris <jmorris@namei.org> > Signed-off-by: Alan Cox <alan@redhat.com> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > diff --git a/include/linux/security.h b/include/linux/security.h > index f5c4a51..c13f1ce 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -1585,6 +1585,7 @@ int security_syslog(int type); > int security_settime(struct timespec *ts, struct timezone *tz); > int security_vm_enough_memory(long pages); > int security_vm_enough_memory_mm(struct mm_struct *mm, long pages); > +int security_vm_enough_memory_kern(long pages); > int security_bprm_alloc(struct linux_binprm *bprm); > void security_bprm_free(struct linux_binprm *bprm); > void security_bprm_apply_creds(struct linux_binprm *bprm, int unsafe); > @@ -1820,6 +1821,11 @@ static inline int security_vm_enough_memory(long pages) > return cap_vm_enough_memory(current->mm, pages); > } > > +static inline int security_vm_enough_memory_kern(long pages) > +{ > + return cap_vm_enough_memory(current->mm, pages); > +} > + > static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) > { > return cap_vm_enough_memory(mm, pages); > diff --git a/mm/mmap.c b/mm/mmap.c > index 74f4d15..de14ac2 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -175,7 +175,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) > > /* Don't let a single process grow too big: > leave 3% of the size of this process for other processes */ > - allowed -= mm->total_vm / 32; > + if (mm) > + allowed -= mm->total_vm / 32; > > /* > * cast `allowed' as a signed long because vm_committed_space > diff --git a/mm/nommu.c b/mm/nommu.c > index 2696b24..7695dc8 100644 > --- a/mm/nommu.c > +++ b/mm/nommu.c > @@ -1454,7 +1454,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) > > /* Don't let a single process grow too big: > leave 3% of the size of this process for other processes */ > - allowed -= current->mm->total_vm / 32; > + if (mm) > + allowed -= mm->total_vm / 32; > > /* > * cast `allowed' as a signed long because vm_committed_space > diff --git a/mm/shmem.c b/mm/shmem.c > index d38d7e6..0ed0752 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -161,8 +161,8 @@ static inline struct shmem_sb_info *SHMEM_SB(struct super_block *sb) > */ > static inline int shmem_acct_size(unsigned long flags, loff_t size) > { > - return (flags & VM_ACCOUNT)? > - security_vm_enough_memory(VM_ACCT(size)): 0; > + return (flags & VM_ACCOUNT) ? > + security_vm_enough_memory_kern(VM_ACCT(size)) : 0; > } > > static inline void shmem_unacct_size(unsigned long flags, loff_t size) > @@ -179,8 +179,8 @@ static inline void shmem_unacct_size(unsigned long flags, loff_t size) > */ > static inline int shmem_acct_block(unsigned long flags) > { > - return (flags & VM_ACCOUNT)? > - 0: security_vm_enough_memory(VM_ACCT(PAGE_CACHE_SIZE)); > + return (flags & VM_ACCOUNT) ? > + 0 : security_vm_enough_memory_kern(VM_ACCT(PAGE_CACHE_SIZE)); > } > > static inline void shmem_unacct_blocks(unsigned long flags, long pages) > diff --git a/security/security.c b/security/security.c > index 255b085..c0acfa7 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -198,14 +198,23 @@ int security_settime(struct timespec *ts, struct timezone *tz) > > int security_vm_enough_memory(long pages) > { > + WARN_ON(current->mm == NULL); > return security_ops->vm_enough_memory(current->mm, pages); > } > > int security_vm_enough_memory_mm(struct mm_struct *mm, long pages) > { > + WARN_ON(mm == NULL); > return security_ops->vm_enough_memory(mm, pages); > } > > +int security_vm_enough_memory_kern(long pages) > +{ > + /* If current->mm is a kernel thread then we will pass NULL, > + for this specific case that is fine */ > + return security_ops->vm_enough_memory(current->mm, pages); > +} > + > int security_bprm_alloc(struct linux_binprm *bprm) > { > return security_ops->bprm_alloc_security(bprm); > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-25 9:00 ` Tharindu Rukshan Bamunuarachchi @ 2010-05-25 16:58 ` Greg KH 0 siblings, 0 replies; 12+ messages in thread From: Greg KH @ 2010-05-25 16:58 UTC (permalink / raw) To: Tharindu Rukshan Bamunuarachchi Cc: Hugh Dickins, Alan Cox, linux-mm, linux-nfs, linux-kernel, stable On Tue, May 25, 2010 at 10:00:29AM +0100, Tharindu Rukshan Bamunuarachchi wrote: > hope that the 2.6.27.48 or later will be shipped with SP1 :-) What do you mean "SP1"? confused, greg k-h -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 23:46 ` Hugh Dickins 2010-05-25 9:00 ` Tharindu Rukshan Bamunuarachchi @ 2010-05-25 17:00 ` Greg KH 1 sibling, 0 replies; 12+ messages in thread From: Greg KH @ 2010-05-25 17:00 UTC (permalink / raw) To: Hugh Dickins Cc: Alan Cox, Tharindu Rukshan Bamunuarachchi, linux-mm, linux-nfs, linux-kernel, stable On Mon, May 24, 2010 at 04:46:24PM -0700, Hugh Dickins wrote: > Hi Greg, > > On Mon, 24 May 2010, Alan Cox wrote: > > On Mon, 24 May 2010 02:57:30 -0700 > > Hugh Dickins <hughd@google.com> wrote: > > > On Mon, May 24, 2010 at 2:26 AM, Tharindu Rukshan Bamunuarachchi > > > <btharindu@gmail.com> wrote: > > > > thankx a lot Hugh ... I will try this out ... (bit harder patch > > > > already patched SLES kernel :-p ) .... > > > > > > If patch conflicts are a problem, you really only need to put in the > > > two-liner patch to mm/mmap.c: Alan was seeking perfection in > > > the rest of the patch, but you can get away without it. > > > > > > > > > > > BTW, what does Alan means by "strict overcommit" ? > > > > > > Ah, that phrase, yes, it's a nonsense, but many of us do say it by mistake. > > > Alan meant to say "strict no-overcommit". > > > > No I always meant to say 'strict overcommit'. It avoids excess negatives > > and "no noovercommit" discussions. > > > > I guess 'strict overcommit control' would have been clearer 8) > > > > Alan > > I see we've just missed 2.6.27.47-rc1, but if there's to be an -rc2, > please include Alan's 2.6.28 oops fix below: which Tharindu appears > to be needing - just now discussed on linux-mm and linux-nfs. > Failing that, please queue it up for 2.6.27.48. There is now going to be a -rc2 due to other problems, so I'll go queue this one up as well. > Or if you'd prefer a smaller patch for -stable, then just the mm/mmap.c > part of it should suffice: I think it's fair to say that the rest of the > patch was more precautionary - as Alan describes, for catching other bugs, > so good for an ongoing development tree, but not necessarily in -stable. > (However, Alan may disagree - I've already misrepresented him once here!) The original is best, it makes more sense. thanks, greg k-h -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 9:57 ` Hugh Dickins 2010-05-24 10:09 ` Alan Cox @ 2010-05-24 14:16 ` Tharindu Rukshan Bamunuarachchi 1 sibling, 0 replies; 12+ messages in thread From: Tharindu Rukshan Bamunuarachchi @ 2010-05-24 14:16 UTC (permalink / raw) To: Hugh Dickins; +Cc: linux-mm, linux-nfs, Alan Cox hi Hugh. On Mon, May 24, 2010 at 10:57 AM, Hugh Dickins <hughd@google.com> wrote: > On Mon, May 24, 2010 at 2:26 AM, Tharindu Rukshan Bamunuarachchi > > If patch conflicts are a problem, you really only need to put in the > two-liner patch to mm/mmap.c: Alan was seeking perfection in > the rest of the patch, but you can get away without it. > I will just add it by hand. > > > So what you see fits with what Alan was fixing. > Yes, of courese. BTW, that was typo and it should be overcommit_memory. I have done testing in our test severs and "2 > overcommit_memory" triggers the issue. OTOH, I have reported the issue Novell. Hope they will apply necessary patch in next release. > Hugh > Thankx a lot/ __ tharindu -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 9:26 ` Tharindu Rukshan Bamunuarachchi 2010-05-24 9:57 ` Hugh Dickins @ 2010-05-24 10:02 ` Alan Cox 2010-05-24 11:36 ` Tharindu Rukshan Bamunuarachchi 1 sibling, 1 reply; 12+ messages in thread From: Alan Cox @ 2010-05-24 10:02 UTC (permalink / raw) To: Tharindu Rukshan Bamunuarachchi; +Cc: Hugh Dickins, linux-mm, linux-nfs On Mon, 24 May 2010 10:26:39 +0100 Tharindu Rukshan Bamunuarachchi <btharindu@gmail.com> wrote: > thankx a lot Hugh ... I will try this out ... (bit harder patch > already patched SLES kernel :-p ) .... > > BTW, what does Alan means by "strict overcommit" ? Strict overcommit works like banks should. It tries to ensure that at any point it has sufficient swap and memory to fulfill any possible use of allocated address space. So in strict overcommit mode you should almost never see an OOM kill (there are perverse cases as always), but you will need a lot more swap that may well never be used. In the normal mode the kernel works like the US banking system and makes speculative guesses that all the resources it hands out will never be needed at once. That has the corresponding risk that one day it might at which point you get a meltdown (or in the kernel case OOM kills) Alan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: TMPFS over NFSv4 2010-05-24 10:02 ` Alan Cox @ 2010-05-24 11:36 ` Tharindu Rukshan Bamunuarachchi 0 siblings, 0 replies; 12+ messages in thread From: Tharindu Rukshan Bamunuarachchi @ 2010-05-24 11:36 UTC (permalink / raw) To: Alan Cox; +Cc: Hugh Dickins, linux-mm, linux-nfs Got it cleared. BTW, nice example ... US Banking System :-) __ tharindu.info "those that can, do. Those that can’t, complain." -- Linus On Mon, May 24, 2010 at 11:02 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Mon, 24 May 2010 10:26:39 +0100 > Tharindu Rukshan Bamunuarachchi <btharindu@gmail.com> wrote: > >> thankx a lot Hugh ... I will try this out ... (bit harder patch >> already patched SLES kernel :-p ) .... >> >> BTW, what does Alan means by "strict overcommit" ? > > Strict overcommit works like banks should. It tries to ensure that at any > point it has sufficient swap and memory to fulfill any possible use of > allocated address space. So in strict overcommit mode you should almost > never see an OOM kill (there are perverse cases as always), but you will > need a lot more swap that may well never be used. > > In the normal mode the kernel works like the US banking system and makes > speculative guesses that all the resources it hands out will never be > needed at once. That has the corresponding risk that one day it might at > which point you get a meltdown (or in the kernel case OOM kills) > > Alan > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-05-25 17:03 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-05-21 13:47 TMPFS over NFSv4 Tharindu Rukshan Bamunuarachchi 2010-05-21 20:55 ` Hugh Dickins 2010-05-24 9:26 ` Tharindu Rukshan Bamunuarachchi 2010-05-24 9:57 ` Hugh Dickins 2010-05-24 10:09 ` Alan Cox 2010-05-24 23:46 ` Hugh Dickins 2010-05-25 9:00 ` Tharindu Rukshan Bamunuarachchi 2010-05-25 16:58 ` Greg KH 2010-05-25 17:00 ` Greg KH 2010-05-24 14:16 ` Tharindu Rukshan Bamunuarachchi 2010-05-24 10:02 ` Alan Cox 2010-05-24 11:36 ` Tharindu Rukshan Bamunuarachchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).