Received: by 10.223.185.116 with SMTP id b49csp715187wrg; Sat, 10 Feb 2018 17:54:44 -0800 (PST) X-Google-Smtp-Source: AH8x225Yj6T9P+hXa38RuTFiK4b0VMBg2btgjzPobSDQvlBt3X5qGypguJzE2nT4c331Sq3lO3ws X-Received: by 10.98.139.196 with SMTP id e65mr7512912pfl.128.1518314083937; Sat, 10 Feb 2018 17:54:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518314083; cv=none; d=google.com; s=arc-20160816; b=dRUvQZ966lPuLpRWsULeMx7zQyp8dR5vlgHPE+xpLFsFtOkr8fKtMSwaLZapdlXGDZ TMvM+33/HVDPajV9NFy1ElIH2gYgVXGFTnUUY7352l/uTPB7vfpikbbt81sC8+tULfSF FUUSnp4TvXNQYq64tBCQF/pIGNLzcJeLX7faY0FzzoXqiNT9IHWyGtfOSfuUN5vxJu9i V0iuDN/v/9uZ8NQKOKSjnpfEaEAcnhHNel4tnLLU6X3TNdBOSQVXN/I2IdLOMweujLSm iXo+9J+sFmGxx9L+4AqzO1Z4X/qcP9Ar1row6ZA60KsqKV+4HKdfuE2+69WzWTZsUCCR vEag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:subject :from:to:dkim-signature:arc-authentication-results; bh=66f0CGirwT8U1YN6hcGChQBT6sFg8pORIZI/szpSLFM=; b=e/IoveYPHeskkcnwCudiOH0DaTlRy4PaHoH+Pb4vu5QZHbkv7x2DniP13YBEpK53QK gV9JQ/8cCB3dV8upc0YeMFrwqjTW7Aqg3Oc0BD+Uekw9eDJyfW6MYxXM1fqt3vE1u2NO AHK2gL0fMBJn0tvHeuj1F/+22fGIMfgIv+cc36jQ+vQjSylKymJr2yn2kIfUZhz85MYh XzMGALOdUtYdSG4fIKTwBZkqLcZsnpcciRJvo26acEcO87z+CU9MX1KRHUNS9zj3Jsi3 PT9siyLHw09IqBhxAIfRGit4Cgr4lALQ/eJp0WgMXwk8SAn/BHhdjMDUzmkjGJqnnwBn N9wQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@landley-net.20150623.gappssmtp.com header.s=20150623 header.b=jKvzZus+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q11-v6si1988124pli.790.2018.02.10.17.54.29; Sat, 10 Feb 2018 17:54:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@landley-net.20150623.gappssmtp.com header.s=20150623 header.b=jKvzZus+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbeBKBxm (ORCPT + 99 others); Sat, 10 Feb 2018 20:53:42 -0500 Received: from mail-it0-f46.google.com ([209.85.214.46]:36156 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057AbeBKBxl (ORCPT ); Sat, 10 Feb 2018 20:53:41 -0500 Received: by mail-it0-f46.google.com with SMTP id n206so2794536itg.1 for ; Sat, 10 Feb 2018 17:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=66f0CGirwT8U1YN6hcGChQBT6sFg8pORIZI/szpSLFM=; b=jKvzZus+eqi4eteIym5O0WjIhLgtY5JUxnxBYPkGCgtKEiV23Kd0CyIdnNb1AemkA4 ca3zGOOg9d0fliGoeg307AYL1YVl9pSLPhGzIO3LqXT6tmgAAdKaqqk/8m4kLaPuovOf rmK3lqWjY3sI5Q/V91TK+2BntZHC23YyCnUPyGJ2hbmHra+XCI0KVTfwD5AIeEu4G/BP +q9OAPSEqCYTiC8013c/9RnKK2EXI+aKuDVlxysHEQdubjg7tvVKJ60wSaiAHCPYhkJZ X1smXFkyXmLdCK6JlIziDDxyUgC0DweekVVwbOjEKDvTbHe9dDQ1OTC9MIwyDuJFWs1d tIvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=66f0CGirwT8U1YN6hcGChQBT6sFg8pORIZI/szpSLFM=; b=n/Lrd/HoJQRFdJww+82tT4sVyand5nd9lL57qo1Fcy2dKJP8eNsljEkHI7qWoREkFK LPWgaIG2IgV1i3NHCkcmOZJv/8AjoL8LqPWBwqDCA7k1bjCHb3EM3SSRTlMjoGQLBpaj 3k/AXfYafLaXuJ3OWTgM0cU7L4sRffOQ40oDvtblP/cCvJJiadndVrWH1gefFdGE/pKE mpIMsle/eAnyy7vVjyBI4Kx+z2C83VrRpyqdyZ1qk34UotbQQPCIH2dYY2Jt924CkcqK nu04iFIe0yKmH/sHHK9mSwyurbscRP6Oe97JxaN7WFdSb5GjlVw0zc0Q6k2EkeVygbRN mOHA== X-Gm-Message-State: APf1xPDTQAkL7Ma5Kwq5L2UQdKbUFZ0BAeQ8iSN/xVqHXW2GpB+4nqTK 3FVsLoPrExCySyQr2l5teNzXEGZUQ2s= X-Received: by 10.36.6.129 with SMTP id 123mr475815itv.33.1518314020421; Sat, 10 Feb 2018 17:53:40 -0800 (PST) Received: from [192.168.5.232] (ip-64-134-170-150.public.wayport.net. [64.134.170.150]) by smtp.googlemail.com with ESMTPSA id g186sm3528933itg.2.2018.02.10.17.53.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Feb 2018 17:53:40 -0800 (PST) To: linux-kernel@vger.kernel.org From: Rob Landley Subject: tmpfs and brickability (size=50% default considered naieve). Message-ID: <89293703-6e19-f6b6-a0d4-dc3ca90785ed@landley.net> Date: Sat, 10 Feb 2018 19:53:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If you have two default tmpfs instances on your box (hi buildroot!) and they're world writeable and a normal user goes "cat /dev/zero > /run/fillit; cat /dev/zero > /tmp/fillit" the system then goes "sh: can't fork" trying to call rm on those files, because they each default to 50% of total system memory, no matter how many instances there are. It only stops writing when memory allocation fails in the kernel. I'm not quite sure how to fix that. I want to say "change the default to be 50% of what's _left_" (and if you size= manually you get to keep the pieces) but define "what's left"? Other things are using some memory already, the 50% _was_ the amount it's safe for tmpfs to use. (Once upon a time the logic was that 50% of memory can go to disk cache. I think that's gotten a bit more complicated since then? No idea what the current rules are.) This is related to the guy who wanted initramfs to be ramfs instead of tmpfs because he had a cpio.gz that extracted to >50% of system memory so it extracted fine with ramfs but hit the limit and failed with tmpfs. That sounds like a tmpfs rootfs (I.E. initmpfs) should start with a limit of 90% and then scale it _down_ to 50% after extracting the cpio. (I wonder what happens if you -o remount the size= limit to smaller than the filesystem currently holds? Hmmm...) Rob P.S. Yes I need to pipe rootflags= through so you can specify the size on the command line. I've got 3 or 4 initramfs/tmpfs plates spinning and haven't had a chance to work on them all merge window. I'll try to get some patches ready by next weekend, if they miss the release they miss the release...