On 12/15/11, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Sat, Dec 10, 2011 at 10:37:02PM +0800, t cheney wrote:
>> This patch just add memory layout(same as /proc/pid/maps) to
>> coredump file. The layout is appended to corenote segment with
>> flag NT_MAPS=7.
>
>> + len = sprintf(buf, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu",
>> + start,
>> + end,
>> + flags & VM_READ ? 'r' : '-',
>> + flags & VM_WRITE ? 'w' : '-',
>> + flags & VM_EXEC ? 'x' : '-',
>> + flags & VM_MAYSHARE ? 's' : 'p',
>> + pgoff,
>> + MAJOR(dev), MINOR(dev), ino);
>
> Device numbers may be wider than 16 bits.
Yes, it should be:
len = sprintf(buf, "%08lx-%08lx %c%c%c%c %08llx %03x:%05x %lu",
and corresponding change from 25 to 29 in function pad_spaces:
static int pad_spaces(char *p, int len)
{
len = 29 + sizeof(void *) * 6 - len;
>
>> + p = d_path(&vma->vm_file->f_path, s, maps_size-1);
>
> What if somebody renames the file (or, better yet, its parent directory)
> between two calls of that thing?
>
Yes, function core_handle_maps is called twice, first one just calculate size,
second one write maps into coredump file. If the pathname is changed,
the size may changed too.
If the new size is less than or same as origin, all maps string is
written to file.
If the new size is more than origin, just part is written to file,
the rest is ignored.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
