From patchwork Thu Apr 14 23:48:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrey Ulanov X-Patchwork-Id: 8843861 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 399A9C0553 for ; Thu, 14 Apr 2016 23:49:08 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2C35E202FF for ; Thu, 14 Apr 2016 23:49:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55D822026C for ; Thu, 14 Apr 2016 23:49:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752406AbcDNXsz (ORCPT ); Thu, 14 Apr 2016 19:48:55 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:34605 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752238AbcDNXsy (ORCPT ); Thu, 14 Apr 2016 19:48:54 -0400 Received: by mail-pa0-f42.google.com with SMTP id ot11so49310488pab.1 for ; Thu, 14 Apr 2016 16:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=JjkjiloydTQaDs3sJmigJiL3Z+I0B9oLwBAIkhzyqHs=; b=OJxp7UJJ2w1RoJ4qkK1LdkaygrUwB/RVYK9FS1tZdp4VnBQtsPLKW+cMq5Hui5STgQ pTnDrO69kV9ty/TKEgntmJiWkHAdgleYkHQSymXzL2WyN0kh2eix/ZEt01z8cTZflLQi pLuroY6pVXn6ThG5gSAXCn3PaSv6FF6Cgny37W+rxC9Q6+pWlyFWr5dy8E3gP55jkWqP ldz2XabECERSDPPpfj0tCiUDm3nkCbSsDx1O7NJ3ubb7ilPFTP3RQwmbT39WZpqPoalo kXHKoVCHCK4J24J6ptZnhQoULcp6pf1bMDrtSdDF0GO/nRmBhm9gBBtHvsnasIjS5D0t SQBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=JjkjiloydTQaDs3sJmigJiL3Z+I0B9oLwBAIkhzyqHs=; b=GKTCtIlE9l5j3wrM4hSXBoRhVIe+MU4mKDmBHAM1A7QdJjdrlxnQaFe3cIEtCvEwEz tpBiO142DTNXVvHhvkDEro0xOfeMpemnCxYhKc6p/o5Vc2XeJAvLaUMW3YVTgrIU8//K OUqVo1l77o9YblcXhbb1MibLrsIgn8d57fbMHbU3cKQMit8V00EiNAZRemRxQ3Z396tY 6dcszd4zcRnhmhCPuTwvGYXo1yks0FZ4fLosh0Te5NHQ/IJKSryW5y2+1HBU1cOoWQ7l XEL0OAreVCHcKPCFDd7vLSjLN3HmxGyB3lt1pUA0Vi1fFfWKrjWJSTqv1VGTXLybKYtv Cp8Q== X-Gm-Message-State: AOPr4FV2PVXs+gOTZjoH/8KTA2tYao2mGhztS1Ih5zFSigo35LZrC3Iyg8xoMiIc2JTMLhy+ X-Received: by 10.66.183.230 with SMTP id ep6mr25445102pac.89.1460677733756; Thu, 14 Apr 2016 16:48:53 -0700 (PDT) Received: from charon.kir.corp.google.com ([100.100.206.51]) by smtp.gmail.com with ESMTPSA id l81sm60351312pfj.21.2016.04.14.16.48.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Apr 2016 16:48:52 -0700 (PDT) From: Andrey Ulanov To: linux-fsdevel@vger.kernel.org Cc: Alexander Viro , linux-kernel@vger.kernel.org, Andrey Ulanov Subject: [PATCH] namespace: update event counter when umounting a deleted dentry Date: Thu, 14 Apr 2016 16:48:32 -0700 Message-Id: <1460677712-26909-1-git-send-email-andreyu@google.com> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This change fixes a problem originally reported at: https://github.com/coreos/bugs/issues/1153 You can find code that reproduces it at: https://github.com/coreos/bugs/issues/1153#issuecomment-210201681 - m_start() in fs/namespace.c expects that ns->event is incremented each time a mount added or removed from ns->list. - umount_tree() removes items from the list but does not increment event counter, expecting that it's done before the function is called. - There are some codepaths that call umount_tree() without updating "event" counter. e.g. from __detach_mounts(). - When this happens m_start may reuse a cached mount structure that no longer belongs to ns->list (i.e. use after free which usually leads to infinite loop). This change fixes the above problem by incrementing global event counter before invoking umount_tree(). Signed-off-by: Andrey Ulanov --- fs/namespace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index 4fb1691..b06bb9a 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1562,6 +1562,7 @@ void __detach_mounts(struct dentry *dentry) goto out_unlock; lock_mount_hash(); + event++; while (!hlist_empty(&mp->m_list)) { mnt = hlist_entry(mp->m_list.first, struct mount, mnt_mp_list); if (mnt->mnt.mnt_flags & MNT_UMOUNT) { @@ -1576,7 +1577,7 @@ out_unlock: namespace_unlock(); } -/* +/* * Is the caller allowed to modify his namespace? */ static inline bool may_mount(void) @@ -1765,6 +1766,7 @@ void drop_collected_mounts(struct vfsmount *mnt) { namespace_lock(); lock_mount_hash(); + event++; umount_tree(real_mount(mnt), UMOUNT_SYNC); unlock_mount_hash(); namespace_unlock();