Re: [Crash-utility] [PATCH for testing only] Make radix tree compatible with 4.20-rc1 xarray
Dave Anderson wrote on Mon, Nov 05, 2018:
> 4.20-rc1 was not released yet so this isn't surprising :)
> It came out just this weekend, should probably hit rawhide soon.
Yeah, on Friday the guy in the cube next to me was working with a roll-your-own
kernel from the latest upstream git tree, and he saw the crash problem. I created
a "snap.so" vmcore from it, so I can play around with it for now.
Oh, another handy extension I didn't know about; will need to play with
this on bigger servers when we have a transient issue to see how it
performs, it's always annoying to do a voluntary crash when we could go
on without it :)
I just started looking at the xarray kernel code, and w/respect to
the crash
utility, I'm thinking it's probably worth biting the bullet and creating
a set of analogous xarray functions/structures/#define's that are similar
in nature (identical except in name in most cases) to the set of exported
radix tree functions/structures/#define's.
Yes, the new pieces will in most places be essentially the same as the
radix tree versions, but the alternative of "hiding" the xarray kernel
facility
behind a bunch of radix tree functions and structures is disconcerting.
Yeah, ultimately I pretty much agree there; it's just close enough to be
alluring to merge but long-term it's definitely better to duplicate the
code.
Past the confusion of hiding the name (we could just alias functions if
that's all it was); Matthew was talking about further modifying the
xarray code so adding hacks on top of other hacks will be more difficult
to understand if we don't do that.
That's what the RADIX_TREE_EXCEPTIONAL_ENTRY items are, right?
Granted,
I never ran into one until recently when I bumped into a value instead
of a pointer when running "files -p":
Ah, that looks right. I think xarray is much more flexible with these,
letting users use any of the first two bits as they please except for
'2' (the new internal value bit); see xa_tag_pointer for example:
* If the user of the XArray prefers, they can tag their pointers instead
* of storing value entries. Three tags are available (0, 1 and 3).
* These are distinct from the xa_mark_t as they are not replicated up
* through the array and cannot be searched for.
--
Dominique