getrusage sucks
PATCH 1/1 getrusage sucks
Does exist any _real_ reason why getrusage can't be invoked by a task to know statistics of another task ?
The changes would be very trivial, as shown by the following patch.
Claudio
kernel/sys.c +7 -3
@@ -1746,9 +1746,13 @@ int getrusage(struct task_struct *p, intasmlinkage long sys_getrusage (int who,struct rusage __user *ru) { -if (who !=RUSAGE_SELF && who !=RUSAGE_CHILDREN ) -return -EINVAL ; -return getrusage (current, who, ru); +if (who !=RUSAGE_SELF && who !=RUSAGE_CHILDREN ) { +struct task_struct * tsk =find_task_by_pid (who); +if (tsk ==NULL ) +return -EINVAL ; +return getrusage (tsk,RUSAGE_SELF , ru); + }else +return getrusage (current, who, ru); }asmlinkage long sys_umask (int mask)
Quoted 2 lines · Claudio Scordino
Does exist any _real_ reason why getrusage can't be invoked by a task to know statistics of another task ?
Probably only super-user should be permitted to read the usage information about other processes. Allowing anyone to read anyone else's rusage would open up a bunch of side channels that sound pretty dangerous. For instance, user #1 might be able to mount a timing attack against crypto code being executed by user #2, and that doesn't sound good.
Quoted 9 lines · David Wagner
Quoted 2 lines · Claudio Scordino
Does exist any _real_ reason why getrusage can't be invoked by a task to know statistics of another task ?
Probably only super-user should be permitted to read the usage information about other processes. Allowing anyone to read anyone else's rusage would open up a bunch of side channels that sound pretty dangerous. For instance, user #1 might be able to mount a timing attack against crypto code being executed by user #2, and that doesn't sound good.
Why restrict it to root? Why not just prevent users from reading other users rusage. How could it be a security hole for joeuser's process be able to read the rusage of joeuser's other processes?
Lee
Quoted 7 lines · Lee Revell
Quoted 2 lines · David Wagner
Probably only super-user should be permitted to read the usage information about other processes.
Why restrict it to root? Why not just prevent users from reading other users rusage. How could it be a security hole for joeuser's process be able to read the rusage of joeuser's other processes?
Sorry; you're absolutely right. I agree. I overlooked that case.
How to quickly detect the mode change of a hard disk?
In reply to Claudio ScordinoHi,
I am currently doing a kernel module involves detecting/changing disk mode among STANDBY and ACTIVE/IDLE. I used ide_cmd_wait() to issue commands like WIN_IDLEIMMEDIATELY and WIN_STANDBYNOW1. The problem is, a drive in standby mode will automatically awake whenever a disk operation is requested and I need to know the mode change as soon as possible. (So I donot want to periodically use the WIN_CHECKPOWERMODE to detect it). I was wondering if the standby disk is waken by the kernel or by the disk firmware? If it is not in the kernel, is there any good way to detect it? Thanks,
Hui
Re: How to quickly detect the mode change of a hard disk?
Quoted 5 lines
I am currently doing a kernel module involves detecting/changing disk mode among STANDBY and ACTIVE/IDLE. I used
ide_cmd_wait()to issue commands likeWIN_IDLEIMMEDIATELYandWIN_STANDBYNOW1. The problem is, a drive in standby mode will automatically awake whenever a disk operation is requested and I need to know the mode change as soon as possible. (So I
AFAIK there's no nice way to get that info, but it is useful, so patch would be welcome.
Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Re: How to quickly detect the mode change of a hard disk?
On Sun, 13 Nov 2005 15:10:56 +0000, Pavel Machek wrote
Quoted 8 lines
Quoted 5 lines
I am currently doing a kernel module involves detecting/changing disk mode among STANDBY and ACTIVE/IDLE. I used
ide_cmd_wait()to issue commands likeWIN_IDLEIMMEDIATELYandWIN_STANDBYNOW1. The problem is, a drive in standby mode will automatically awake whenever a disk operation is requested and I need to know the mode change as soon as possible. (So IAFAIK there's no nice way to get that info, but it is useful, so patch would be welcome.
I would check the hdparm man page again. Still, it sounds interesting.
Additionally, it could be cool if someone could finish up or make the option for the HD freeze to use it with the HDAPS driver. ;-)
.Alejandro
Re: How to quickly detect the mode change of a hard disk?
Quoted 10 lines · Alejandro Bonilla
On Sun, 13 Nov 2005 15:10:56 +0000, Pavel Machek wrote
Quoted 8 lines
Quoted 5 lines
I am currently doing a kernel module involves detecting/changing disk mode among STANDBY and ACTIVE/IDLE. I used
ide_cmd_wait()to issue commands likeWIN_IDLEIMMEDIATELYandWIN_STANDBYNOW1. The problem is, a drive in standby mode will automatically awake whenever a disk operation is requested and I need to know the mode change as soon as possible. (So IAFAIK there's no nice way to get that info, but it is useful, so patch would be welcome.
Quoted 7 lines
I would check the hdparm man page again. Still, it sounds interesting.
Additionally, it could be cool if someone could finish up or make the option for the HD freeze to use it with the HDAPS driver. ;-)
.Alejandro
Thanks for reply :) What I did to handle this problem is a little stupid : Suppose the disk is now in a standby mode. In case that there is a request sent to the disk drive, a kernel thread is awake to detect/update the current disk power mode. The disk power mode is stored in the ide_drive_t structure and be protected by lock. It seems to work fine in my simple tests. But again, there should be better solutions.
Hui
Re: How to quickly detect the mode change of a hard disk?
Hi!
Quoted 17 lines
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
I am currently doing a kernel module involves detecting/changing disk mode among STANDBY and ACTIVE/IDLE. I used
ide_cmd_wait()to issue commands likeWIN_IDLEIMMEDIATELYandWIN_STANDBYNOW1. The problem is, a drive in standby mode will automatically awake whenever a disk operation is requested and I need to know the mode change as soon as possible. (So IAFAIK there's no nice way to get that info, but it is useful, so patch would be welcome.
Quoted 7 lines
I would check the hdparm man page again. Still, it sounds interesting.
Additionally, it could be cool if someone could finish up or make the option for the HD freeze to use it with the HDAPS driver. ;-)
.Alejandro
Quoted 6 lines
Thanks for reply :) What I did to handle this problem is a little stupid : Suppose the disk is now in a standby mode. In case that there is a request sent to the disk drive, a kernel thread is awake to detect/update the current disk power mode. The disk power mode is stored in the
ide_drive_tstructure and be protected by lock. It seems to work fine in my simple tests. But again, there should be better solutions.
Can we get the patch?
Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Re: How to quickly detect the mode change of a hard disk?
On Sat, 19 Nov 2005, Pavel Machek wrote:
Hi,
Quoted 26 lines
Hi!
Quoted 17 lines
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
I am currently doing a kernel module involves detecting/changing disk mode among STANDBY and ACTIVE/IDLE. I used
ide_cmd_wait()to issue commands likeWIN_IDLEIMMEDIATELYandWIN_STANDBYNOW1. The problem is, a drive in standby mode will automatically awake whenever a disk operation is requested and I need to know the mode change as soon as possible. (So IAFAIK there's no nice way to get that info, but it is useful, so patch would be welcome.
Quoted 7 lines
I would check the hdparm man page again. Still, it sounds interesting.
Additionally, it could be cool if someone could finish up or make the option for the HD freeze to use it with the HDAPS driver. ;-)
.Alejandro
Quoted 6 lines
Thanks for reply :) What I did to handle this problem is a little stupid : Suppose the disk is now in a standby mode. In case that there is a request sent to the disk drive, a kernel thread is awake to detect/update the current disk power mode. The disk power mode is stored in the
ide_drive_tstructure and be protected by lock. It seems to work fine in my simple tests. But again, there should be better solutions.
Quoted 2 lines
Can we get the patch?
--
Sure. I will make the patch and test it again. But it may take a while because I have an urgent task now...Thanks,
Hui