From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <ak@linux.intel.com>
Received: from mga14.intel.com ([192.55.52.115])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <ak@linux.intel.com>)
	id 1fEbQg-0005Dh-I6
	for speck@linutronix.de; Fri, 04 May 2018 16:11:23 +0200
Date: Fri, 4 May 2018 07:11:20 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: [PATCH 7/8] L1TFv3 5
Message-ID: <20180504141120.GD75137@tassilo.jf.intel.com>
References: <cover.1525403858.git.ak@linux.intel.com>
 <9422c9bcd3e664ce0f3a5eeadd45fa9127e0b5ba.1525403858.git.ak@linux.intel.com>
 <20180504134300.GU4535@dhcp22.suse.cz>
MIME-Version: 1.0
In-Reply-To: <20180504134300.GU4535@dhcp22.suse.cz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

> still applies. Just in case the previous post got lost in the noise I
> repeat that I would prefer if we issued pr_want about truncated swap
> file. It is quite a stretch to expect such a large swap storage but
> let's keep users aware of the fact just in case.

The warning is already there in swapfile.c

        last_page = swap_header->info.last_page;
        if (last_page > maxpages) {
                pr_warn("Truncating oversized swap area, only using %luk out of %luk\n",
                        maxpages << (PAGE_SHIFT - 10),
                        last_page << (PAGE_SHIFT - 10));
        }

-Andi