Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp2809676imb; Mon, 4 Mar 2019 15:03:43 -0800 (PST) X-Google-Smtp-Source: APXvYqyYyt2gEVfOXamuRkcBWziSTBU3BBKuwryfYGn9giq7pX/ClQ1TLhW6O/Tiwze6lqjvVFZQ X-Received: by 2002:a63:470a:: with SMTP id u10mr21041407pga.17.1551740623835; Mon, 04 Mar 2019 15:03:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551740623; cv=none; d=google.com; s=arc-20160816; b=wIjq3TbhhDTEpWnUfnZpwb7wjJnNRgVvz5NM2hff+lFEKfIqVIdO022x/uE/1y5Iu2 NYwMakRtOtaklOALR9MD7R18XCmgxZT8fBMGjWMosSfezZH+pHzf3WuaSi+k2KyBBSGL bc1KsMmITBwkC0HOFcM9GXOuggx1Yhtcr25cXpk7iPeODCXE/NGMjC886izH23SfPlMU fr7Uj9jLyz+iB3aGWgBBl2aIScZYrxdp0S4BJ0JUJ8bwpNwjRDa88LO2bTIzaAL0ikvd JR5KN7C67rAcXrOStr3GrkjimUxKXO/fOVgrZTUIeY09eVc71vo2tTgU1nvIax9oIDvd G1NA== 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=R2N0tTdHE8P9jj+yhWjmz0+fRYMk6w9H1TrV1I9S4Fc=; b=F9DK28Js0CYrgzlvlPtOFWkFjtrGwfg47mof7Y4cAKEauTlQcdMhDupJYd9PAV99fm wMbTQ/46pnqSM7cTuInT1WBIu9Jj1s7/XQNsgdSMFB+n+osK2ioU7cwBduZPbwNptFw5 JEH1pfZINnSwO8g85WdXsAh1lHiqCv/TKXcmpGDTjAXblCoGs7+QCyGtb4UW4qZUxd+k IrzoS9/iX1MO70XXz6QBsVb7cpX+tWWwvBlSKrWf5XQq66MzgK1AfVx7cvummIPax5C7 izTlhXmzulAsdE1CKsbT4UbsP/J9BBXYMfnAgEYkRkc8OG8MH6xTjCeBA8UPk11ioJ0J aTRQ== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e20si6185074pfi.237.2019.03.04.15.03.26; Mon, 04 Mar 2019 15:03: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; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726656AbfCDXCu (ORCPT + 99 others); Mon, 4 Mar 2019 18:02:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54602 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726101AbfCDXCu (ORCPT ); Mon, 4 Mar 2019 18:02:50 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2CD17308404C; Mon, 4 Mar 2019 23:02:50 +0000 (UTC) Received: from localhost (unknown [10.18.25.174]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4596C5D6B3; Mon, 4 Mar 2019 23:02:47 +0000 (UTC) Date: Mon, 4 Mar 2019 18:02:46 -0500 From: Mike Snitzer To: Alexander Duyck Cc: linux-next@vger.kernel.org, LKML , dm-devel@redhat.com Subject: Re: x86 VM Boot hang with latest linux-next Message-ID: <20190304230246.GC20327@redhat.com> References: <20190303034847.GA8699@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 04 Mar 2019 23:02:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 03 2019 at 12:06pm -0500, Alexander Duyck wrote: > Thanks. The behavior of it has me wondering if we are looking at > something like an uninitialized data issue or something like that > since as I mentioned I don't see this occur on every boot, just on > most of them. So every now and then I can boot up the VM without any > issues, but most of the time it will boot and then get stuck waiting > on jobs that take forever. The commit in question (1efa3bb79d3 "dm: must allocate dm_noclone for stacked noclone devices") conditionally allocates the 'struct dm_noclone' and I can only infer that the change is causing a negative side-effect in virtualized environments (both x86_64 and s390). I haven't been able to reproduce on x86_64 kvm with virtio-scsi on fedora 25 though. Will try fedora 29 shortly, and also try virtio-blk. Could you please provide your guest's .config (even if just off-list)? Also, what kernel are you running on the host? Thanks, Mike