From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.8750.1659459079309688454 for ; Tue, 02 Aug 2022 09:51:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VR6HTOMz; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9EA2A6100C for ; Tue, 2 Aug 2022 16:51:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D230C433D7 for ; Tue, 2 Aug 2022 16:51:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659459078; bh=Luduj0qkCLU7rRe8nEje01awEfnm/KRscfYRuCzyw0c=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VR6HTOMzVtPUQ81u5eGt0QEVGCAltu9oFj0+BialP/zREdvTqKXCXLxUoa4mjCW8T dGULlKjvJky4pKbUUbHwuBNzNlWVs1yKwFW1Av6c5f0do4M5wa5k8hVEuO8rrDoca7 jpseksYcq5m0nQXflvGf6x7rv3x0wHD2rXn1Csulp1rzEVurHZTc5Wi1tBSx0OLyo3 FFnCTHNoTo789ffxw2bQtQBZlAHOYUViYtQoNNVkZLU4ZdoertBYYsF6LZssoxlSRm M3odg8Yl7hh1D4I/84joO1n9KIf8olBSr2npPmtQTj3/SC2BsDeQNvqrRg9bh05y1I /F4Xvro+50ivA== Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-10ee900cce0so5895061fac.5 for ; Tue, 02 Aug 2022 09:51:18 -0700 (PDT) X-Gm-Message-State: ACgBeo2PjKrbekfN5/MO8zvAaLEk2cFd1CxcRKC9gtcK9Y8mL0DAMnRr WdZuKMxj4dM+AelXRLVdMrDAQCRL7zIsLnn6XNk= X-Google-Smtp-Source: AA6agR6LmytkL8TkjxakJ04cgUlwwef8nXvPcanwA+Z6pi+BTeROD1db+v8JEzHr64yi7NijAMgfLl0Eg/WN2WUy7JM= X-Received: by 2002:a05:6870:a90a:b0:10d:9e83:98a6 with SMTP id eq10-20020a056870a90a00b0010d9e8398a6mr168774oab.228.1659459077156; Tue, 02 Aug 2022 09:51:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 2 Aug 2022 18:51:06 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe: Allow partial FreeBuffer To: Jeff Brasen Cc: "devel@edk2.groups.io" , "hao.a.wu@intel.com" , "ray.ni@intel.com" , "quic_llindhol@quicinc.com" , "ardb+tianocore@kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2 Aug 2022 at 17:32, Jeff Brasen wrote: > > > > > -----Original Message----- > > From: Ard Biesheuvel > > Sent: Friday, July 29, 2022 9:48 AM > > To: Jeff Brasen > > Cc: devel@edk2.groups.io; hao.a.wu@intel.com; ray.ni@intel.com; > > quic_llindhol@quicinc.com; ardb+tianocore@kernel.org > > Subject: Re: [PATCH v2] MdeModulePkg/NonDiscoverablePciDeviceDxe: > > Allow partial FreeBuffer > > > > External email: Use caution opening links or attachments > > > > > > On Thu, 28 Jul 2022 at 13:25, Jeff Brasen wrote: > > > > > > > > > Adding Leif/Ard to CC incase they have any comments on this patch. > > > > > > > This generally looks ok to me. I just wonder if it wouldn't be simpler = to reuse > > the existing allocation descriptor if it is not being freed entirely. G= iven the > > [presumably] the most common case is to allocate and then free some pag= es > > at the end, lowering the page count on the existing descriptor would co= ver > > most cases, and we'd only need to allocate new ones if pages are being = freed > > at the start or in the middle. > > There is often freeing at the beginning as well as this is being used to = create a 64K aligned section of memory in the case. So it over allocates an= d the free's some at the beginning and the end. I could probably make it de= tect and use that but figured this code would support all cases and require= d less case specific detection. > Ah interesting. Would it help if the allocate routine aligned allocations to their size?