Re: Mutual debugging of 2 processes can stuck in unkillable stopped state

2021-04-12 Thread Igor Zhbanov
Hi Oleg, So what is the cause of this problem? Thank you. On 29.03.2021 20:44, Igor Zhbanov wrote: Here is the processes stack before sending any signals to them: izh@suse2:~> sudo cat /proc/1751/stack [<0>] ptrace_stop+0x14e/0x260 [<0>] ptrace_do_notify+0x91/0xb0 [<0>

Re: Mutual debugging of 2 processes can stuck in unkillable stopped state

2021-03-29 Thread Igor Zhbanov
Hi Oleg, On 29.03.2021 20:38, Oleg Nesterov wrote: Hi Igor, So. As expected, they sleep in EVENT_EXIT _after_ you have already sent SIGKILL. Here is the processes stack before sending any signals to them: izh@suse2:~> sudo cat /proc/1751/stack [<0>] ptrace_stop+0x14e/0x260 [<0>]

Re: Mutual debugging of 2 processes can stuck in unkillable stopped state

2021-03-29 Thread Igor Zhbanov
0 Speculation_Store_Bypass: vulnerable SpeculationIndirectBranch: always enabled Cpus_allowed: 7 Cpus_allowed_list: 0-2 Mems_allowed: ,,,,,,,,,,,,,,,0001 Mems_allowed_list: 0 voluntary_ctxt_switches:180 nonvoluntary_ctxt_switches:

Wrong __setup() callbacks return values and /init's environment pollution

2020-12-25 Thread Igor Zhbanov
It seems that nobody knows how to write __setup() callback functions for parsing the command line parameters. And there are no documentation or comments about best practices. Despite being declared obsolete __setup() is used about 435 times in the kernel and 51 of them (~11.2%) are erroneous in

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

2020-09-11 Thread Igor Zhbanov
On 10.09.2020 23:05, Matthew Wilcox wrote: On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote: On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote: On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: There is also the use case of noexec mounts and file permissions.

Re: [PATCH RFC 0/3] Per-process power consumption measurement facility

2013-07-30 Thread Igor Zhbanov
d be very helpful to implement our task in correct way and enhance current kernel functionality. Thank you. P.S. Since I'm not subscribed to LKML, please CC in reply. -- Best regards, Igor Zhbanov, Sub-Project Leader, phone: +7 (495) 797 25 00 ext 3981 e-mail: i.zhba...@samsung.com Mobile group

Re: [PATCH RFC 0/3] Per-process power consumption measurement facility

2013-07-30 Thread Igor Zhbanov
to implement our task in correct way and enhance current kernel functionality. Thank you. P.S. Since I'm not subscribed to LKML, please CC in reply. -- Best regards, Igor Zhbanov, Sub-Project Leader, phone: +7 (495) 797 25 00 ext 3981 e-mail: i.zhba...@samsung.com Mobile group, Moscow RD

Re: [PATCH] Fix common_audit_data type for smack_inode_unlink() and smack_inode_rmdir()

2013-03-12 Thread Igor Zhbanov
Hi Casey, Casey Schaufler wrote: On 3/11/2013 4:50 AM, Igor Zhbanov wrote: This patch fixes kernel Oops because of wrong common_audit_data type in smack_inode_unlink() and smack_inode_rmdir(). This patch does not apply to any tree I have. The lines: smk_ad_setfield_u_fs_path_dentry

Re: [PATCH] Fix common_audit_data type for smack_inode_unlink() and smack_inode_rmdir()

2013-03-12 Thread Igor Zhbanov
Hi Casey, Casey Schaufler wrote: On 3/11/2013 4:50 AM, Igor Zhbanov wrote: This patch fixes kernel Oops because of wrong common_audit_data type in smack_inode_unlink() and smack_inode_rmdir(). This patch does not apply to any tree I have. The lines: smk_ad_setfield_u_fs_path_dentry

[PATCH] Fix common_audit_data type for smack_inode_unlink() and smack_inode_rmdir()

2013-03-11 Thread Igor Zhbanov
ializes common_audit_data structures with correct type. Also I removed unneeded smk_ad_setfield_u_fs_path_dentry(, NULL); initialization, because both dentry and inode pointers are stored in the same union. Signed-off-by: Igor Zhbanov Signed-off-by: Kyungmin Park --- security/smack/smack_

[PATCH] Fix common_audit_data type for smack_inode_unlink() and smack_inode_rmdir()

2013-03-11 Thread Igor Zhbanov
removed unneeded smk_ad_setfield_u_fs_path_dentry(ad, NULL); initialization, because both dentry and inode pointers are stored in the same union. Signed-off-by: Igor Zhbanov i.zhba...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- security/smack/smack_lsm.c |4