Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752084AbcKQVo7 (ORCPT ); Thu, 17 Nov 2016 16:44:59 -0500 Received: from mail-oi0-f65.google.com ([209.85.218.65]:34712 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbcKQVo5 (ORCPT ); Thu, 17 Nov 2016 16:44:57 -0500 MIME-Version: 1.0 In-Reply-To: <20161010031450.GW19539@ZenIV.linux.org.uk> References: <20161010024607.GV19539@ZenIV.linux.org.uk> <20161010031450.GW19539@ZenIV.linux.org.uk> From: Cong Wang Date: Thu, 17 Nov 2016 13:44:35 -0800 Message-ID: Subject: Re: net: BUG still has locks held in unix_stream_splice_read To: Al Viro Cc: Dmitry Vyukov , David Miller , Hannes Frederic Sowa , Eric Dumazet , netdev , LKML , syzkaller , Colin Cross , Mandeep Singh Baines Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1509 Lines: 31 On Sun, Oct 9, 2016 at 8:14 PM, Al Viro wrote: > E.g what will happen if some code does a read on AF_UNIX socket with > some local mutex held? AFAICS, there are exactly two callers of > freezable_schedule_timeout() - this one and one in XFS; the latter is > in a kernel thread where we do have good warranties about the locking > environment, but here it's in the bleeding ->recvmsg/->splice_read and > for those assumption that caller doesn't hold any locks is pretty > strong, especially since it's not documented anywhere. > > What's going on there? Commit 2b15af6f95 ("af_unix: use freezable blocking calls in read") converts schedule_timeout() to its freezable version, it was probably correct at that time, but later, commit 2b514574f7e88c8498027ee366 ("net: af_unix: implement splice for stream af_unix sockets") breaks its requirement for a freezable sleep: commit 0f9548ca10916dec166eaf74c816bded7d8e611d lockdep: check that no locks held at freeze time We shouldn't try_to_freeze if locks are held. Holding a lock can cause a deadlock if the lock is later acquired in the suspend or hibernate path (e.g. by dpm). Holding a lock can also cause a deadlock in the case of cgroup_freezer if a lock is held inside a frozen cgroup that is later acquired by a process outside that group. So probably we just need to revert commit 2b15af6f95 now. I am going to send a revert for at least -net and -stable, since Dmitry saw this warning again.