751992 – mount.nfs4: Cannot allocate memory

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 751992 - mount.nfs4: Cannot allocate memory

Summary: mount.nfs4: Cannot allocate memory

Keywords:
Status:	CLOSED DUPLICATE of bug 730045
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	kernel
Sub Component:
Version:	6.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	nfs-maint
QA Contact:	Filesystem QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	767187
TreeView+	depends on / blocked

Reported:	2011-11-08 09:20 UTC by Jan Stancek
Modified:	2012-03-15 15:42 UTC (History)
CC List:	14 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2012-03-15 13:48:00 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Jan Stancek 2011-11-08 09:20:39 UTC

Description of problem:
While running KT1 tests, connectathon test failed to do mount:
mount.nfs4: Cannot allocate memory

Same mount before and after succeeded. It doesn't appear that OOM has been invoked.

mount.nfs4: page allocation failure. order:4, mode:0xd0
CPU: 1 Tainted: G           ---------------- T 2.6.32-218.el6.s390x #1
Process mount.nfs4 (pid: 31853, task: 000000001d2ea990, ksp: 000000000199f390)
000000000199f6e8 000000000199f668 0000000000000002 0000000000000000 
       000000000199f708 000000000199f680 000000000199f680 00000000004cbb50 
       000000001fe45fb6 0000000000000000 00000000000000d0 0000000000000000 
       000000000000000d 000000000000000c 000000000199f6d8 0000000000000000 
       0000000000000000 00000000001051bc 000000000199f668 000000000199f6a8 
Call Trace:
([<00000000001050bc>] show_trace+0xe8/0x138)
 [<00000000002066ce>] __alloc_pages_nodemask+0x80a/0xa40
 [<0000000000243b56>] cache_alloc_refill+0x3e2/0x6d8
 [<00000000002443ca>] kmem_cache_alloc_notrace+0xa6/0xf8
 [<000003c002ca7f86>] nfs_idmap_new+0x52/0x184 [nfs]
 [<000003c002c6984c>] nfs4_init_client+0x9c/0x238 [nfs]
 [<000003c002c6a1d0>] nfs_get_client+0x634/0x798 [nfs]
 [<000003c002c6a3ce>] nfs4_set_client+0x9a/0x134 [nfs]
 [<000003c002c6abde>] nfs4_create_server+0xe6/0x378 [nfs]
 [<000003c002c77fc0>] nfs4_remote_get_sb+0xa4/0x2b8 [nfs]
 [<0000000000258444>] vfs_kern_mount+0x74/0x1bc
 [<000003c002c783fa>] nfs_do_root_mount+0x8a/0xc0 [nfs]
 [<000003c002c78a64>] nfs4_try_mount+0x70/0xec [nfs]
 [<000003c002c78de8>] nfs4_get_sb+0x308/0x3b0 [nfs]
 [<0000000000258444>] vfs_kern_mount+0x74/0x1bc
 [<00000000002585f4>] do_kern_mount+0x54/0x128
 [<0000000000278038>] do_mount+0x2fc/0x96c
 [<000000000027874c>] SyS_mount+0xa4/0xf0
 [<000000000011863c>] sysc_tracego+0xe/0x14
 [<000003fffcf8e442>] 0x3fffcf8e442
Mem-Info:
DMA per-cpu:
CPU    0: hi:  186, btch:  31 usd: 156
CPU    1: hi:  186, btch:  31 usd:   0
active_anon:9665 inactive_anon:15099 isolated_anon:0
 active_file:19398 inactive_file:50552 isolated_file:0
 unevictable:913 dirty:4780 writeback:0 unstable:0
 free:4051 slab_reclaimable:9445 slab_unreclaimable:9702
 mapped:8599 shmem:36 pagetables:335 bounce:0
DMA free:16204kB min:2876kB low:3592kB high:4312kB active_anon:38660kB inactive_anon:60396kB active_file:77592kB inactive_file:202208kB unevictable:3652kB isolated(anon):0kB isolated(file):0kB present:517120kB mlocked:0kB dirty:19120kB writeback:0kB mapped:34396kB shmem:144kB slab_reclaimable:37780kB slab_unreclaimable:38808kB kernel_stack:2688kB pagetables:1340kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 363*4kB 226*8kB 607*16kB 101*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB = 16204kB
71009 total pagecache pages
71 pages in swap cache
Swap cache stats: add 1047, delete 976, find 155/190
Free swap  = 1013240kB
Total swap = 1015800kB
131072 pages RAM
5212 pages reserved
87845 pages shared
71223 pages non-shared
device eth0 left promiscuous mode


Version-Release number of selected component (if applicable):
2.6.32-218.el6.s390x

How reproducible:
rarely

Steps to Reproduce:
1. running connectathon test on s390x

Actual results:
failed mount

Expected results:
mount works every time

Additional info:

Comment 3 J. Bruce Fields 2011-11-09 15:56:54 UTC

Looks like struct idmap is about 40k on a 64-bit architecture.

I wonder whether it would be possible to make the transition to the new idmapper on rhel6?  That would solve a number of problems.

Comment 4 Steve Dickson 2011-11-11 17:23:39 UTC

(In reply to comment #3)
> Looks like struct idmap is about 40k on a 64-bit architecture.
> 
> I wonder whether it would be possible to make the transition to the new
> idmapper on rhel6?  That would solve a number of problems.
I agree... lets how enabling the new idmapper in upstream 
and rawhide pans out... If well, we should consider enabling
the code in 6.3... imho...

Comment 6 Ray Van Dolson 2012-03-09 18:36:45 UTC

I believe this is impacting me as well although the triggering process is mount.nfs rather than mount.nfs4.

Have opened SR #612178 for the issue with Red Hat Support.

Are there any workarounds for this issue currently?

Comment 7 yanfu,wang 2012-03-15 07:16:11 UTC

If the bug is duplicate with bug 730045?

Comment 8 Steve Dickson 2012-03-15 13:48:00 UTC

(In reply to comment #7)
> If the bug is duplicate with bug 730045?
Yeah...

*** This bug has been marked as a duplicate of bug 730045 ***

Comment 9 Ray Van Dolson 2012-03-15 15:42:19 UTC

Any chance of making bug 730045 public?

Note You need to log in before you can comment on or make changes to this bug.