Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp325979imm; Tue, 15 May 2018 02:13:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpZwLMpzyIBv2iNl3wBbrpr5jSC/UIccje7BjhiEiqjLrgMRanL7fuAOu94z40ku8MIzlHI X-Received: by 2002:a17:902:8bcb:: with SMTP id r11-v6mr8788767plo.51.1526375593820; Tue, 15 May 2018 02:13:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526375593; cv=none; d=google.com; s=arc-20160816; b=uKnh/HTDAcklxNzEv0Ob/K1+tXLzWozaZzBqRYiFRkp6wLySdS57hOcAOn+fFBbe6+ vC+7vKNiZDRfCqreuMFlyoYPPnmgyzWfp1AM17Vy5+EpyLUtFs++ZPdO7wGU6qdZMfEr h+3TwXKaGEeFHoIfv5oKM6Cu5r0nH+v3oH4FKZ2/mAPde2Cqsrwkz6jSsmKV/IRs5CSc sdmKEU03/UkogH2aBadsQzUQfZpwwflEI0z/eYahXp7QyE3JNYgYB9pT4C7MmLg8Eome Bu54dPVy3ucwgXTrEIXOWDREkhbVASC1Vu5gaCLW/F0o2imca81OkyGoOXm+NMO5YFLe fuFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=J9TO+L/mDRmfMZU/KDqOPUeiNWpQui1VriJMNCMbrPM=; b=YcpD0ASaLpSEa5NztKkkkv5aZJDpMacVzySx2HCOycP4ygZUc7L8IvbM4am9hb3tHB TjWTictOqdFBarQma5gIVjG6A7j2eHtpCGcVmjLrLhboNAV/iz0VDBs5mmQN+fJoJTEO Udi1wX4RqIsYrWgEan1R9I2Jb4Gj43viDbty/a+kbGfjhbLyxx+k7Slx21ZwCOm4Gh6/ oekzX7u2387jYXCbiyv5yOB2ug52nxpZpyq4oq7NkECdPc6g8G0zgDvBA3/cQZb9HVYO UMceh5ut6bPlrXxvNHYn64cBBWDHfMjJZb3L4iPUKt13k+Qflv2tU8v6SQjXLhA+6lj3 x/0Q== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p7-v6si1190796pgv.170.2018.05.15.02.12.59; Tue, 15 May 2018 02:13:13 -0700 (PDT) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752701AbeEOJKo (ORCPT + 99 others); Tue, 15 May 2018 05:10:44 -0400 Received: from mx2.suse.de ([195.135.220.15]:53267 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570AbeEOJKn (ORCPT ); Tue, 15 May 2018 05:10:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 93CA7AE1B; Tue, 15 May 2018 09:10:41 +0000 (UTC) Date: Tue, 15 May 2018 11:10:36 +0200 From: Michal Hocko To: Pavel Tatashin Cc: Steven Sistare , Daniel Jordan , Andrew Morton , LKML , tglx@linutronix.de, Linux Memory Management List , mgorman@techsingularity.net, mingo@kernel.org, peterz@infradead.org, Steven Rostedt , Fengguang Wu , Dennis Zhou Subject: Re: [PATCH v2] mm: allow deferred page init for vmemmap only Message-ID: <20180515091036.GC12670@dhcp22.suse.cz> References: <20180510115356.31164-1-pasha.tatashin@oracle.com> <20180510123039.GF5325@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 11-05-18 10:17:55, Pavel Tatashin wrote: > > Thanks that helped me to see the problem. On the other hand isn't this a > > bit of an overkill? AFAICS this affects only NEED_PER_CPU_KM which is !SMP > > and DEFERRED_STRUCT_PAGE_INIT makes only very limited sense on UP, > > right? > > > Or do we have more such places? > > I do not know other places, but my worry is that trap_init() is arch > specific and we cannot guarantee that arches won't do virt to phys in > trap_init() in other places. Therefore, I think a proper fix is simply > allow DEFERRED_STRUCT_PAGE_INIT when it is safe to do virt to phys without > accessing struct pages, which is with SPARSEMEM_VMEMMAP. You are now disabling a potentially useful feature to SPARSEMEM users without having any evidence that they do suffer from the issue which is kinda sad. Especially when the only known offender is a UP pcp allocator implementation. I will not insist of course but it seems like your fix doesn't really prevent virt_to_page or other direct page access either. -- Michal Hocko SUSE Labs