From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:55074 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756124AbdD1FeX (ORCPT ); Fri, 28 Apr 2017 01:34:23 -0400 Date: Fri, 28 Apr 2017 06:34:20 +0100 From: Al Viro To: Nikolay Borisov Cc: dvyukov@google.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com, Dave Chinner Subject: Re: [PATCH] fs: Handle register_shrinker failure Message-ID: <20170428053420.GJ29622@ZenIV.linux.org.uk> References: <1490342140-19138-1-git-send-email-nborisov@suse.com> <20170428043046.GI29622@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170428043046.GI29622@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Apr 28, 2017 at 05:30:46AM +0100, Al Viro wrote: > I really don't like that. Your "remove it from all lists and pray that > nobody has picked a reference of any kind" at the very least needs a careful > written proof of correctness. AFAICS, somebody might've found it on the > list and attempted to grab ->s_umount (grab_super() from another thread > calling sget()). Then they'd block until your up_write() in there and > bugger the system up trying to play with ->s_umount in the object you've > freed. > > NAK. Yes, the bug is real, but this is not a solution. Why do we register it that early, anyway? super_cache_scan() won't do anything until we are done with setting the sucker up and dropped ->s_umount. How about we initialize ->s_shrink.list in alloc_super(), have deactivate_locked_super() call unregister_shrinker() only if list_empty(...) and have mount_fs() do error = register_shrinker(&sb->s_shrink); if (error) goto out_sb; sb->s_flags |= MS_BORN; error = security_sb_kern_mount(sb, flags, secdata); if (error) goto out_sb; Folks? Am I missing something subtle here?