From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0D878A0577; Wed, 15 Apr 2020 10:11:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CD8111D451; Wed, 15 Apr 2020 10:11:17 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 4EBE41D44E for ; Wed, 15 Apr 2020 10:11:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586938275; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Z6tz+rZ1RUeNMnGa351QlXwGBbSAwDzzPdEI+SVKXA4=; b=W97fiAR8rB0TozSPHBUXFwM8H7w6XSyfrYhKWTKOPfoI4JcSgo3ysk39EB0ZkLgsLsOnEI s9r6BtRejifV2MYFwfpNFdA+buc3LHV5RncHEvT8iiAXl+MoZbpG24WUj6+hhl6WOz+glc SpogjnQk2BdDgA168er1cFf3MwVgBMI= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-260-8JPqVkZVMB2z4MklOXdaTQ-1; Wed, 15 Apr 2020 04:11:12 -0400 X-MC-Unique: 8JPqVkZVMB2z4MklOXdaTQ-1 Received: by mail-ua1-f71.google.com with SMTP id l9so1456599uao.12 for ; Wed, 15 Apr 2020 01:11:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z6tz+rZ1RUeNMnGa351QlXwGBbSAwDzzPdEI+SVKXA4=; b=X2eZh2Egw2OxEIKgopuj0PZjln1bzPHvmSpLSm5B0DCXHthsGM5cY8yxUFKs5W107s p2gqA9pBaHzY8QLnJyxoHjJOXaV5b4NiUdio+9KsxR5EULT9AzuEs628t0kMekkMxyzC IZo+36+4DNUDQCb59sVVplWkYvkSzZ+55O3D8BdAV/JS/egeeY0YhpNjJE5MXi5fgEmR +fiMsPn0zlKSN9atsWsiufjNqlQWWwF8e8H0IN2KbGanv598mSTY3YAPReRDWG8dMRvQ yS4PHHBbl6kT2IY9sBCDzh7/IAak/Il3u3QO1dylp0lUSFHFoWVscqUk6TH4e3VcWPcn C+BA== X-Gm-Message-State: AGi0PuYLFZuESl09HhCZksgi2eJfC0HmWO6nHIh+0K+YWVoGIuhl7sXa sBWO+ExBEmxPd23Eq8YBUnykLo7A3uceuN45r0cGsjfWlB8g5u8sQhtwBoMk3i8ltNAkDqTCtQV OU5jltjsmReW1EZhRvog= X-Received: by 2002:a9f:2c87:: with SMTP id w7mr3516088uaj.41.1586938271762; Wed, 15 Apr 2020 01:11:11 -0700 (PDT) X-Google-Smtp-Source: APiQypJPCvuDIIYQqntPhCfZDszXZpr+KBf9RCyVZD5wKImmIMvLmkcsbw1Bx7jOyGSEfm8A2UjcHf/JPqwbcuUOZ3s= X-Received: by 2002:a9f:2c87:: with SMTP id w7mr3516068uaj.41.1586938271356; Wed, 15 Apr 2020 01:11:11 -0700 (PDT) MIME-Version: 1.0 References: <1586680073-11075-1-git-send-email-xiangxia.m.yue@gmail.com> <20200413210658.2308b86e@hermes.lan> In-Reply-To: From: David Marchand Date: Wed, 15 Apr 2020 10:10:59 +0200 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Tonghao Zhang Cc: Stephen Hemminger , dpdk-dev , "stable@dpdk.org" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH dpdk-dev] rte_random: fix crash when random init X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Apr 15, 2020 at 8:01 AM Mattias R=C3=B6nnblom wrote: > > On 2020-04-15 01:42, Tonghao Zhang wrote: > > On Tue, Apr 14, 2020 at 11:37 PM Mattias R=C3=B6nnblom > > wrote: > >> On 2020-04-14 15:35, David Marchand wrote: > >>> On Tue, Apr 14, 2020 at 3:20 PM Mattias R=C3=B6nnblom > >>> wrote: > >>>> On 2020-04-14 06:43, Tonghao Zhang wrote: > >>>>> On Tue, Apr 14, 2020 at 12:07 PM Stephen Hemminger > >>>>> wrote: > >>>>>> On Sun, 12 Apr 2020 16:27:53 +0800 > >>>>>> xiangxia.m.yue@gmail.com wrote: > >>>>>> > >>>>>>> From: Tonghao Zhang > >>>>>>> > >>>>>>> When rte_rand_init is invoked, and the kernel > >>>>>>> (kernel version < 3.17) running dpdk does't support > >>>>>>> *getentropy, at the same time, the cpu does't support > >>>>>>> rdseed, the rte_rand_init will invoke rte_get_timer_cycles > >>>>>>> which function will invoke rte_get_hpet_cycles > >>>>>>> (RTE_LIBEAL_USE_HPET was enabled) while *eal_hpet is not > >>>>>>> allocated. > >>>>>>> > >>>>>>> Fixes: faf8fd252785 ("eal: improve entropy for initial PRNG seed"= ) > >>>>>>> Fixes: 3f002f069612 ("eal: replace libc-based random generation w= ith LFSR") > >>>>>>> > >>>>>>> Cc: stable@dpdk.org > >>>>>>> > >>>>>>> Signed-off-by: Tonghao Zhang > >>>>>> Are you sure this patch won't change current default to use HPET (= which is slower)? > >>>>> In rte_eal_timer_init (linux/eal_timer.c)=EF=BC=8C it will set > >>>>> eal_timer_source =3D EAL_TIMER_TSC too. > >>>>> So after rte_eal_init, eal_timer_source =3D=3D EAL_TIMER_TSC which = is the > >>>>> default timer source actually. > >>>>> Then this patch will affect RTE_INIT function which invoke > >>>>> rte_get_timer_cycles. but hpet is not available yet. > >>>> Would using rte_rdtsc() directly be an option? > >>> s/rte_rdtsc/rte_get_tsc_cycles/ > >>> > >>> This could work, but I am a bit surprised to see an initialisation in > >>> a constructor. > >>> The commitlog that moved rte_srand() from rte_eal_init does not > >>> explain why it was moved. > >>> > >>> > >> The initialization (i.e. automatic seeding) grew in complexity somewha= t, > >> and with the new rte_random.c file, it felt like it would have a good, > >> new home. > >> > >> > >> That said, maybe it would have been better to add an initialization > >> function to the rte_random.h API, and have it called from > >> rte_eal_init(), to avoid the ordering issues with constructors. > > If we use that solution we can register a callback which invoked when > > almost resources are available: > > http://patches.dpdk.org/patch/68313/ > > > We might then instead have a new ordering issue, if we wait too long > with rte_random initialization, since other initialization code might > well use rte_rand(). It seems like the memory heap expansion code does > currently. rte_rand() is a pretty basic function, that should be safe to > call early during initialization, I think. > > > I would suggest first switching to rte_get_tsc_cycles() and later > potentially change to explicit (i.e. non-constructor), early, rte_random > initialization. Switching to rte_get_tsc_cycles seems fine to me. Who will send the fix? --=20 David Marchand