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

On Fri, 22 Mar 2019 10:38:31 -0400 (EDT) Dave Anderson <anderson(a)redhat.com&gt; wrote: > ----- Original Message ----- > > Hi Dave, > > > > > > On Thu, 21 Mar 2019 11:46:33 -0400 (EDT) > > Dave Anderson <anderson(a)redhat.com&gt; 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 > > > > > > > > > > > > > > > >