On 07/20/2017 03:15 PM, Stefan Ring wrote: > On Thu, Jul 20, 2017 at 4:27 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >> On 07/20/2017 02:52 AM, Stefan Ring wrote: >>> On Thu, Jul 20, 2017 at 12:00 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >>>> ok, that shoulda worked... I wonder how to debug this, if you can't >>>> legally share the problematic image with me to investigate... >>>> >>>> I put a lot of effort into selectively zeroing out unused portions >>>> of metablocks a couple years back, I am surprised that this much remains. >>>> >>>> I wonder if something regressed ... >>> >>> I will try if I can find out which code paths lead to the content >>> being dumped out. >> >> Perhaps you could send xfs_info output and offsets of the "safe" strings, >> and maybe look at block or sector boundaries of the blocks containing >> those "safe" strings to identify magic numbers which would identify >> the metadata types ... >> > > Ok, > > I'm using the for-next branch now (0602fbe880) and inserted something > like this so I can set a breakpoint on my_break. Thanks, I'll dig into this a bit. I thought we had an xfstest that looked for this sort of leaked string problem, but now I'm not finding it... something to fix, I guess. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
