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 X-Spam-Level: X-Spam-Status: No, score=-17.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CFF6C433DB for ; Thu, 4 Mar 2021 10:28:45 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B6BA264F2B for ; Thu, 4 Mar 2021 10:28:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6BA264F2B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.93090.175730 (Exim 4.92) (envelope-from ) id 1lHlDX-0004qe-Jy; Thu, 04 Mar 2021 10:28:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 93090.175730; Thu, 04 Mar 2021 10:28:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lHlDX-0004qX-H1; Thu, 04 Mar 2021 10:28:27 +0000 Received: by outflank-mailman (input) for mailman id 93090; Thu, 04 Mar 2021 10:28:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lHlDV-0004qS-Uh for xen-devel@lists.xenproject.org; Thu, 04 Mar 2021 10:28:25 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lHlDV-0000QQ-FT; Thu, 04 Mar 2021 10:28:25 +0000 Received: from 54-240-197-236.amazon.com ([54.240.197.236] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lHlDV-00086q-6b; Thu, 04 Mar 2021 10:28:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=mNlFm4VQb0yj1aHmxWN+nnGSg9MTFU5612d/9trK7yo=; b=r8ytQ6KB26mfbhMRxY1vY824jH 04nT3B4/wAugiVlmyIOocsSVYArRfLZIsiE71dSk8ujZIcvPWA33o2go5AxwyHC/SrAeKEp9btRcM Gcrh5J6SY8ErIskn1nQqkstJobqcO+dZhlLD/PWZXIHk9axA3EoeQD5djpvO1PH+afq4=; Subject: Re: dom0less boot two compressed kernel images out-of-memory work-around To: Jan Beulich Cc: Stefano Stabellini , Ian Jackson , Andrew Cooper , Charles Chiou , "xen-devel@lists.xenproject.org" References: <58aaf68f-4499-9400-6eb2-f1ad3b620c73@xen.org> <511603c8-40b4-5e22-7eba-7722d89895fe@suse.com> From: Julien Grall Message-ID: Date: Thu, 4 Mar 2021 10:28:23 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <511603c8-40b4-5e22-7eba-7722d89895fe@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Hi Jan, On 04/03/2021 08:34, Jan Beulich wrote: > On 03.03.2021 20:36, Julien Grall wrote: >> (BCCing xen-users, CCing xen-devel + a few folks) >> How about the following (untested): >> >> commit e1cd2d85234c8d0aa62ad32c824a5568a57be930 (HEAD -> dev) >> Author: Julien Grall >> Date: Wed Mar 3 19:27:56 2021 +0000 >> >> xen/gunzip: Allow perform_gunzip() to be called multiple times >> >> Currently perform_gunzip() can only be called once because the the >> internal allocator is not fully re-initialized. >> >> This works fine if you are only booting dom0. But this will break when >> booting multiple using the dom0less that uses compressed kernel images. >> >> This can be resolved by re-initializing malloc_ptr and malloc_count >> every time perform_gunzip() is called. >> >> Note the latter is only re-initialized for hardening purpose as >> there is >> no guarantee that every malloc() are followed by free() (It should in >> theory!). >> >> Take the opportunity to check the return of alloc_heap_pages() to >> return >> an error rather than dereferencing a NULL pointer later on failure. >> >> Reported-by: Charles Chiou >> Signed-off-by: Julien Grall >> >> --- >> >> This patch is candidate for Xen 4.15. Without this patch, it will >> not be >> possible to boot multiple domain using dom0less when they are using >> compressed kernel images. > > Other decompression methods are unaffected? Arm is only using gzip so far. I quickly looked through bunzip2 and unlz4 (I know there are others), they look fine because they don't allocate a large global pool. We probably want to check the others. > >> --- a/xen/common/gunzip.c >> +++ b/xen/common/gunzip.c >> @@ -114,7 +114,11 @@ __init int perform_gunzip(char *output, char >> *image, unsigned long image_len) >> window = (unsigned char *)output; >> >> free_mem_ptr = (unsigned long)alloc_xenheap_pages(HEAPORDER, 0); >> + if ( !free_mem_ptr ) >> + return -ENOMEM; >> + >> free_mem_end_ptr = free_mem_ptr + (PAGE_SIZE << HEAPORDER); >> + init_allocator(); >> >> inbuf = (unsigned char *)image; >> insize = image_len; >> diff --git a/xen/common/inflate.c b/xen/common/inflate.c >> index f99c985d6135..d8c28a3e9593 100644 >> --- a/xen/common/inflate.c >> +++ b/xen/common/inflate.c >> @@ -238,6 +238,12 @@ STATIC const ush mask_bits[] = { >> static unsigned long INITDATA malloc_ptr; >> static int INITDATA malloc_count; >> >> +static void init_allocator(void) > > Please add INIT here. (I wouldn't mind if you used __init instead, > as there's going to be file-wide replacement after 4.15 anyway, > but of course this would render things inconsistent until then.) I will use INIT. I will wait a bit before sending the patch formally (I'd like a confirmation that it solves the problem reported). Cheers, -- Julien Grall