Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp164758imu; Thu, 24 Jan 2019 23:38:11 -0800 (PST) X-Google-Smtp-Source: ALg8bN7OLCXlLEdlLh0jtbKfxEQ/ltykswpejeShT5vuzbeIB240emXntIQMgrftPC5QPVp7dHQN X-Received: by 2002:a62:8e19:: with SMTP id k25mr9828533pfe.185.1548401891740; Thu, 24 Jan 2019 23:38:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548401891; cv=none; d=google.com; s=arc-20160816; b=CTEL2MjFaDMygCFWIUJ52u6AvlxRo1R7ZfpKtzVeVPCnJYb87VGbcgOCYgwA7pup5L 1bORlvMyQGcq+FX+12nbr/NKnacWpEZ+aJ3Ec+dNQqkc9lFhCoUDR5SBR0jgYBngw9wZ 8I2+kD1CKcs8+tc0/G46D217QwNbjB0hkE8we9ucL8oB9cOtxgiDAbVNH2PGjJIXM0ix QYK1mDZtwEDDw8U0b3OYfN8W4OPMmmp2kuUj6Om/WQ2MNww12wJenU7zjUOIs6YzFkS2 DsjZ4JyTZ2VcENPee6ip4r039lRIz2vzSz+OJy9wsFa3uU+5rojhT8l88psHKyP+OupZ ko0w== 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=CfaNYwF3gyR0uKPQj1xqVTZmLSRVJ5AUHdguoxfFOxM=; b=IpBB946QTfK1x8kcQ4mtEMGEfXKNXnpQZt44lKNMLfvuRdHh2RfgtNkTSZz/ntx1eb 5Kwjik5+JnIUAoBRVP4aO9ZnZJX4RHt2ehZBUwTgQX1GFH1+Ex7zh27f0loA3H6+fwEd E4V06nEopjmiSpn34TWXQ+bNuzYfxDU1Nfu/A1l9aLGXzdHPv8TxorR0rBBNg7DrvNvH Yay2ziqS2S9w4yl9PCCXfC/AhCr9FZ5YcCr/d/seVMTlozWocI0otBVD1plxj2GTj1Z0 gy57YHJZcU8cGGjl467oW/iPqJX43+XlpR8Azs/wV3CmJq0Gy5g9bNM1LQfr2JsuDoCx 2dpw== 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 p3si9898748plk.424.2019.01.24.23.37.56; Thu, 24 Jan 2019 23:38:11 -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 S1727967AbfAYHhH (ORCPT + 99 others); Fri, 25 Jan 2019 02:37:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:42808 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726271AbfAYHhH (ORCPT ); Fri, 25 Jan 2019 02:37:07 -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 E4689ACD2; Fri, 25 Jan 2019 07:37:05 +0000 (UTC) Date: Fri, 25 Jan 2019 08:37:04 +0100 From: Michal Hocko To: Linus Torvalds Cc: robert shteynfeld , Mikhail Zaslonko , Linux List Kernel Mailing , Gerald Schaefer , Mikhail Gavrilov , Dave Hansen , Alexander Duyck , Andrew Morton , Pavel Tatashin , Steven Sistare , Daniel Jordan , Bob Picco Subject: Re: kernel panic due to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2830bf6f05fb3e05bc4743274b806c821807a684 Message-ID: <20190125073704.GC3560@dhcp22.suse.cz> References: 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 Fri 25-01-19 17:48:32, Linus Torvalds wrote: > [ Just adding a lot of other people to the cc ] > > Robert, could you add a dmesg of a successful boot to that bugzilla, > or just as an attachement in email to this group of people.. > > This looks to be with the Fedora kernel config. Two people reporting > it, it looks like similar machines. > > I assume it's some odd memory sizing detail that happens to trigger a > particular case. Quite possible. > I absolutely *hate* those "let's lazily clear 'struct page' array" > patches. They've caused problems before, and I'm not convinced the > pain has been worth it. Maybe we should revert them (again) and > promise to never ever take things like that again? Andrew? The performance numbers were pretty dramatic on the other hand. This was especially seen for very large NVDIMMs initialization when a userspace was timing out without these applied. I am certainly not very happy about regressions which we still do see. I was worried about that early when reviewing these patches because it is really hard to find all those weird places which simply happened to work even when broken before. E.g. unitialized struct pages were simply with zeroed and that means that they seemed to belong to node zero and zone DMA and nothing really blown up. With the poisoning in place we have an explicit VM_BUG_ON and Fedora kernels do enable VM debugging so those problems are visible. I still think we should chase after those issue and fix them regardless. Lazy initialization revert will not solve those problems. It will just paper over them. -- Michal Hocko SUSE Labs