From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from compass.polito.it (compass.polito.it [130.192.55.110]) by dpdk.org (Postfix) with ESMTP id 1D1D52BCD for ; Wed, 30 Mar 2016 11:13:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id DF5E3100114 for ; Wed, 30 Mar 2016 11:13:16 +0200 (CEST) Authentication-Results: compass.polito.it (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=studenti.polito.it DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= studenti.polito.it; h=content-type:content-type:cc:to:from:from :subject:subject:message-id:date:date:references:in-reply-to :received:mime-version:received:received:received; s=y2k10; t= 1459329195; bh=lhQIIsJA6Yx8bRsoRzDHIxAWX2X5uNURZdl7ctkvgTQ=; b=h jzDf4UIzee+1Wr5qqUwy9jrBzIAG6nSpvGI7BkuTkp1gniJ3A6fkS3NjiM5yiTn3 HF/OnVZ9qrGW32yW3M8nkng7p4VEVevmCvsyBMLfx6SY5HhKY5NeP3+GhAoYhTX6 G924/HVZAHxLNgzh3xjEUCE1wkXiUHj/LJJUv3O17g= X-Virus-Scanned: amavisd-new at studenti.polito.it X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-100 required=3.5 tests=[ALL_TRUSTED=-5, AWL=0.636, BAYES_00=-1.5, HTML_MESSAGE=0.001] autolearn=ham Received: from compass.polito.it ([127.0.0.1]) by localhost (compass.polito.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CBPlWoZ5XJP3 for ; Wed, 30 Mar 2016 11:13:15 +0200 (CEST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: s203403@studenti.polito.it) by compass.polito.it (Postfix) with ESMTPSA id 4F533100176 for ; Wed, 30 Mar 2016 11:13:15 +0200 (CEST) Received: by mail-lb0-f176.google.com with SMTP id u8so27499802lbk.0 for ; Wed, 30 Mar 2016 02:13:15 -0700 (PDT) X-Gm-Message-State: AD7BkJL4f0ujHtPXxCCSFQ+kxRW6GYVREHWvwFfm16cmlpW5JB2wT4CNbPEYs7eurww4loYtZjEyFNPB18CeGg== MIME-Version: 1.0 X-Received: by 10.112.168.194 with SMTP id zy2mr3281643lbb.102.1459329194843; Wed, 30 Mar 2016 02:13:14 -0700 (PDT) Received: by 10.25.0.198 with HTTP; Wed, 30 Mar 2016 02:13:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2016 11:13:14 +0200 X-Gmail-Original-Message-ID: Message-ID: From: =?UTF-8?Q?Mauricio_V=C3=A1squez?= To: "Burakov, Anatoly" Cc: "dev@dpdk.org" , "Gonzalez Monroy, Sergio" , "Richardson, Bruce" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing") 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, 30 Mar 2016 09:13:17 -0000 Hi Anatoly, Thank you very much, I did not take into account that detail. I have two additional concerns about it: 1. I think it is possible to have a race condition. The memzone is marked as not freeable after it has been added to the ivshmem device, then it is possible to free the memzone just after it has been added to the metadata but before it is marked as not freeable. Shouldn't the memzone be marked before adding the memzone to the ivshmem device? 2. Are the #ifdefs necessary?, we already are in a file that will only compiled when ivshmem is enabled. Thanks, Mauricio Vasquez, On Wed, Mar 30, 2016 at 10:29 AM, Burakov, Anatoly < anatoly.burakov@intel.com> wrote: > Hi Mauricio, > > > > You=E2=80=99re not missing anything. It would be done this way, if the me= mzone > parameter wasn=E2=80=99t const. But it is const, so we have to find the m= emzone in > config to edit it. > > > > Thanks, > > Anatoly > > > > *From:* Mauricio V=C3=A1squez [mailto:mauricio.vasquezbernal@studenti.pol= ito.it] > > *Sent:* Wednesday, March 30, 2016 9:22 AM > *To:* dev@dpdk.org > *Cc:* Gonzalez Monroy, Sergio ; > Richardson, Bruce ; Burakov, Anatoly < > anatoly.burakov@intel.com> > *Subject:* Question about cd10c42eb5bc ("mem: fix ivshmem freeing") > > > > Dear All, > > I was looking at that patch, I can understand its functionality but not > its implementation.. > > Why to calculate idx?, Just doing "mz->ioremap_addr =3D mz->phys_addr" wo= uld > not be sufficient? After all, the goal is to mark the memzone as used by > ivshmem to forbid freeing it. > > Please corrected if I am missing something. > > Thank you, > > Mauricio Vasquez, >