Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2422460imj; Mon, 18 Feb 2019 05:50:27 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia+EI18b2lVfaJtyDMqreucFznn0N3o0UOE7oITC5Ip6NzA/U7Gm1T+mgfBjT6NZY5bd+R8 X-Received: by 2002:a63:788a:: with SMTP id t132mr12397433pgc.0.1550497827645; Mon, 18 Feb 2019 05:50:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550497827; cv=none; d=google.com; s=arc-20160816; b=e5RkGTBlHw5ULxe6HHUFA5/zOAPi4Gu5qLVdza6Yl0XEMGlZHET1pHBXr0YoPm00Cy tw7ZvJAl4QuJhxwE7ZD7tEDy1Lpb/fR1nqUxTg/oYmgjHDdTzBXrHKSIzfcRMPNIEF3W neglYsGfkHmdppsFaYyJ/71y1p5spyEFPx5b6ytoHnZeHHxGfkco5ZkxpRdfFKdS8Zkq sz1R5+sWGkF9uHSy/w43Z6msCf3yaCD0InxQfM4dhyMj1MfQiShYHTQVwXySyQ1k/GUV MK1UK6f4Hg6K6yGVTfvSU/81f8TtAwHvAJnzgGBpuOneiqBOUZwtWSBUquaZI1NM32Yn AMcA== 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; bh=AmtIYxHGO95oC80/w/8i8Vgy1OhQOA9y359cVv2MQCs=; b=tD4dtnKdKNfEajwrV/CoXsqn4IVXSTfCDxtntwTQI6bP0HNpec9iDpp09d4gn7yJIo aVTeVljexHA/1tNLKlCGAsfMyqyYh9YWbP4sLFCeEferExFobGbW5nDLohXuiyc+NezF ZOQ7bmCVpPCfDrjIUfHl4uILfmcnakwsjD35hY8UKvc42ZauAciS/iCu0EmOX9sSC+sk z35+eow9b4TjSJe8ZO9uGcAxFzjhk388CmeO3U0QzMl30umXKMb592eTboM4FEpdF51j 8i/w1Iyngc4N/AqLoiVVGcXfaqtas8P3lGg8gyjbFvqr+nEjnxJV9+LSqsQCcIiRemms COHQ== 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 4si13865295pfg.280.2019.02.18.05.50.12; Mon, 18 Feb 2019 05:50:27 -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; 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 S1731614AbfBRNuG (ORCPT + 99 others); Mon, 18 Feb 2019 08:50:06 -0500 Received: from mx2.suse.de ([195.135.220.15]:46130 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731440AbfBRNuE (ORCPT ); Mon, 18 Feb 2019 08:50:04 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 63490B015; Mon, 18 Feb 2019 13:50:03 +0000 (UTC) Date: Mon, 18 Feb 2019 14:50:02 +0100 From: Michal Hocko To: Lars Persson Cc: Jan Stancek , linux-mm@kvack.org, lersek@redhat.com, alex williamson , aarcange@redhat.com, rientjes@google.com, kirill@shutemov.name, mgorman@techsingularity.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP Message-ID: <20190218135002.GR4525@dhcp22.suse.cz> References: <997509746.100933786.1549350874925.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 18-02-19 14:43:58, Lars Persson wrote: > On Tue, Feb 5, 2019 at 8:14 AM Jan Stancek wrote: > > Hi, > > > > are you using THP (CONFIG_TRANSPARENT_HUGEPAGE)? > > > > The changed line should affect only THP and normal compound pages, > > so a test with THP disabled might be interesting. > > > > > > > > The breakage consists of random processes dying with SIGILL or SIGSEGV > > > when we stress test the system with high memory pressure and explicit > > > memory compaction requested through /proc/sys/vm/compact_memory. > > > Reverting this patch fixes the crashes. > > > > > > We can put some effort on debugging if there are no obvious > > > explanations for this. Keep in mind that this is 32-bit system with > > > HIGHMEM. > > > > Nothing obvious that I can see. I've been trying to reproduce on > > 32-bit x86 Fedora with no luck so far. > > > > Hi > > Thanks for looking in to it. After some deep dive in MM code, I think > it is safe to say this patch was innocent. > > All traces studied so far points to a missing cache coherency call in > mm/migrate.c:migrate_page that is needed only for those evil MIPSes > that lack I/D cache coherency. I will send a write-up to linux-mips > about this. Basically for a non-mapped page it does only a copy of > page data and metadata but no flush_dcache_page() call will be done. > This races with subsequent use of the page. Please make sure to cc linux-mm for the patch -- Michal Hocko SUSE Labs