* Occasional memory fault in inode_has_perm() while running xfstest 234 @ 2011-11-10 21:36 Chandra Seetharaman 2011-11-14 10:27 ` Christoph Hellwig 0 siblings, 1 reply; 5+ messages in thread From: Chandra Seetharaman @ 2011-11-10 21:36 UTC (permalink / raw) To: XFS Mailing List Hi All, While debugging the xfstest case 234, I was occasionally hitting the following memory fault. Has anybody seen it ? ----------------- IP: [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 PGD 0 Oops: 0000 [#1] SMP CPU 0 Modules linked in: xfs exportfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun kvm_intel kvm cdc_ether usbnet mii microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core ses enclosure sg igb dca ext4 mbcache jbd2 sd_mod crc_t10dif ahci libahci megaraid_sas [last unloaded: scsi_wait_scan] Pid: 32611, comm: setquota Not tainted 3.1.0-rc9.virgin+ #6 IBM System x3630 M3 -[7377AC1]-/69Y1101 RIP: 0010:[<ffffffff811e57ff>] [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 RSP: 0018:ffff880642bcdb78 EFLAGS: 00010246 RAX: 0000000000800002 RBX: ffff88064f2205f8 RCX: 0000000000800000 RDX: 0000000000800000 RSI: 0000000000000000 RDI: ffff880649e58480 RBP: ffff880642bcdb78 R08: ffff880642bcdb88 R09: 0000000000000080 R10: ffff880658ffff00 R11: ffff880642bcdb88 R12: 0000000000000081 R13: ffff88064f2205f8 R14: ffff8806592b8100 R15: 0000000000000000 FS: 00007f56dfa3a700(0000) GS:ffff88067f200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000020 CR3: 0000000642b30000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process setquota (pid: 32611, threadinfo ffff880642bcc000, task ffff8806592b8100) Stack: ffff880642bcdc18 ffffffff811e5d79 0000000000000009 0000000000000000 ffff88064f2205f8 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Call Trace: [<ffffffff811e5d79>] selinux_inode_permission+0xa9/0x100 [<ffffffff811e323c>] security_inode_permission+0x1c/0x30 [<ffffffff81162509>] inode_permission+0x49/0x100 [<ffffffff81164b57>] link_path_walk+0x87/0x810 [<ffffffff810fedfa>] ? unlock_page+0x2a/0x40 [<ffffffff81165955>] path_lookupat+0x55/0x690 [<ffffffff81125867>] ? handle_pte_fault+0xf7/0xb50 [<ffffffff81165fc1>] do_path_lookup+0x31/0xc0 [<ffffffff81162168>] ? getname_flags+0x1f8/0x280 [<ffffffff81166df9>] user_path_at+0x59/0xa0 [<ffffffff8112641b>] ? handle_mm_fault+0x15b/0x270 [<ffffffff814af8c0>] ? do_page_fault+0x1e0/0x460 [<ffffffff81146a62>] ? kmem_cache_alloc+0x152/0x190 [<ffffffff8115b9c7>] vfs_fstatat+0x47/0x80 [<ffffffff81077571>] ? do_sigaction+0x91/0x1d0 [<ffffffff8115badb>] vfs_stat+0x1b/0x20 [<ffffffff8115bb04>] sys_newstat+0x24/0x50 [<ffffffff810c3c4f>] ? audit_syscall_entry+0x1bf/0x1f0 [<ffffffff814b29c2>] system_call_fastpath+0x16/0x1b Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 f6 46 0d 02 75 23 48 8b 76 38 48 8b 7f 68 45 89 c1 49 89 c8 89 d1 <0f> b7 46 20 8b 7f 04 8b 76 1c 89 c2 e8 a0 f9 ff ff c9 c3 31 c0 RIP [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 RSP <ffff880642bcdb78> CR2: 0000000000000020 ---[ end trace 5d054c892d311b3f ]--- ---------------------------- I made some code changes and found that inode->i_security is the data structure that is NULL. I added the following code ------------------ diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 266a229..43870ec 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1466,6 +1466,7 @@ static int task_has_system(struct task_struct *tsk, SECCLASS_SYSTEM, perms, NULL); } +u64 isec_yes; /* Check whether a task has a particular permission to an inode. The 'adp' parameter is optional and allows other audit data to be passed (e.g. the dentry). */ @@ -1486,6 +1487,13 @@ static int inode_has_perm(const struct cred *cred, sid = cred_sid(cred); isec = inode->i_security; + if (isec) + isec_yes++; + else { + printk("isec NULL; isec_yes %llu\n", isec_yes); + return -EACCES; + } + return avc_has_perm_flags(sid, isec->sid, isec->sclass, perms, adp, flags); } -------------------------------- and this is what I see in /var/log/messages ----------------------------- isec NULL; isec_yes 14345860 isec NULL; isec_yes 102846678 isec NULL; isec_yes 107203361 isec NULL; isec_yes 136859591 isec NULL; isec_yes 140941549 isec NULL; isec_yes 168163633 isec NULL; isec_yes 222030886 isec NULL; isec_yes 238835570 isec NULL; isec_yes 263587444 isec NULL; isec_yes 280912141 ------------------------------ Can somebody throw some light on it ? I am using xfs.sgi.com with commit 9e4c109ac822395e0aae650e4e3c9e4903f6602f at the top. Regards, Chandra _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Occasional memory fault in inode_has_perm() while running xfstest 234 2011-11-10 21:36 Occasional memory fault in inode_has_perm() while running xfstest 234 Chandra Seetharaman @ 2011-11-14 10:27 ` Christoph Hellwig 2011-11-14 15:13 ` Eric Paris 0 siblings, 1 reply; 5+ messages in thread From: Christoph Hellwig @ 2011-11-14 10:27 UTC (permalink / raw) To: Chandra Seetharaman; +Cc: linux-security-module, XFS Mailing List This looks like a selinux issues. Ccing the LSM list. On Thu, Nov 10, 2011 at 03:36:43PM -0600, Chandra Seetharaman wrote: > Hi All, > > While debugging the xfstest case 234, I was occasionally hitting the > following memory fault. Has anybody seen it ? > > ----------------- > IP: [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 > PGD 0 > Oops: 0000 [#1] SMP > CPU 0 > Modules linked in: xfs exportfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun kvm_intel kvm cdc_ether usbnet mii microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core ses enclosure sg igb dca ext4 mbcache jbd2 sd_mod crc_t10dif ahci libahci megaraid_sas [last unloaded: scsi_wait_scan] > > Pid: 32611, comm: setquota Not tainted 3.1.0-rc9.virgin+ #6 IBM System x3630 M3 -[7377AC1]-/69Y1101 > RIP: 0010:[<ffffffff811e57ff>] [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 > RSP: 0018:ffff880642bcdb78 EFLAGS: 00010246 > RAX: 0000000000800002 RBX: ffff88064f2205f8 RCX: 0000000000800000 > RDX: 0000000000800000 RSI: 0000000000000000 RDI: ffff880649e58480 > RBP: ffff880642bcdb78 R08: ffff880642bcdb88 R09: 0000000000000080 > R10: ffff880658ffff00 R11: ffff880642bcdb88 R12: 0000000000000081 > R13: ffff88064f2205f8 R14: ffff8806592b8100 R15: 0000000000000000 > FS: 00007f56dfa3a700(0000) GS:ffff88067f200000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000020 CR3: 0000000642b30000 CR4: 00000000000006f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process setquota (pid: 32611, threadinfo ffff880642bcc000, task ffff8806592b8100) > Stack: > ffff880642bcdc18 ffffffff811e5d79 0000000000000009 0000000000000000 > ffff88064f2205f8 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > Call Trace: > [<ffffffff811e5d79>] selinux_inode_permission+0xa9/0x100 > [<ffffffff811e323c>] security_inode_permission+0x1c/0x30 > [<ffffffff81162509>] inode_permission+0x49/0x100 > [<ffffffff81164b57>] link_path_walk+0x87/0x810 > [<ffffffff810fedfa>] ? unlock_page+0x2a/0x40 > [<ffffffff81165955>] path_lookupat+0x55/0x690 > [<ffffffff81125867>] ? handle_pte_fault+0xf7/0xb50 > [<ffffffff81165fc1>] do_path_lookup+0x31/0xc0 > [<ffffffff81162168>] ? getname_flags+0x1f8/0x280 > [<ffffffff81166df9>] user_path_at+0x59/0xa0 > [<ffffffff8112641b>] ? handle_mm_fault+0x15b/0x270 > [<ffffffff814af8c0>] ? do_page_fault+0x1e0/0x460 > [<ffffffff81146a62>] ? kmem_cache_alloc+0x152/0x190 > [<ffffffff8115b9c7>] vfs_fstatat+0x47/0x80 > [<ffffffff81077571>] ? do_sigaction+0x91/0x1d0 > [<ffffffff8115badb>] vfs_stat+0x1b/0x20 > [<ffffffff8115bb04>] sys_newstat+0x24/0x50 > [<ffffffff810c3c4f>] ? audit_syscall_entry+0x1bf/0x1f0 > [<ffffffff814b29c2>] system_call_fastpath+0x16/0x1b > Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 f6 46 0d 02 75 23 48 8b 76 38 48 8b 7f 68 45 89 c1 49 89 c8 89 d1 <0f> b7 46 20 8b 7f 04 8b 76 1c 89 c2 e8 a0 f9 ff ff c9 c3 31 c0 > RIP [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 > RSP <ffff880642bcdb78> > CR2: 0000000000000020 > ---[ end trace 5d054c892d311b3f ]--- > ---------------------------- > > I made some code changes and found that inode->i_security is the data > structure that is NULL. > > I added the following code > ------------------ > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 266a229..43870ec 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -1466,6 +1466,7 @@ static int task_has_system(struct task_struct *tsk, > SECCLASS_SYSTEM, perms, NULL); > } > > +u64 isec_yes; > /* Check whether a task has a particular permission to an inode. > The 'adp' parameter is optional and allows other audit > data to be passed (e.g. the dentry). */ > @@ -1486,6 +1487,13 @@ static int inode_has_perm(const struct cred *cred, > sid = cred_sid(cred); > isec = inode->i_security; > > + if (isec) > + isec_yes++; > + else { > + printk("isec NULL; isec_yes %llu\n", isec_yes); > + return -EACCES; > + } > + > return avc_has_perm_flags(sid, isec->sid, isec->sclass, perms, adp, flags); > } > > -------------------------------- > > and this is what I see in /var/log/messages > ----------------------------- > isec NULL; isec_yes 14345860 > isec NULL; isec_yes 102846678 > isec NULL; isec_yes 107203361 > isec NULL; isec_yes 136859591 > isec NULL; isec_yes 140941549 > isec NULL; isec_yes 168163633 > isec NULL; isec_yes 222030886 > isec NULL; isec_yes 238835570 > isec NULL; isec_yes 263587444 > isec NULL; isec_yes 280912141 > ------------------------------ > > Can somebody throw some light on it ? > > I am using xfs.sgi.com with commit 9e4c109ac822395e0aae650e4e3c9e4903f6602f > at the top. > > Regards, > > Chandra > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Occasional memory fault in inode_has_perm() while running xfstest 234 2011-11-14 10:27 ` Christoph Hellwig @ 2011-11-14 15:13 ` Eric Paris 2011-11-14 20:20 ` Christoph Hellwig 2011-11-14 21:55 ` Chandra Seetharaman 0 siblings, 2 replies; 5+ messages in thread From: Eric Paris @ 2011-11-14 15:13 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-security-module, Chandra Seetharaman, XFS Mailing List The only way this can happen is if the filesystem is creating inodes and not calling security_inode_alloc() (which should be done in inode_init_always) I can only guess (and believe me it is a complete wild guess after looking at grep for 5 seconds) it has something to do with the XFS __releases() function which does some weirdness in the case of a failed call to inode_init_always(). The only other option is an FS somehow still uses an inode after __destroy_inode(), but I'd assume that would land you in other troubles. In either case, I'm hard pressed to blame SELinux/LSM, since the VFS does appear to be hooked in the right places (inode_init_alwasys and __destroy_inode) to set and unset inode->i_security.... -Eric On Mon, Nov 14, 2011 at 5:27 AM, Christoph Hellwig <hch@infradead.org> wrote: > This looks like a selinux issues. Ccing the LSM list. > > On Thu, Nov 10, 2011 at 03:36:43PM -0600, Chandra Seetharaman wrote: >> Hi All, >> >> While debugging the xfstest case 234, I was occasionally hitting the >> following memory fault. Has anybody seen it ? >> >> ----------------- >> IP: [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 >> PGD 0 >> Oops: 0000 [#1] SMP >> CPU 0 >> Modules linked in: xfs exportfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun kvm_intel kvm cdc_ether usbnet mii microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core ses enclosure sg igb dca ext4 mbcache jbd2 sd_mod crc_t10dif ahci libahci megaraid_sas [last unloaded: scsi_wait_scan] >> >> Pid: 32611, comm: setquota Not tainted 3.1.0-rc9.virgin+ #6 IBM System x3630 M3 -[7377AC1]-/69Y1101 >> RIP: 0010:[<ffffffff811e57ff>] [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 >> RSP: 0018:ffff880642bcdb78 EFLAGS: 00010246 >> RAX: 0000000000800002 RBX: ffff88064f2205f8 RCX: 0000000000800000 >> RDX: 0000000000800000 RSI: 0000000000000000 RDI: ffff880649e58480 >> RBP: ffff880642bcdb78 R08: ffff880642bcdb88 R09: 0000000000000080 >> R10: ffff880658ffff00 R11: ffff880642bcdb88 R12: 0000000000000081 >> R13: ffff88064f2205f8 R14: ffff8806592b8100 R15: 0000000000000000 >> FS: 00007f56dfa3a700(0000) GS:ffff88067f200000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> CR2: 0000000000000020 CR3: 0000000642b30000 CR4: 00000000000006f0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >> Process setquota (pid: 32611, threadinfo ffff880642bcc000, task ffff8806592b8100) >> Stack: >> ffff880642bcdc18 ffffffff811e5d79 0000000000000009 0000000000000000 >> ffff88064f2205f8 0000000000000000 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> Call Trace: >> [<ffffffff811e5d79>] selinux_inode_permission+0xa9/0x100 >> [<ffffffff811e323c>] security_inode_permission+0x1c/0x30 >> [<ffffffff81162509>] inode_permission+0x49/0x100 >> [<ffffffff81164b57>] link_path_walk+0x87/0x810 >> [<ffffffff810fedfa>] ? unlock_page+0x2a/0x40 >> [<ffffffff81165955>] path_lookupat+0x55/0x690 >> [<ffffffff81125867>] ? handle_pte_fault+0xf7/0xb50 >> [<ffffffff81165fc1>] do_path_lookup+0x31/0xc0 >> [<ffffffff81162168>] ? getname_flags+0x1f8/0x280 >> [<ffffffff81166df9>] user_path_at+0x59/0xa0 >> [<ffffffff8112641b>] ? handle_mm_fault+0x15b/0x270 >> [<ffffffff814af8c0>] ? do_page_fault+0x1e0/0x460 >> [<ffffffff81146a62>] ? kmem_cache_alloc+0x152/0x190 >> [<ffffffff8115b9c7>] vfs_fstatat+0x47/0x80 >> [<ffffffff81077571>] ? do_sigaction+0x91/0x1d0 >> [<ffffffff8115badb>] vfs_stat+0x1b/0x20 >> [<ffffffff8115bb04>] sys_newstat+0x24/0x50 >> [<ffffffff810c3c4f>] ? audit_syscall_entry+0x1bf/0x1f0 >> [<ffffffff814b29c2>] system_call_fastpath+0x16/0x1b >> Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 f6 46 0d 02 75 23 48 8b 76 38 48 8b 7f 68 45 89 c1 49 89 c8 89 d1 <0f> b7 46 20 8b 7f 04 8b 76 1c 89 c2 e8 a0 f9 ff ff c9 c3 31 c0 >> RIP [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 >> RSP <ffff880642bcdb78> >> CR2: 0000000000000020 >> ---[ end trace 5d054c892d311b3f ]--- >> ---------------------------- >> >> I made some code changes and found that inode->i_security is the data >> structure that is NULL. >> >> I added the following code >> ------------------ >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c >> index 266a229..43870ec 100644 >> --- a/security/selinux/hooks.c >> +++ b/security/selinux/hooks.c >> @@ -1466,6 +1466,7 @@ static int task_has_system(struct task_struct *tsk, >> SECCLASS_SYSTEM, perms, NULL); >> } >> >> +u64 isec_yes; >> /* Check whether a task has a particular permission to an inode. >> The 'adp' parameter is optional and allows other audit >> data to be passed (e.g. the dentry). */ >> @@ -1486,6 +1487,13 @@ static int inode_has_perm(const struct cred *cred, >> sid = cred_sid(cred); >> isec = inode->i_security; >> >> + if (isec) >> + isec_yes++; >> + else { >> + printk("isec NULL; isec_yes %llu\n", isec_yes); >> + return -EACCES; >> + } >> + >> return avc_has_perm_flags(sid, isec->sid, isec->sclass, perms, adp, flags); >> } >> >> -------------------------------- >> >> and this is what I see in /var/log/messages >> ----------------------------- >> isec NULL; isec_yes 14345860 >> isec NULL; isec_yes 102846678 >> isec NULL; isec_yes 107203361 >> isec NULL; isec_yes 136859591 >> isec NULL; isec_yes 140941549 >> isec NULL; isec_yes 168163633 >> isec NULL; isec_yes 222030886 >> isec NULL; isec_yes 238835570 >> isec NULL; isec_yes 263587444 >> isec NULL; isec_yes 280912141 >> ------------------------------ >> >> Can somebody throw some light on it ? >> >> I am using xfs.sgi.com with commit 9e4c109ac822395e0aae650e4e3c9e4903f6602f >> at the top. >> >> Regards, >> >> Chandra >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > ---end quoted text--- > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Occasional memory fault in inode_has_perm() while running xfstest 234 2011-11-14 15:13 ` Eric Paris @ 2011-11-14 20:20 ` Christoph Hellwig 2011-11-14 21:55 ` Chandra Seetharaman 1 sibling, 0 replies; 5+ messages in thread From: Christoph Hellwig @ 2011-11-14 20:20 UTC (permalink / raw) To: Eric Paris Cc: Christoph Hellwig, linux-security-module, Chandra Seetharaman, XFS Mailing List On Mon, Nov 14, 2011 at 10:13:11AM -0500, Eric Paris wrote: > The only way this can happen is if the filesystem is creating inodes > and not calling security_inode_alloc() (which should be done in > inode_init_always) > > I can only guess (and believe me it is a complete wild guess after > looking at grep for 5 seconds) it has something to do with the XFS > __releases() function which does some weirdness in the case of a > failed call to inode_init_always(). Do you mean xfs_iget_cache_hit? > The only other option is an FS somehow still uses an inode after > __destroy_inode(), but I'd assume that would land you in other > troubles. In either case, I'm hard pressed to blame SELinux/LSM, > since the VFS does appear to be hooked in the right places > (inode_init_alwasys and __destroy_inode) to set and unset > inode->i_security.... XFS inodes have a longer life time than VFS inodes they still hang around after ->destroy_inode, and if we manage to reuse them we'll call inode_init_always on them manually. The error handling there is nasty - basically we try to move it back into the state before we tried to reuse it, return an error to userspace and then expect the inode to either get reclaimed, or that we have enough memory next time someone tries to reuse it. Note that the only way for it to fail is if security_inode_alloc fails, so on normal non-LSM systems it won't ever fail. I can't really see an issue with i_security lifetimes from a quick look over the code, though. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Occasional memory fault in inode_has_perm() while running xfstest 234 2011-11-14 15:13 ` Eric Paris 2011-11-14 20:20 ` Christoph Hellwig @ 2011-11-14 21:55 ` Chandra Seetharaman 1 sibling, 0 replies; 5+ messages in thread From: Chandra Seetharaman @ 2011-11-14 21:55 UTC (permalink / raw) To: Eric Paris; +Cc: Christoph Hellwig, linux-security-module, XFS Mailing List On Mon, 2011-11-14 at 10:13 -0500, Eric Paris wrote: > The only way this can happen is if the filesystem is creating inodes > and not calling security_inode_alloc() (which should be done in > inode_init_always) > > I can only guess (and believe me it is a complete wild guess after > looking at grep for 5 seconds) it has something to do with the XFS > __releases() function which does some weirdness in the case of a > failed call to inode_init_always(). > > The only other option is an FS somehow still uses an inode after > __destroy_inode(), but I'd assume that would land you in other > troubles. In either case, I'm hard pressed to blame SELinux/LSM, > since the VFS does appear to be hooked in the right places > (inode_init_alwasys and __destroy_inode) to set and unset > inode->i_security.... Hi Eric, Thanks for your response. I added code to print inode value at xfs_iget_cache_hit() and inode_has_perm(). I see the inode values printed at inode_has_perm() but not at xfs_iget_cache_hit(), which means the failure at xfs_iget_cache_hit() is not the cause for the inode_security being NULL at inode_has_perm(). So, it makes me think that the memory fault I see is related to the (error path) code in xfs_iget_cache_hit(). Any other suggestions to try ? Chandra > > -Eric > > On Mon, Nov 14, 2011 at 5:27 AM, Christoph Hellwig <hch@infradead.org> wrote: > > This looks like a selinux issues. Ccing the LSM list. > > > > On Thu, Nov 10, 2011 at 03:36:43PM -0600, Chandra Seetharaman wrote: > >> Hi All, > >> > >> While debugging the xfstest case 234, I was occasionally hitting the > >> following memory fault. Has anybody seen it ? > >> > >> ----------------- > >> IP: [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 > >> PGD 0 > >> Oops: 0000 [#1] SMP > >> CPU 0 > >> Modules linked in: xfs exportfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat iptable_mangle bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun kvm_intel kvm cdc_ether usbnet mii microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core ses enclosure sg igb dca ext4 mbcache jbd2 sd_mod crc_t10dif ahci libahci megaraid_sas [last unloaded: scsi_wait_scan] > >> > >> Pid: 32611, comm: setquota Not tainted 3.1.0-rc9.virgin+ #6 IBM System x3630 M3 -[7377AC1]-/69Y1101 > >> RIP: 0010:[<ffffffff811e57ff>] [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 > >> RSP: 0018:ffff880642bcdb78 EFLAGS: 00010246 > >> RAX: 0000000000800002 RBX: ffff88064f2205f8 RCX: 0000000000800000 > >> RDX: 0000000000800000 RSI: 0000000000000000 RDI: ffff880649e58480 > >> RBP: ffff880642bcdb78 R08: ffff880642bcdb88 R09: 0000000000000080 > >> R10: ffff880658ffff00 R11: ffff880642bcdb88 R12: 0000000000000081 > >> R13: ffff88064f2205f8 R14: ffff8806592b8100 R15: 0000000000000000 > >> FS: 00007f56dfa3a700(0000) GS:ffff88067f200000(0000) knlGS:0000000000000000 > >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > >> CR2: 0000000000000020 CR3: 0000000642b30000 CR4: 00000000000006f0 > >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > >> Process setquota (pid: 32611, threadinfo ffff880642bcc000, task ffff8806592b8100) > >> Stack: > >> ffff880642bcdc18 ffffffff811e5d79 0000000000000009 0000000000000000 > >> ffff88064f2205f8 0000000000000000 0000000000000000 0000000000000000 > >> 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > >> Call Trace: > >> [<ffffffff811e5d79>] selinux_inode_permission+0xa9/0x100 > >> [<ffffffff811e323c>] security_inode_permission+0x1c/0x30 > >> [<ffffffff81162509>] inode_permission+0x49/0x100 > >> [<ffffffff81164b57>] link_path_walk+0x87/0x810 > >> [<ffffffff810fedfa>] ? unlock_page+0x2a/0x40 > >> [<ffffffff81165955>] path_lookupat+0x55/0x690 > >> [<ffffffff81125867>] ? handle_pte_fault+0xf7/0xb50 > >> [<ffffffff81165fc1>] do_path_lookup+0x31/0xc0 > >> [<ffffffff81162168>] ? getname_flags+0x1f8/0x280 > >> [<ffffffff81166df9>] user_path_at+0x59/0xa0 > >> [<ffffffff8112641b>] ? handle_mm_fault+0x15b/0x270 > >> [<ffffffff814af8c0>] ? do_page_fault+0x1e0/0x460 > >> [<ffffffff81146a62>] ? kmem_cache_alloc+0x152/0x190 > >> [<ffffffff8115b9c7>] vfs_fstatat+0x47/0x80 > >> [<ffffffff81077571>] ? do_sigaction+0x91/0x1d0 > >> [<ffffffff8115badb>] vfs_stat+0x1b/0x20 > >> [<ffffffff8115bb04>] sys_newstat+0x24/0x50 > >> [<ffffffff810c3c4f>] ? audit_syscall_entry+0x1bf/0x1f0 > >> [<ffffffff814b29c2>] system_call_fastpath+0x16/0x1b > >> Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 f6 46 0d 02 75 23 48 8b 76 38 48 8b 7f 68 45 89 c1 49 89 c8 89 d1 <0f> b7 46 20 8b 7f 04 8b 76 1c 89 c2 e8 a0 f9 ff ff c9 c3 31 c0 > >> RIP [<ffffffff811e57ff>] inode_has_perm+0x1f/0x40 > >> RSP <ffff880642bcdb78> > >> CR2: 0000000000000020 > >> ---[ end trace 5d054c892d311b3f ]--- > >> ---------------------------- > >> > >> I made some code changes and found that inode->i_security is the data > >> structure that is NULL. > >> > >> I added the following code > >> ------------------ > >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > >> index 266a229..43870ec 100644 > >> --- a/security/selinux/hooks.c > >> +++ b/security/selinux/hooks.c > >> @@ -1466,6 +1466,7 @@ static int task_has_system(struct task_struct *tsk, > >> SECCLASS_SYSTEM, perms, NULL); > >> } > >> > >> +u64 isec_yes; > >> /* Check whether a task has a particular permission to an inode. > >> The 'adp' parameter is optional and allows other audit > >> data to be passed (e.g. the dentry). */ > >> @@ -1486,6 +1487,13 @@ static int inode_has_perm(const struct cred *cred, > >> sid = cred_sid(cred); > >> isec = inode->i_security; > >> > >> + if (isec) > >> + isec_yes++; > >> + else { > >> + printk("isec NULL; isec_yes %llu\n", isec_yes); > >> + return -EACCES; > >> + } > >> + > >> return avc_has_perm_flags(sid, isec->sid, isec->sclass, perms, adp, flags); > >> } > >> > >> -------------------------------- > >> > >> and this is what I see in /var/log/messages > >> ----------------------------- > >> isec NULL; isec_yes 14345860 > >> isec NULL; isec_yes 102846678 > >> isec NULL; isec_yes 107203361 > >> isec NULL; isec_yes 136859591 > >> isec NULL; isec_yes 140941549 > >> isec NULL; isec_yes 168163633 > >> isec NULL; isec_yes 222030886 > >> isec NULL; isec_yes 238835570 > >> isec NULL; isec_yes 263587444 > >> isec NULL; isec_yes 280912141 > >> ------------------------------ > >> > >> Can somebody throw some light on it ? > >> > >> I am using xfs.sgi.com with commit 9e4c109ac822395e0aae650e4e3c9e4903f6602f > >> at the top. > >> > >> Regards, > >> > >> Chandra > >> > >> _______________________________________________ > >> xfs mailing list > >> xfs@oss.sgi.com > >> http://oss.sgi.com/mailman/listinfo/xfs > > ---end quoted text--- > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-11-14 21:55 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-10 21:36 Occasional memory fault in inode_has_perm() while running xfstest 234 Chandra Seetharaman 2011-11-14 10:27 ` Christoph Hellwig 2011-11-14 15:13 ` Eric Paris 2011-11-14 20:20 ` Christoph Hellwig 2011-11-14 21:55 ` Chandra Seetharaman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox