[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xen: linker symbol mess, and freeing errors


  • To: Andrew Cooper <amc96@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Dec 2021 16:20:48 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k+LzXGuMUIsINIBTh9QaoXw2NcVFk1toHUM38W2fzTE=; b=j+nHSiSoyNYQgIplLYnj18VE/Gt40ut5/11Fukw7ewo6MSYwBnu/kmvCZaHkTOykdVKVTXYBoblIFPI04FczVh5WwVseJeZlmugiZx1E7IC6vX42mpe0wT2y7XACZR4zeRPe08zDwsdMDZBs3t3cAXbSaSL3YlwO+YOIc9o1nv1dEXzTM+4ZFveL/WwL/1YuERQzd2oh95O24vCd5WGD1cSIJ4Qi2o14mg4OhWMi4cN9bttQV4v1XGbXIpjKIPhK+xtYyNRDKsAI5CDACB88orbt2Cep/Nc/bgPjuZzkdFCNGb1Wqu/WnWm0uMJ06zbd3+UCOLbstGJK0QTLuizI6g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dfR/GBb5m1uci8eu3wVt1RLG6hDnqVY71HWjouppD7/uKcrs6CPz7BJ78L3ZeMvzXAo+Sw7kkFSIlgHAUip7wLoOfbIKGB29Q6qPNv8ixHjiX6VA5JTBkTxkI025C+2UzhVWLUL4AMNWoVu+zoFtHqjaNCxhiPUmcwwNzRyiLFqyiNKRdB1J20s/7TCSQTRGDuRxvj4m24TIaCBKEdLUgLzhAZcSQtLQBgi5NgNB/pCy47mDk0Ax+cQZkl1T6Iiim5ct8Ag7ai39mFSQGAT6UfCVWSZa29ALWWTL3xTbPLcsOmz1nAn5HTumd/5ymo5bWJNDFjhAgT3ow1gpz6SheA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Delivery-date: Tue, 07 Dec 2021 15:21:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.12.2021 14:34, Andrew Cooper wrote:
> Hello,
> 
> Following the __ro_after_init work, I tried to complete a few pieces of
> cleanup that I'd accrued, and everything has unravelled.
> 
> On x86, the __2M_* symbols haven't really been 2M aligned since their
> introduction, and the utter mess that was _stext starting at 1M has long
> since been cleared up.  Dropping the 2M prefix reveals that we have both
> __init_{start,begin} and identifying that lead to discovering that
> 
>     /* Destroy Xen's mappings, and reuse the pages. */
>     if ( using_2M_mapping() )
>     {
>         start = (unsigned long)&__2M_init_start,
>         end   = (unsigned long)&__2M_init_end;
>     }
>     else
>     {
>         start = (unsigned long)&__init_begin;
>         end   = (unsigned long)&__init_end;
>     }
> 
> is a tautology that nothing is capable of optimising.

Interesting. I would assume it wasn't always that way, but clearly it
is now.

> So I set about trying to simply both x86 and ARM down to a single sets
> of bounding variables, with a requirement that these would be expected
> to be common across all architectures.
> 
> I'm intending to use __$FOO_{start,end} because we're semi-consistent on
> this already, and get rid of the ones such as _{s,e}$FOO because they're
> unnecessarily obscure, and complicated to read for a compound foo.
> 
> At this point (as I haven't really started yet), I could be persuaded on
> a different naming scheme if anyone has any strong views.

Imo that scheme is fine. _{s,e}$FOO have always seemed risky in terms
of name clashes / confusion to me, but I've assumed we use them for
being pretty standard and hence recognized by certain tools.

> But that's only the start of the fun.  The is_kernel() predicate is
> broken (or at least problematic) because it covers the init section. 

I'd say problematic. We may want to have is_active_kernel()
paralleling other is_active_...(); whether a need for is_kernel()
would then remain is to be seen.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.