lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46CB2E7B.70103@linux.vnet.ibm.com>
Date:	Tue, 21 Aug 2007 23:57:07 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Jonathan Lim <jlim@....com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Send exit code through for taskstats.ac_exitcode

Jonathan Lim wrote:
> On Mon Aug 20 20:44:13 2007, balbir@...ux.vnet.ibm.com wrote:
>> Jonathan Lim wrote:
>>> taskstats.ac_exitcode is assigned to task_struct.exit_code in
>>> bacct_add_tsk() through the following kernel function calls: 
>>>
>>>   do_exit()
>>>     taskstats_exit_send()
>>>       fill_pid()
>>>         bacct_add_tsk()
>>>
>>> The problem is that in do_exit(), task_struct.exit_code is set to 'code' 
>>> only after taskstats_exit_send() has been called.  So we need to send
>>> 'code' through to bacct_add_tsk().
>> Hi, Jonathan,
>>
>> The patches look like a step in the right direction, I would suggest an
>> alternate implementation
>>
>> Why can't we assign tsk->exit_code to code earlier? Can we not move up the
>> assignment to before taskstats_exit()? Wouldn't that be much simpler?
> 
> Hi Balbir,
> 
> That was what I wanted to do at first, but there was some concern over whether
> it would affect any of the intervening function calls.  If there's no
> particular reason why the tsk->exit_code assignment is placed where it's at
> now, then yes, I would much rather move it to before taskstats_exit().
> 
> I looked at the following functions involving tsk:
> 
>   exit_mm
>     mm_release
>       deactivate_mm
>   exit_sem
>   __exit_files
>   __exit_fs
>   cpuset_exit
>   exit_keys
> 
> and don't see anything that setting exit_code would affect.  What do you think?
> 

I think your search and analysis leads me to believe that, it might be the
correct thing to do. I would suggest we patch it that way and run a functional
test like LTP to ensure we did not break anything.

What do you think?

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ