From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750837AbdAWJgS (ORCPT ); Mon, 23 Jan 2017 04:36:18 -0500 Received: from mail-vk0-f45.google.com ([209.85.213.45]:35723 "EHLO mail-vk0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750703AbdAWJgR (ORCPT ); Mon, 23 Jan 2017 04:36:17 -0500 MIME-Version: 1.0 In-Reply-To: <87lgu5w92e.fsf@xmission.com> References: <877f5py5c2.fsf@xmission.com> <87lgu5w92e.fsf@xmission.com> From: Dmitry Vyukov Date: Mon, 23 Jan 2017 10:35:56 +0100 Message-ID: Subject: Re: namespace: deadlock in dec_pid_namespaces To: "Eric W. Biederman" Cc: Nikolay Borisov , avagin , serge@hallyn.com, Kees Cook , Al Viro , LKML , syzkaller Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 21, 2017 at 1:28 AM, Eric W. Biederman wrote: > Nikolay Borisov writes: > >> On 20.01.2017 20:05, Eric W. Biederman wrote: >>> Nikolay Borisov writes: >>> >>>> On 20.01.2017 15:07, Dmitry Vyukov wrote: >>>>> Hello, >>>>> >>>>> I've got the following deadlock report while running syzkaller fuzzer >>>>> on eec0d3d065bfcdf9cd5f56dd2a36b94d12d32297 of linux-next (on odroid >>>>> device if it matters): >>> >>> I am puzzled I thought we had fixed this with: >>> add7c65ca426 ("pid: fix lockdep deadlock warning due to ucount_lock") >>> But apparently not. We just moved it from hardirq to softirq context. Bah. >>> >>> Thank you very much for the report. >>> >>> Nikolay can you make your change use spinlock_irq? And have put_ucounts >>> do spin_lock_irqsave? That way we just don't care where we call this. >> >> Like the one attached? > > Exactly thank you. Dmitry if you have time to test that patch and > verify it fixes your issue I would appreciate it. > >> I haven't really taken careful look as to whether >> the function where _irq versions do fiddle with irq state, since this >> might cause a problem if we unconditionally enable them. > > In code paths where we can sleep irqs must come in enabled or it's a > bug. > > spin_lock_irq which unconditionally disables irqs is thus safe on the > allocation path. > > Similary spin_unlock_irq which unconditionally enables irqs is also safe > on the allocation path. Yes, it fixes the issue for me: Tested-by: Dmitry Vyukov