From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open() Date: Wed, 03 Dec 2014 10:59:57 -0600 Message-ID: <87fvcwk6sy.fsf@x220.int.ebiederm.org> References: <20140805194627.GA30693@redhat.com> <20140805194655.GA30728@redhat.com> <20141203141433.GA25683@node.dhcp.inet.fi> Mime-Version: 1.0 Content-Type: text/plain Cc: Oleg Nesterov , "David S. Miller" , Linus Torvalds , Andrew Morton , Alexander Viro , Cyrill Gorcunov , David Howells , "Kirill A. Shutemov" , Peter Zijlstra , Sasha Levin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Alexey Dobriyan , netdev@vger.kernel.org To: "Kirill A. Shutemov" Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]:35432 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbaLCRCN (ORCPT ); Wed, 3 Dec 2014 12:02:13 -0500 In-Reply-To: <20141203141433.GA25683@node.dhcp.inet.fi> (Kirill A. Shutemov's message of "Wed, 3 Dec 2014 16:14:33 +0200") Sender: netdev-owner@vger.kernel.org List-ID: "Kirill A. Shutemov" writes: > On Tue, Aug 05, 2014 at 09:46:55PM +0200, Oleg Nesterov wrote: >> A simple test-case from Kirill Shutemov >> >> cat /proc/self/maps >/dev/null >> chmod +x /proc/self/net/packet >> exec /proc/self/net/packet >> >> makes lockdep unhappy, cat/exec take seq_file->lock + cred_guard_mutex in >> the opposite order. > > Oleg, I see it again with almost the same test-case: > > cat /proc/self/stack >/dev/null > chmod +x /proc/self/net/packet > exec /proc/self/net/packet > > Looks like bunch of proc files were converted to use seq_file by Alexey > Dobriyan around the same time you've fixed the issue for /proc/pid/maps. > > More generic test-case: > > find /proc/self/ -type f -exec dd if='{}' of=/dev/null bs=1 count=1 ';' 2>/dev/null > chmod +x /proc/self/net/packet > exec /proc/self/net/packet > > David, any justification for allowing chmod +x for files under > /proc/pid/net? I don't think there are any good reasons for allowing chmod +x for the proc generic files. Certainly executing any of them is nonsense. I do recall some weird conner cases existing. I think they resulted in a need to preserve chmod if not chmod +x. This is just me saying tread carefully before you change anything. It really should be safe to tweak proc_notify_change to not allow messing with the executable bits of proc files. > [ 2.042212] ====================================================== > [ 2.042930] [ INFO: possible circular locking dependency detected ] > [ 2.043648] 3.18.0-rc7-00003-g3a18ca061311-dirty #237 Not tainted > [ 2.044350] ------------------------------------------------------- > [ 2.045054] sh/94 is trying to acquire lock: > [ 2.045546] (&p->lock){+.+.+.}, at: [] seq_read+0x3d/0x3e0 > [ 2.045781] > [ 2.045781] but task is already holding lock: > [ 2.045781] (&sig->cred_guard_mutex){+.+.+.}, at: [] prepare_bprm_creds+0x2d/0x90 > [ 2.045781] > [ 2.045781] which lock already depends on the new lock. > [ 2.045781] > [ 2.045781] > [ 2.045781] the existing dependency chain (in reverse order) is: > [ 2.045781] > -> #1 (&sig->cred_guard_mutex){+.+.+.}: > [ 2.045781] [] __lock_acquire+0x4d9/0xd40 > [ 2.045781] [] lock_acquire+0xd2/0x2a0 > [ 2.045781] [] mutex_lock_killable_nested+0x66/0x460 > [ 2.045781] [] lock_trace+0x24/0x70 > [ 2.045781] [] proc_pid_stack+0x5f/0xe0 > [ 2.045781] [] proc_single_show+0x54/0xa0 > [ 2.045781] [] seq_read+0xe0/0x3e0 > [ 2.045781] [] vfs_read+0x97/0x180 > [ 2.045781] [] SyS_read+0x4d/0xc0 > [ 2.045781] [] system_call_fastpath+0x12/0x17 > [ 2.045781] > -> #0 (&p->lock){+.+.+.}: > [ 2.045781] [] validate_chain.isra.36+0xfff/0x1400 > [ 2.045781] [] __lock_acquire+0x4d9/0xd40 > [ 2.045781] [] lock_acquire+0xd2/0x2a0 > [ 2.045781] [] mutex_lock_nested+0x69/0x3c0 > [ 2.045781] [] seq_read+0x3d/0x3e0 > [ 2.045781] [] proc_reg_read+0x48/0x70 > [ 2.045781] [] vfs_read+0x97/0x180 > [ 2.045781] [] kernel_read+0x48/0x60 > [ 2.045781] [] prepare_binprm+0xdc/0x180 > [ 2.045781] [] do_execve_common.isra.29+0x4fa/0x960 > [ 2.045781] [] do_execve+0x18/0x20 > [ 2.045781] [] SyS_execve+0x25/0x30 > [ 2.045781] [] stub_execve+0x69/0xa0 > [ 2.045781] > [ 2.045781] other info that might help us debug this: > [ 2.045781] > [ 2.045781] Possible unsafe locking scenario: > [ 2.045781] > [ 2.045781] CPU0 CPU1 > [ 2.045781] ---- ---- > [ 2.045781] lock(&sig->cred_guard_mutex); > [ 2.045781] lock(&p->lock); > [ 2.045781] lock(&sig->cred_guard_mutex); > [ 2.045781] lock(&p->lock); > [ 2.045781] > [ 2.045781] *** DEADLOCK *** > [ 2.045781] > [ 2.045781] 1 lock held by sh/94: > [ 2.045781] #0: (&sig->cred_guard_mutex){+.+.+.}, at: [] prepare_bprm_creds+0x2d/0x90 > [ 2.045781] > [ 2.045781] stack backtrace: > [ 2.045781] CPU: 0 PID: 94 Comm: sh Not tainted 3.18.0-rc7-00003-g3a18ca061311-dirty #237 > [ 2.045781] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 > [ 2.045781] ffffffff82a48d50 ffff88085427bad8 ffffffff81844a85 0000000000000cac > [ 2.045781] ffffffff82a654a0 ffff88085427bb28 ffffffff810a1b03 0000000000000000 > [ 2.045781] ffff88085427bb68 ffff88085427bb28 ffff8808547f1500 ffff8808547f1c40 > [ 2.045781] Call Trace: > [ 2.045781] [] dump_stack+0x4e/0x68 > [ 2.045781] [] print_circular_bug+0x203/0x310 > [ 2.045781] [] validate_chain.isra.36+0xfff/0x1400 > [ 2.045781] [] ? local_clock+0x16/0x30 > [ 2.045781] [] __lock_acquire+0x4d9/0xd40 > [ 2.045781] [] lock_acquire+0xd2/0x2a0 > [ 2.045781] [] ? seq_read+0x3d/0x3e0 > [ 2.045781] [] mutex_lock_nested+0x69/0x3c0 > [ 2.045781] [] ? seq_read+0x3d/0x3e0 > [ 2.045781] [] ? sched_clock_cpu+0x98/0xc0 > [ 2.045781] [] ? seq_read+0x3d/0x3e0 > [ 2.045781] [] ? lockref_put_or_lock+0x29/0x40 > [ 2.045781] [] seq_read+0x3d/0x3e0 > [ 2.045781] [] ? lockref_put_or_lock+0x29/0x40 > [ 2.045781] [] proc_reg_read+0x48/0x70 > [ 2.045781] [] vfs_read+0x97/0x180 > [ 2.045781] [] kernel_read+0x48/0x60 > [ 2.045781] [] prepare_binprm+0xdc/0x180 > [ 2.045781] [] do_execve_common.isra.29+0x4fa/0x960 > [ 2.092142] tsc: Refined TSC clocksource calibration: 2693.484 MHz > [ 2.045781] [] ? do_execve_common.isra.29+0x133/0x960 > [ 2.045781] [] ? retint_swapgs+0xe/0x13 > [ 2.045781] [] do_execve+0x18/0x20 > [ 2.045781] [] SyS_execve+0x25/0x30 > [ 2.045781] [] stub_execve+0x69/0xa0