From patchwork Mon Jul 13 16:15:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Down X-Patchwork-Id: 11660207 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6B74B722 for ; Mon, 13 Jul 2020 16:15:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 384F820738 for ; Mon, 13 Jul 2020 16:15:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="dqAuVp/M" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 384F820738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5CA358D0006; Mon, 13 Jul 2020 12:15:57 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 5534B8D0001; Mon, 13 Jul 2020 12:15:57 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41BC78D0006; Mon, 13 Jul 2020 12:15:57 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id 2238A8D0001 for ; Mon, 13 Jul 2020 12:15:57 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D59A2180AD838 for ; Mon, 13 Jul 2020 16:15:56 +0000 (UTC) X-FDA: 77033553912.25.earth53_4f041b626ee9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id C69251804E95D for ; Mon, 13 Jul 2020 16:15:34 +0000 (UTC) X-Spam-Summary: 1,0,0,5ecc8f3c5ab976a0,d41d8cd98f00b204,chris@chrisdown.name,,RULES_HIT:41:355:379:967:973:988:989:1260:1277:1312:1313:1314:1345:1437:1516:1518:1519:1535:1542:1593:1594:1595:1596:1711:1730:1747:1777:1792:1801:2198:2199:2393:2525:2553:2559:2564:2682:2685:2689:2731:2859:2890:2898:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4042:4250:4321:4605:5007:6119:6261:6653:6742:7875:9025:10004:10400:11026:11232:11473:11658:11914:12043:12291:12296:12297:12438:12517:12519:12555:12663:12679:12895:12986:13053:13439:13895:14096:14097:14181:14394:14721:21080:21444:21450:21451:21627:21740:21795:21939:21990:22013:30001:30034:30054:30066:30070:30090,0,RBL:209.85.208.67:@chrisdown.name:.lbl8.mailshell.net-66.201.201.201 62.14.0.100;04yfgyuhz6ccxhijg6naa47iwqiypop68zfkkz3i5nxxobpn9swhu5uxzko3d54.efztxhh7ged84pp6hg1zizur7ka6m4soo5dgaunwcjc48bhnx3nkpfzhd1bbedt.4 -lbl8.ma X-HE-Tag: earth53_4f041b626ee9 X-Filterd-Recvd-Size: 5508 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Jul 2020 16:15:34 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id b15so14145880edy.7 for ; Mon, 13 Jul 2020 09:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=qYE0MGzN5oZiWXIC6Rq6ejY3VVjgiXoPpvYjyKeBdiI=; b=dqAuVp/Md6dltU2+wWd9YmXmJl0gjR4sK5zDAvjpTsJSVJFEJFpBOpTEFPSYpZrDap FvgwvNzH7PYXXjZj0kRjjJYnHYbr40UVkpwOFFuDRfDDDHTwKOApy25cUst736JqiSEN 1pXb/1YwmZ1btxsaqDTInRVQlHzc3Smv65CFY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=qYE0MGzN5oZiWXIC6Rq6ejY3VVjgiXoPpvYjyKeBdiI=; b=QRBimzp8obSGYqqAwbsoxSzIvkzcWJvmHtUR3eYj2NUNyTR7ryodZxEYixxzv3BRX+ N0gibtlXA34aGqW8VtWEFlonbRnu0/AtQjC8hat3vRZep4BYCtRMnResyeTK8WrgEZX/ oKqlenSRqhBAvJ+49kyZy5uDPffmGDCXjoEI6/Ys8nnMpb0lnqZHEDDrKS70G4aruHXE +uw2xBy/5ogv+VKxXUylhwqZscKRfMCw84mrvMKJ4YPktcaexQj+V1TzSXrfdgh8zwCA oG5hw9VYzpwtKA0p04zi8S61gFtmeZdGtbHMrIQc8Ggo4SBIpvbk8UprEjicv4lFYmL1 EkJQ== X-Gm-Message-State: AOAM530q173s73AqXlGWK8QB98yVcCoeufM1w5DlYKt/GZQMys0kyHrb FUTnBjMPDxnZlkrXAy/mocyIAg== X-Google-Smtp-Source: ABdhPJzsRdZY8noRNZwAyszwwF9P9Y/ARLnpJW6z3ijXs5crRBCn6Voi+/JfVOJDz2petEtU+vf66w== X-Received: by 2002:a50:bf09:: with SMTP id f9mr133964edk.249.1594656932825; Mon, 13 Jul 2020 09:15:32 -0700 (PDT) Received: from localhost ([2620:10d:c093:400::5:ef88]) by smtp.gmail.com with ESMTPSA id n9sm12163985edr.46.2020.07.13.09.15.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2020 09:15:32 -0700 (PDT) Date: Mon, 13 Jul 2020 17:15:32 +0100 From: Chris Down To: Andrew Morton Cc: Hugh Dickins , Al Viro , Matthew Wilcox , Amir Goldstein , Jeff Layton , Johannes Weiner , Tejun Heo , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: [PATCH v6 0/2] tmpfs: inode: Reduce risk of inum overflow Message-ID: MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.14.5 (2020-06-23) X-Rspamd-Queue-Id: C69251804E95D X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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: In Facebook production we are seeing heavy i_ino wraparounds on tmpfs. On affected tiers, in excess of 10% of hosts show multiple files with different content and the same inode number, with some servers even having as many as 150 duplicated inode numbers with differing file content. This causes actual, tangible problems in production. For example, we have complaints from those working on remote caches that their application is reporting cache corruptions because it uses (device, inodenum) to establish the identity of a particular cache object, but because it's not unique any more, the application refuses to continue and reports cache corruption. Even worse, sometimes applications may not even detect the corruption but may continue anyway, causing phantom and hard to debug behaviour. In general, userspace applications expect that (device, inodenum) should be enough to be uniquely point to one inode, which seems fair enough. One might also need to check the generation, but in this case: 1. That's not currently exposed to userspace (ioctl(...FS_IOC_GETVERSION...) returns ENOTTY on tmpfs); 2. Even with generation, there shouldn't be two live inodes with the same inode number on one device. In order to mitigate this, we take a two-pronged approach: 1. Moving inum generation from being global to per-sb for tmpfs. This itself allows some reduction in i_ino churn. This works on both 64- and 32- bit machines. 2. Adding inode{64,32} for tmpfs. This fix is supported on machines with 64-bit ino_t only: we allow users to mount tmpfs with a new inode64 option that uses the full width of ino_t, or CONFIG_TMPFS_INODE64. You can see how this compares to previous related patches which didn't implement this per-superblock: - https://patchwork.kernel.org/patch/11254001/ - https://patchwork.kernel.org/patch/11023915/ Changes since v5 (it's been a while, eh?): - Implement percpu batching for SB_KERNMOUNT at Hugh's suggestion. - Hugh also pointed out that user-exposed tmpfs can also now have max_inodes == 0, so we have to account for that. I just use SB_KERNMOUNT to do that in all the places we used to look at max_inodes. Chris Down (2): tmpfs: Per-superblock i_ino support tmpfs: Support 64-bit inums per-sb Documentation/filesystems/tmpfs.rst | 11 +++ fs/Kconfig | 15 ++++ include/linux/fs.h | 15 ++++ include/linux/shmem_fs.h | 3 + mm/shmem.c | 127 ++++++++++++++++++++++++++-- 5 files changed, 166 insertions(+), 5 deletions(-)