linux-kernel - Re: frequent lockups in 3.18rc4

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141204105103.GD14519@arm.com>
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/