Re: [PATCH] connector: add parent pid and tgid to coredump and exit events

[Evgeniy Polyakov <zbr@ioremap.net>]

Stefan, hi

Sorry for delay.

26.04.2018, 15:04, "Stefan Strogin" <stefan.strogin@gmail.com>:
> Hi David, Evgeniy,
>
> Sorry to bother you, but could you please comment about the UAPI change and the patch?

With 4-bytes pid_t everything looks fine, and I do not know arch where pid is larger currently, so it looks safe.

David, please pull it into your tree, or should it go via different path?

Acked-by: Evgeniy Polyakov <zbr@ioremap.net>


>>  I don't see how it breaks UAPI. The point is that structures
>>  coredump_proc_event and exit_proc_event are members of *union*
>>  event_data, thus position of the existing data in the structure is
>>  unchanged. Furthermore, this change won't increase size of struct
>>  proc_event, because comm_proc_event (also a member of event_data) is
>>  of bigger size than the changed structures.
>>
>>  If I'm wrong, could you please explain what exactly will the change
>>  break in UAPI?
>>
>>  On 30/03/18 19:59, David Miller wrote:
>>>  From: Stefan Strogin <sstrogin@cisco.com>
>>>  Date: Thu, 29 Mar 2018 17:12:47 +0300
>>>
>>>>  diff --git a/include/uapi/linux/cn_proc.h b/include/uapi/linux/cn_proc.h
>>>>  index 68ff25414700..db210625cee8 100644
>>>>  --- a/include/uapi/linux/cn_proc.h
>>>>  +++ b/include/uapi/linux/cn_proc.h
>>>>  @@ -116,12 +116,16 @@ struct proc_event {
>>>>               struct coredump_proc_event {
>>>>                       __kernel_pid_t process_pid;
>>>>                       __kernel_pid_t process_tgid;
>>>>  + __kernel_pid_t parent_pid;
>>>>  + __kernel_pid_t parent_tgid;
>>>>               } coredump;
>>>>
>>>>               struct exit_proc_event {
>>>>                       __kernel_pid_t process_pid;
>>>>                       __kernel_pid_t process_tgid;
>>>>                       __u32 exit_code, exit_signal;
>>>>  + __kernel_pid_t parent_pid;
>>>>  + __kernel_pid_t parent_tgid;
>>>>               } exit;
>>>>
>>>>       } event_data;
>>>
>>>  I don't think you can add these members without breaking UAPI.