[Crash-utility] [PATCH 0/1] Fix for XArray/radix_tree rework on linux-next

[Dave Anderson]

----- Original Message -----
> On Fri, 22 Mar 2019 10:38:31 -0400 (EDT)
> Dave Anderson <anderson at redhat.com> wrote:
> 
> > ----- Original Message -----
> > > Hi Dave,
> > > 
> > > 
> > > On Thu, 21 Mar 2019 11:46:33 -0400 (EDT)
> > > Dave Anderson <anderson at redhat.com> wrote:
> > >   
> > > > ----- Original Message -----
> > > > > Hi Dave,
> > > > > 
> > > > > crash currently fails on linux-next kernel due to another radix-tree
> > > > > rework.
> > > > > The patch attached fixes this.
> > > > > 
> > > > > BTW, is there an 'official policy' about fixing linux-next issues, as
> > > > > commits
> > > > > can be changed/dropped on their way to the linux repo?
> > > > 
> > > > Hi Philipp,
> > > > 
> > > > Not really, although since your fixes will not affect the current
> > > > mechanism,
> > > > they should be safe to apply.
> > > 
> > > Ok. I'm mainly asking because we are building up an environment for
> > > automated
> > > (kernel) tests on s390, including tests on linux-next. In this context we
> > > also
> > > have a test if crash starts with a given kernel. That's why I expect more
> > > fixes/bugs like this to come in the future.
> > 
> > Excellent -- I appreciate that!
> 
> You're welcome.
>  
> > > 
> > > I'm not really sure what's the best way to handle them. On one hand it
> > > would be
> > > nice when crash could read those kernels. On the other I don't want to
> > > clutter
> > > the code with fixes for patches that don't make it upstream. Do you have
> > > a
> > > preferred way to handle similar bugs in the future?
> > 
> > Recently I have been trying to be as proactive as possible, although I only
> > go as
> > far as sanity-testing upstream -rc kernels as they get released (i.e. not
> > linux-next).
> > On the other hand, I'm about to check in the first phase of support for
> > ARM64 52-bit
> > virtual addressing, which has not yet made it into the mainstream kernel.
> > In that
> > case, it's pretty certain that those changes will be accepted.  And I would
> > presume
> > that stuff that Matthew Wilcox has queued up for Xarray are a pretty safe
> > bet as
> > well.  So let's take it on a case-by-case basis.
> 
> Yeah, Matthew Wilcox are a pretty save bet. It's more patches like the one
> that
> caused the 'MAGIC_START not found' Mikhail is working on, that bugs me.
> 
> Great. So we keep sending you the patches. Then you can decide if you feel
> comfortable enough to include them or better wait till the code is accepted
> upstream.
> 
> > >   
> > > > But I note that your changes only address the basic task initialization
> > > > sequence and the "bpf" and the "ipcs" commands.  Did you also look
> > > > into the "files -p", "irq" and "tree -t -p" options?
> > > 
> > > You are right I missed those. "files -p" however seems to work fine with
> > > the
> > > patch I sent. For the other two I'll prepare a v2.
> > 
> > Nice -- thanks!
> 
> It's almost on the way. The only problem I have is that 'bpf' only prints a
> blank line for linux-next but works totally fine on upstream. So I currently
> don't know if there's still a problem or if there simply is no bpf program.
> At least the error is gone :)

That's most likely the case.  If you print out the "prog_idr" or "map_idr" structures,
their "xa_head" pointer are probably NULL.

Dave

 
> Thanks
> Philipp
> 
> > 
> > Dave
> > 
> >  
> > > Thanks
> > > Philipp
> > >   
> > > > 
> > > > Thanks,
> > > >   Dave
> > > >  
> > > > PS: the
> > > > 
> > > > "
> > > > > 
> > > > > Thanks
> > > > > Philipp
> > > > > 
> > > > > Philipp Rudo (1):
> > > > >   Fix for XArray/radix_tree rework on linux-next
> > > > > 
> > > > >  bpf.c  |  7 ++++++-
> > > > >  ipcs.c |  5 ++++-
> > > > >  task.c | 15 +++++++++++----
> > > > >  3 files changed, 21 insertions(+), 6 deletions(-)
> > > > > 
> > > > > --
> > > > > 2.16.4
> > > > > 
> > > > >     
> > > >   
> > > 
> > >   
> > 
> 
>