lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 4 Dec 2014 10:51:03 +0000 From: Will Deacon <will.deacon@....com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: "Kirill A. Shutemov" <kirill@...temov.name>, Tejun Heo <tj@...nel.org>, Dave Jones <davej@...hat.com>, Andy Lutomirski <luto@...capital.net>, Don Zickus <dzickus@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, Linux Kernel <linux-kernel@...r.kernel.org>, the arch/x86 maintainers <x86@...nel.org>, Peter Zijlstra <peterz@...radead.org> Subject: Re: frequent lockups in 3.18rc4 On Mon, Dec 01, 2014 at 06:36:04PM +0000, Linus Torvalds wrote: > On Mon, Dec 1, 2014 at 10:25 AM, Kirill A. Shutemov > <kirill@...temov.name> wrote: > > > > No idea about oom_score, but kernel happily accepts chmod on any file > > under /proc/PID/net/. > > /proc used to accept that fairly widely, but no, we tightened things > down, and core /proc files end up not accepting chmod. See > 'proc_setattr()': > > if (attr->ia_valid & ATTR_MODE) > return -EPERM; > > although particular /proc files could choose to not use 'proc_setattr' > if they want to. > > The '/proc/pid/net' subtree is obviously not doing that. No idea why, > and probably for no good reason. I just hit another one of these, but it's slightly different this time: [child1:811] [2219] execve(name="/proc/610/attr/keycreate", argv=0x3a044bf0, envp=0x3a04c810) this guy disappears off into the execve and never returns. A little later, another guy gets stuck on a completion after a sync: [child0:856] [155] sync() trinity-c0 D ffffffc000087570 0 856 612 0x00000000 Call trace: [<ffffffc000087570>] __switch_to+0x74/0x8c [<ffffffc0005350b4>] __schedule+0x204/0x670 [<ffffffc000535544>] schedule+0x24/0x74 [<ffffffc0005380a4>] schedule_timeout+0x134/0x18c [<ffffffc000536204>] wait_for_common+0x9c/0x144 [<ffffffc0005362bc>] wait_for_completion+0x10/0x1c [<ffffffc0001bbc14>] sync_inodes_sb+0x98/0x194 [<ffffffc0001c0244>] sync_inodes_one_sb+0x10/0x1c [<ffffffc0001984c8>] iterate_supers+0x10c/0x114 [<ffffffc0001c04c0>] sys_sync+0x38/0xa4 The backtrace for 811 looks bogus to me (or we're missing some entries): trinity-c1 R running task 0 811 612 0x00000000 Call trace: [<ffffffc000087570>] __switch_to+0x74/0x8c [<ffffffc0000ecb48>] __handle_domain_irq+0x9c/0xf4 [<ffffffc000301da4>] __this_cpu_preempt_check+0x14/0x20 [<ffffffc000538a2c>] _raw_spin_lock_irq+0x18/0x58 [<ffffffc000538cb4>] _raw_spin_unlock_irq+0x1c/0x48 [<ffffffc0000fa6bc>] run_timer_softirq+0x68/0x240 [<ffffffc0000b5b2c>] __do_softirq+0x110/0x244 [<ffffffc000301d84>] debug_smp_processor_id+0x18/0x24 and, as before, it has a weird child process that I can't backtrace: trinity-c1 R running task 0 861 811 0x00000000 Call trace: The RCU stall detector gets cross too, but the stall ends before it has a chance to dump anything. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists