From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2] helo=sipsolutions.net) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n4pnz-00CfC8-3h for linux-um@lists.infradead.org; Tue, 04 Jan 2022 19:49:12 +0000 Message-ID: <41fe09354fc736fb1ff2cb429e035633f24176ce.camel@sipsolutions.net> Subject: Re: Occasional hung with UM after enable VMAP_STACK From: Johannes Berg Date: Tue, 04 Jan 2022 20:49:05 +0100 In-Reply-To: <8c26a869-0cbe-a38c-8a8d-9f3f171f7e72@collabora.com> References: <8c26a869-0cbe-a38c-8a8d-9f3f171f7e72@collabora.com> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Walter Lozano , linux-um@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Sjoerd Simons , ritesh sarraf On Tue, 2022-01-04 at 16:26 -0300, Walter Lozano wrote: > > Thank you for your quick response. The Debian configuration on package > user-mode-linux have these settings > > CONFIG_HAVE_ARCH_VMAP_STACK=y > CONFIG_VMAP_STACK=y OK, so it actually _is_ enabled. > as you can see in [1]. I did run some tests disabling those settings, > which passed without any hung. > > Unfortunately the "occasional" behavior makes this issue a bit tricky to > debug. > Right. Hm. I've been running our tests with it for about three months and haven't observed any hangs, but I guess that doesn't mean much. To be honest, I have no particular reason to even want it, other than that it catches accidental DMA from stack more easily ... so I guess if we can't find anything, we might as well revert it. Feels like it _should_ work though, since it's just a different location for the stack. johannes _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7013C433F5 for ; Tue, 4 Jan 2022 19:49:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231175AbiADTtM (ORCPT ); Tue, 4 Jan 2022 14:49:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229821AbiADTtL (ORCPT ); Tue, 4 Jan 2022 14:49:11 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A841C061761 for ; Tue, 4 Jan 2022 11:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=Xt8XKfsUO3oqWyKUpvE4fUY2NxxfQmItdYwYbgqL7Q4=; t=1641325751; x=1642535351; b=of3Ms5z9NAMeeG38c2+eIRZCAqYXbyWdB0c0CrjtaPm7kzP HVRm+puzgAURhCG0woTq+8o0C1HFGcGfcHsgFxQXbq9jfoiqKGwadaIZXWhdmBvhcFvxShc6xQ8Lk ytcVGW6Hq024OS9F1sLxTeCkdwOV2kcsfUVvilwYGBjccRXdGLZcMUiHKFqpucEggyq+kIE+sHwpc 3c4tY8fUPU5VWfyPaWhjukRUHczFrqYHEvR5Ju2tRu0Lqi4FyopdnWY94jUofoNObS9iNGnoX0g43 aEP8gE2zLsIkS/Cx7qSFDJtAj2hkeGpJuY/2Iz3VhvAQ/lBmKX8nAQiJQmj/Osag==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1n4pnu-001rmy-Oq; Tue, 04 Jan 2022 20:49:06 +0100 Message-ID: <41fe09354fc736fb1ff2cb429e035633f24176ce.camel@sipsolutions.net> Subject: Re: Occasional hung with UM after enable VMAP_STACK From: Johannes Berg To: Walter Lozano , linux-um@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Sjoerd Simons , ritesh sarraf Date: Tue, 04 Jan 2022 20:49:05 +0100 In-Reply-To: <8c26a869-0cbe-a38c-8a8d-9f3f171f7e72@collabora.com> References: <8c26a869-0cbe-a38c-8a8d-9f3f171f7e72@collabora.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.2 (3.42.2-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2022-01-04 at 16:26 -0300, Walter Lozano wrote: > > Thank you for your quick response. The Debian configuration on package > user-mode-linux have these settings > > CONFIG_HAVE_ARCH_VMAP_STACK=y > CONFIG_VMAP_STACK=y OK, so it actually _is_ enabled. > as you can see in [1]. I did run some tests disabling those settings, > which passed without any hung. > > Unfortunately the "occasional" behavior makes this issue a bit tricky to > debug. > Right. Hm. I've been running our tests with it for about three months and haven't observed any hangs, but I guess that doesn't mean much. To be honest, I have no particular reason to even want it, other than that it catches accidental DMA from stack more easily ... so I guess if we can't find anything, we might as well revert it. Feels like it _should_ work though, since it's just a different location for the stack. johannes