From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9F9EC433DF for ; Wed, 12 Aug 2020 01:31:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F28720866 for ; Wed, 12 Aug 2020 01:31:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="R3/JLmzK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F28720866 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F40748D0003; Tue, 11 Aug 2020 21:31:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EBE2F8D0001; Tue, 11 Aug 2020 21:31:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D86908D0003; Tue, 11 Aug 2020 21:31:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id BC3218D0001 for ; Tue, 11 Aug 2020 21:31:37 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 80167181AEF15 for ; Wed, 12 Aug 2020 01:31:37 +0000 (UTC) X-FDA: 77140189434.10.dime36_361025b26fe7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 3083B169F9A for ; Wed, 12 Aug 2020 01:31:37 +0000 (UTC) X-HE-Tag: dime36_361025b26fe7 X-Filterd-Recvd-Size: 3110 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Aug 2020 01:31:36 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9FAA62076C; Wed, 12 Aug 2020 01:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597195896; bh=LR4UGW+njSoXnZHAIRR0pSvQ0DPvccZZtLZeliQC1Vg=; h=Date:From:To:Subject:In-Reply-To:From; b=R3/JLmzK/OuNfC0EC3L2nL9tGRjuxBTBY7N1mPutFJpnR0UVxWIBrfSms0x81zEXE DJqLobslLTaetLjxNJ5amsU2FfNYtR5H+9qKPQQaEOM69kz3h4CEd1YxEfK4jVEYD1 zgOOAZljpExVAZ3/6t3kPNkcZn/wdqhXFR0kVTgs= Date: Tue, 11 Aug 2020 18:31:35 -0700 From: Andrew Morton To: akpm@linux-foundation.org, amir73il@gmail.com, linux-mm@kvack.org, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, mszeredi@redhat.com, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, walters@verbum.org, willy@infradead.org Subject: [patch 025/165] hugetlbfs: prevent filesystem stacking of hugetlbfs Message-ID: <20200812013135.OJVdJOjRJ%akpm@linux-foundation.org> In-Reply-To: <20200811182949.e12ae9a472e3b5e27e16ad6c@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Queue-Id: 3083B169F9A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Mike Kravetz Subject: hugetlbfs: prevent filesystem stacking of hugetlbfs syzbot found issues with having hugetlbfs on a union/overlay as reported in [1]. Due to the limitations (no write) and special functionality of hugetlbfs, it does not work well in filesystem stacking. There are no know use cases for hugetlbfs stacking. Rather than making modifications to get hugetlbfs working in such environments, simply prevent stacking. [1] https://lore.kernel.org/linux-mm/000000000000b4684e05a2968ca6@google.com/ Link: http://lkml.kernel.org/r/80f869aa-810d-ef6c-8888-b46cee135907@oracle.com Signed-off-by: Mike Kravetz Reported-by: syzbot+d6ec23007e951dadf3de@syzkaller.appspotmail.com Suggested-by: Amir Goldstein Acked-by: Miklos Szeredi Cc: Al Viro Cc: Matthew Wilcox Cc: Colin Walters Signed-off-by: Andrew Morton --- fs/hugetlbfs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/fs/hugetlbfs/inode.c~hugetlbfs-prevent-filesystem-stacking-of-hugetlbfs +++ a/fs/hugetlbfs/inode.c @@ -1364,6 +1364,12 @@ hugetlbfs_fill_super(struct super_block sb->s_magic = HUGETLBFS_MAGIC; sb->s_op = &hugetlbfs_ops; sb->s_time_gran = 1; + + /* + * Due to the special and limited functionality of hugetlbfs, it does + * not work well as a stacking filesystem. + */ + sb->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; sb->s_root = d_make_root(hugetlbfs_get_root(sb, ctx)); if (!sb->s_root) goto out_free; _