From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 0BB2E5A90 for ; Wed, 18 May 2016 11:34:24 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id v200so25313458wmv.1 for ; Wed, 18 May 2016 02:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qIeourS2LLpIp1KlkMMy4UhFhxj1HlwpUTqv5XNUhmY=; b=I7lVkiRiwPEJMh8c5ShfyLku19r51RaeBsCOyVYbYvd5W7oDkwMzlDF1yokqz6NB9Z 5gMjl8GJ0Cbpldut/301s/llrkW9o+UUbnEAvNVGs6sbdeu/LDQmV3p/w/PneoOhSbXr wkAb2XCRe2l8SW2dBpNP6+Q/KiOCHhXpxOWkgXQGq5hwteWYeZ93CRGvv6O7P4Qr7rI8 11iI91WmKQMMywT9VGHvDKZ3xwNx+GjkcuUwthaeBEd/4Sv3zGCtCMw8C2vZBfbXAqme 5ApnzT7Qjda2FK4teTol/L5U8t6jeC814gaie6AvtdCfVW+ZSiCBvhD8mD9OU1koXkCY fneA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qIeourS2LLpIp1KlkMMy4UhFhxj1HlwpUTqv5XNUhmY=; b=E7T70TMFElJ0uyb1cuQBn4s19W4HKuZiW63Vpo5byMq6GNBiVtmuM+unMMH2gBhH9Z GzvbvmtFBK9qrzW3wQW0zMxik/lXjyzVXkLX7jUdZSwd4UeG9O2PngSRQVxnX2Tj8glB 9NfvrO1+khIMg5Rlk+yGZXCND9HoSZnLZiG5TsSBDhxJFs74jK9IsV3J3XoXyLpe59uv lHJ49t9FcwqyrkXBt1aQJqOzuouLBaTxj+Yz0lEwL+x+ktlaNPXuDhSNoXKsCwlDyMDg 2vaPGLZszxpjbjvbl8jGWA/80TPj6He438qwtXlCuYp866v59qTOqI56sQP1oLj7wkG/ lwSA== X-Gm-Message-State: AOPr4FXVvqDglZA7YzBkeS35U2hC0JLNEiaw4OBySduCarnq+JmRoBEaS84URlt2W0erUj0+ZmYAgFRRwPiuOcLg X-Received: by 10.28.133.10 with SMTP id h10mr28919155wmd.49.1463564063781; Wed, 18 May 2016 02:34:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.16.2 with HTTP; Wed, 18 May 2016 02:34:04 -0700 (PDT) In-Reply-To: <7e3e3aa7-4277-ac4f-433e-7d63c9eef78b@intel.com> References: <1457089092-4128-1-git-send-email-jianfeng.tan@intel.com> <1463013881-27985-1-git-send-email-jianfeng.tan@intel.com> <7e3e3aa7-4277-ac4f-433e-7d63c9eef78b@intel.com> From: David Marchand Date: Wed, 18 May 2016 11:34:04 +0200 Message-ID: To: Sergio Gonzalez Monroy Cc: Jianfeng Tan , "dev@dpdk.org" , Neil Horman Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH v4] eal: make hugetlb initialization more robust X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 09:34:24 -0000 Hello Sergio, On Wed, May 18, 2016 at 9:56 AM, Sergio Gonzalez Monroy wrote: > On 17/05/2016 17:39, David Marchand wrote: >>> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c >>> b/lib/librte_eal/linuxapp/eal/eal_memory.c >>> index 5b9132c..8c77010 100644 >>> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c >>> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c >>> @@ -417,12 +434,33 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl, >>> hugepg_tbl[i].final_va = virtaddr; >>> } >>> >>> + if (orig && internal_config.huge_trybest) { >>> + /* In linux, hugetlb limitations, like cgroup, >>> are >>> + * enforced at fault time instead of mmap(), even >>> + * with the option of MAP_POPULATE. Kernel will >>> send >>> + * a SIGBUS signal. To avoid to be killed, save >>> stack >>> + * environment here, if SIGBUS happens, we can >>> jump >>> + * back here. >>> + */ >>> + if (wrap_sigsetjmp()) { >>> + RTE_LOG(DEBUG, EAL, "SIGBUS: Cannot mmap >>> more " >>> + "hugepages of size %u MB\n", >>> + (unsigned)(hugepage_sz / >>> 0x100000)); >>> + munmap(virtaddr, hugepage_sz); >>> + close(fd); >>> + unlink(hugepg_tbl[i].filepath); >>> + return i; >>> + } >>> + *(int *)virtaddr = 0; >>> + } >>> + >>> + >>> /* set shared flock on the file. */ >>> if (flock(fd, LOCK_SH | LOCK_NB) == -1) { >>> - RTE_LOG(ERR, EAL, "%s(): Locking file failed:%s >>> \n", >>> + RTE_LOG(DEBUG, EAL, "%s(): Locking file failed:%s >>> \n", >>> __func__, strerror(errno)); >>> close(fd); >>> - return -1; >>> + return i; >>> } >>> >>> close(fd); >> >> Maybe I missed something, but we are writing into some hugepage before >> the flock has been called. >> Are we sure there is nobody else using this hugepage ? >> >> Especially, can't this cause trouble to a primary process running if >> we start the exact same primary process ? >> > > We lock the hugepage directory during eal_hugepage_info_init(), and we do > not unlock > until we have finished eal_memory_init. > > I think that takes care of that case. Yes, thanks. -- David Marchand