----- Original Message ----- > On Fri, 22 Mar 2019 10:38:31 -0400 (EDT) > Dave Anderson <anderson@xxxxxxxxxx> wrote: > > > ----- Original Message ----- > > > Hi Dave, > > > > > > > > > On Thu, 21 Mar 2019 11:46:33 -0400 (EDT) > > > Dave Anderson <anderson@xxxxxxxxxx> 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 > > > > > > > > > > > > > > > > > > > > > > > > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
