[Crash-utility] Re: [PATCH v7 01/15] Fix the regression of cpumask_t for xen hyper

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

 



Hi Aditya,

On Wed, Sep 4, 2024 at 10:27 PM Aditya Gupta <adityag@xxxxxxxxxxxxx> wrote:
>
> Hi Tao,
>
> Is this a separate independent patch or related to this series ?
>
This is an independent patch, but discovered when doing a regression
test against the stack unwinding patchset. Since we have done the
cpumask_t modification in [PATCH v6 10/14], the modification will
continue in v7 as well. So I posted it with v7 together.

Lianbo suggested that I separate some "less strongly connected with
stack unwinding" patches from v7, which formed the part 1 as mentioned
in [1]. Part 1 can be merged prior to the rest of part 2 & 3. So I
think part 1 is also suitable for the cpumask_t regression patch.

[1]: https://www.mail-archive.com/devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx/msg01079.html

Thanks,
Tao Liu

>
> - Aditya Gupta
>
>
> On 04/09/24 13:19, Tao Liu wrote:
> > There is a regression been found for xen hyper due to the commit:
> > f615f8fab7bf ("Fix "irq -a" exceeding the memory range issue").
> >
> > The reason is for xen hyper, kt->cpu is not initialized due to
> > kernel_init() won't be called. So 0 would be assigned to cpulen and
> > fails the GETBUF().
> >
> > Before:
> > crash> bt -c 2
> > bt: zero-size memory allocation! (called from 51f168)
> >
> > After:
> > crash> bt -c 2
> > PCPU:  0  VCPU: ffff8300001b8080
> >   #0 [ffff8300001bfe00] machine_crash_kexec at ffff83000010de72
> >   #1 [ffff8300001bfe10] do_kexec_op at ffff83000010e3cb
> >   #2 [ffff8300001bfe50] do_console_io at ffff83000011aff4
> >   #3 [ffff8300001bfe90] mod_l1_entry at ffff830000129045
> >   #4 [ffff8300001bfea0] toggle_guest_mode at ffff8300001641bf
> >   #5 [ffff8300001bfeb0] do_iret at ffff830000164888
> >   #6 [ffff8300001bff20] syscall_enter at ffff8300001633d2
> >
> > Since xen hyper will initialize its own cpumask_t, this patch will reuse
> > it for XEN_HYPER_MODE. In addition, this patch won't modify the similar
> > code hunk in generic_get_irq_affinity(), because for xen, there is no
> > "irq" cmd, so the regression won't be triggered.
> >
> > Cc: Sourabh Jain <sourabhjain@xxxxxxxxxxxxx>
> > Cc: Hari Bathini <hbathini@xxxxxxxxxxxxx>
> > Cc: Mahesh J Salgaonkar <mahesh@xxxxxxxxxxxxx>
> > Cc: Naveen N. Rao <naveen.n.rao@xxxxxxxxxxxxxxxxxx>
> > Cc: Lianbo Jiang <lijiang@xxxxxxxxxx>
> > Cc: HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx>
> > Cc: Tao Liu <ltao@xxxxxxxxxx>
> > Cc: Alexey Makhalov <alexey.makhalov@xxxxxxxxxxxx>
> > Cc: Aditya Gupta <adityag@xxxxxxxxxxxxx>
> > Signed-off-by: Tao Liu <ltao@xxxxxxxxxx>
> > ---
> >   tools.c | 6 ++++++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/tools.c b/tools.c
> > index 2b78b95..dec6e5b 100644
> > --- a/tools.c
> > +++ b/tools.c
> > @@ -16,6 +16,7 @@
> >    */
> >
> >   #include "defs.h"
> > +#include "xen_hyper_defs.h"
> >   #include <ctype.h>
> >
> >   #ifdef VALGRIND
> > @@ -6720,6 +6721,11 @@ get_cpumask_buf(void)
> >   {
> >       int cpulen, len_cpumask;
> >
> > +#ifdef XEN_HYPERVISOR_ARCH
> > +     if (XEN_HYPER_MODE() && XEN_HYPER_VALID_SIZE(cpumask_t))
> > +             return (ulong *)GETBUF(XEN_HYPER_SIZE(cpumask_t));
> > +#endif
> > +
> >       cpulen = DIV_ROUND_UP(kt->cpus, BITS_PER_LONG) * sizeof(ulong);
> >       len_cpumask = STRUCT_SIZE("cpumask_t");
> >       if (len_cpumask > 0)
>
--
Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux