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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
