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

[Philipp Rudo]

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 :)

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
> > > > 
> > > >     
> > >   
> > 
> >   
>