From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Anderson Subject: Re: [PATCH v2 0/6] crash: Bundle of fixes for Xen Date: Tue, 14 Aug 2012 10:04:00 -0400 (EDT) Message-ID: <1543188889.13757694.1344953040454.JavaMail.root@redhat.com> References: <20120814061408.GA2471@host-192-168-1-59.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120814061408.GA2471-UojuW/CpjwpdUOLzJiIvSsFoITBeLw/klGfBN0aaEZ+lPcVs/6D9LQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kexec-bounces-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Errors-To: kexec-bounces+glkk-kexec=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: "Discussion list for crash utility usage, maintenance and development" Cc: olaf-QOLJcTWqO2uzQB+pC5nmwQ@public.gmane.org, xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org, konrad wilk , andrew cooper3 , ptesarik-AlSwsSmVLrQ@public.gmane.org, jbeulich-IBi9RG/b67k@public.gmane.org, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: xen-devel@lists.xenproject.org ----- Original Message ----- > On Mon, Aug 13, 2012 at 03:16:53PM -0400, Dave Anderson wrote: > > [...] > > > OK good. It tests OK on a few older pvops kernels that I have on > > hand. > > > > The only thing I've changed is to handle compiler warnings in x86_64.c and > > x86.c by initializing p2m_top to NULL in x86_64_pvops_xendump_p2m_l3_create() > > and x86_pvops_xendump_p2m_l3_create(). I also used GETBUF() in those two > > functions to avoid having to add the malloc-failure line. > > No problem. However, I am a bit surprised that you have seen some warnings. > I have not seen any. Did you compiled crash with extra options or something > like that? Or maybe there is a diffrence in our compilers (mine is gcc version > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) - quite ancient). Extra options (also with gcc 4.1.2) -- try building with "make warn". It adds: WARNING_OPTIONS=-Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector or "make Warn", which adds -Werror to the above. In those two functions there are "goto err" statements prior to allocating p2m_top, and so the free(p2m_top) could receive a random stack value. Of course even if it did get by the free() call in that highly unlikely case, the crash session is just about to fatally shut itself down. Thanks, Dave