On Fri, Sep 30, 2016 at 8:38 PM, Jeff Mahoney <jeffm@xxxxxxxx> wrote: > On 9/30/16 5:07 PM, Rich Freeman wrote: >> On Fri, Sep 30, 2016 at 4:55 PM, Jeff Mahoney <jeffm@xxxxxxxx> wrote: >>> This looks like a use-after-free on one of the pages used for >>> compression. Can you post the output of objdump -Dr >>> /lib/modules/$(uname -r)/kernel/fs/btrfs/btrfs.ko somewhere? >>> >> >> Sure: >> https://drive.google.com/open?id=0BwUDImviY_gcR3JfT0Z1cUlRVEk >> >> I was impressed by just how large it was. >> >> I take it you're going to try to use the offsets in the oops to figure >> out where it went wrong? I really need to get kernel core dumping >> working on this box... > > Yep. What I think is happening is that we have workspace getting freed > while it's in use. The faulting address is in vmalloc space and it's > also the first argument to memcpy, which makes it the destination. In > lzo_decompress_biovec, that means it's the workspace->cbuf. Beyond that > I'll have to dig a bit more. > I'll confess to not being much of a kernel hacker, but could this error also be caused by a buffer overrun? If working_bytes or in_page_bytes_left are larger than the size of the buffer then the memcpy would overrun the length of the buffer. I don't know if that generates a different error than the one reported. What guarantee do we have that working_bytes is less than the size of workspace->cbuf? I'm just throwing stuff out there because as far as I can tell the code never frees workspace (I'm guessing kunmap at the very end might take care of it). -- Rich -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
