20 May 2013 01:02
17 May 2013 00:12
[PATCH 0/1] posix timers: Expand exitsting info in proc file
Hi. I'm working on the checkpoint-restore project (http://criu.org), on realisation of posix-timers. To compleatly checkpoint and restore these timers we need to know which clock they are using. So I d'like to add this information to existing syscall which shows posix-timers info. Pavel Tikhomirov (1): posix-timers: Show clock ID in proc file fs/proc/base.c | 1 + 1 file changed, 1 insertion(+) -- -- 1.7.9.5
22 Mar 2013 12:47
How about allowing ptracing processes in the TASK_UNINTERRUPTIBLE state?
Hello, I am looking for opinions on an idea: How about allowing ptracing of processes in the TASK_UNINTERRUPTIBLE state, at least for processes with CAP_SYS_PTRACE? I think that it would be useful to be able to grab coredumps of processes that are hanging in the TASK_UNINTERRUPTIBLE state, but for that, I think that it would be necessary to have some way to inspect the registers of processes that are hanging there, and the easiest way to allow that that I can see would be to patch ptrace. Here's my usecase: I wrote an OpenCL program to run some computations and estimated the real time it would run for to be around four hours. Now this program has run for ten hours. I'm relatively sure that it's not hanging, but I'd really like to inspect its state with gdb to see how much of the result buffer is filled with results – however, that's not possible because the OpenCL implementation has caused my process to go into the D state. I'll have to reboot the PC to abort the computation or to wait for an unknown amount of time until it finishes (in case it hasn't deadlocked somewhere). Yes, it's my mistake to send such an amount of work to the GPU without intermediary save steps, but still, I think that this would be a useful feature for debugging. The only potential issue I can see with this is that someone might use it for causing a denial of service by stopping something inside some kind of lock. Because of this, I'm suggesting to limit this ability to processes with CAP_SYS_PTRACE. As far as I know, security should not be an issue because kernel mode and user mode registers are seperate, but I'm not entirely sure about that – could anyone here tell me whether that's right? If you don't tell me that it's a very bad idea or hard to implement for some reason (I have written nearly no kernel code in the past, so I don't know how hard it will be), I'll try to write a patch.(Continue reading)
12 Mar 2013 22:19
Info
This is a general notification to the public. We are a reputable and legitimate loan lender company in United Kingdom,Malaysia and Ghana.We give out all kinds of loans, such as personal loans,commercial loans, business loans, investment loans, etc. We offer long and short terms loan services with an affordable interest rate of 3% only. We offer the best loan services on the internet,because our loan services are very genuine and efficient. We have also been awarded by the general loan lending commission as the best loan company on the internet. For details about our loan services, contact us via email for more informations.email: incitipprimfina@... 1. Names in full : 2. Country of Residence/Address : 3. Amount : 4. Duration Of Loan : 5. Age: 6.Phone Number: 7.Applicant Address: We look forward to your patronage. Regards Margaret Jones Secretary
11 Mar 2013 10:11
[PATCH 0/3] posix timers: Extend kernel API to report more info about timers (v3)
Hi. Currently kernel doesn't provide any API for getting information about what timers are currently created by process and in which state they are. Also, the way timer IDs are generated makes it impossible to create a timer with any desired ID. Both facilities are very very tempting by the checkpoint-restore project. That said, this series fixes posix timers API in this way: 1. it makes timers IDs generation per-signal_struct to allow for recreation of a timer with desired ID; 2. it adds per-task proc file where all timers created by it are listed. This v3 series is ported on v3.9-rc2 and patches' changelogs are fixed according to Thomas' feedback to contain info why the change is required. Thanks, Pavel
10 Mar 2013 22:42
Greetings from George Daniels
Greetings from George Daniels I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedaniels@... Have a pleasant day. George Daniels
4 Mar 2013 11:46
[PATCH 1/2] ptrace: add ability to retrieve signals without removing from a queue (v4)
This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
This request is used to retrieve information about pending signals
starting with the specified sequence number. Siginfo_t structures are
copied from the child into the buffer starting at "data".
The argument "addr" is a pointer to struct ptrace_peeksiginfo_args.
struct ptrace_peeksiginfo_args {
u64 off; /* from which siginfo to start */
u32 flags;
s32 nr; /* how may siginfos to take */
};
"nr" has type "s32", because ptrace() returns "long", which has 32 bits
on i386 and a negative values is used for errors.
Currently here is only one flag PTRACE_PEEKSIGINFO_SHARED for dumping
signals from process-wide queue. If this flag is not set, signals are
read from a per-thread queue.
The request PTRACE_PEEKSIGINFO returns a number of dumped signals. If a
signal with the specified sequence number doesn't exist, ptrace returns
zero. The request returns an error, if no signal has been dumped.
Errors:
EINVAL - one or more specified flags are not supported or nr is negative
EFAULT - buf or addr is outside your accessible address space.
A result siginfo contains a kernel part of si_code which usually
striped, but it's required for queuing the same siginfo back during
(Continue reading)
27 Feb 2013 15:37
[PATCH 1/2] ptrace: add ability to retrieve signals without removing from a queue (v3)
This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
This request is used to retrieve information about pending signals
starting with the specified sequence number. Siginfo_t structures are
copied from the child into the buffer starting at "data".
The argument "addr" is a pointer to struct ptrace_peeksiginfo_args.
struct ptrace_peeksiginfo_args {
u64 off; /* from which siginfo to start */
u32 flags;
s32 nr; /* how may siginfos to take */
};
"nr" has type "s32", because ptrace() returns "long", which has 32 bits
on i386 and a negative values is used for errors.
Currently here is only one flag PTRACE_PEEKSIGINFO_SHARED for dumping
signals from process-wide queue. If this flag is not set, signals are
read from a per-thread queue.
The request PTRACE_PEEKSIGINFO returns a number of dumped signals. If a
signal with the specified sequence number doesn't exist, ptrace returns
zero. The request returns an error, if no signal has been dumped.
Errors:
EINVAL - one or more specified flags are not supported or nr is negative
EFAULT - buf or addr is outside your accessible address space.
A result siginfo contains a kernel part of si_code which usually
striped, but it's required for queuing the same siginfo back during
(Continue reading)
25 Feb 2013 11:06
[PATCH] ptrace: add ability to retrieve signals without removing from a queue (v2)
This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
This request is used to retrieve information about signals starting with
the specified sequence number. Siginfo_t structures are copied from the
child into the buffer starting at "data".
The argument "addr" is a pointer to struct ptrace_peeksiginfo_args.
struct ptrace_peeksiginfo_args {
u64 off; /* from which siginfo to start */
u32 nr; /* how may siginfos to take */
u32 flags;
};
Currently here is only one flag PTRACE_PEEKSIGINFO_SHARED for dumping
signals from process-wide shared queue. If this flag is not set, a
signal is read from a per-thread queue. A result siginfo contains a
kernel part of si_code which usually striped, but it's required for
queuing the same siginfo back during restore of pending signals.
The request PTRACE_PEEKSIGINFO returns a number of dumped signals.
If a signal with the specified sequence number doesn't exist, ptrace
returns 0.
This functionality is required for checkpointing pending signals.
The prototype of this code was developed by Oleg Nesterov.
v2: * don't wrapped on CONFIG_CHECKPOINT_RESTORE. This functionality is
going to be used in gdb.
* use ptrace_peeksiginfo_args, because addr is too small for
(Continue reading)
19 Feb 2013 18:53
Re: [PATCH] ptrace: add ability to retrieve signals without removing them from a queue
On 02/19/2013 04:15 PM, Michael Kerrisk (man-pages) wrote: > On Wed, Feb 13, 2013 at 4:16 PM, Andrey Vagin <avagin@...> wrote: >> This patch adds a new ptrace request PTRACE_PEEKSIGINFO. >> >> This request is used to retrieve information about a signal with the >> specified sequence number. A siginfo_t structure is copied from the child >> to location data in the parent. >> >> The low 16 bits of addr contains a sequence number of signal in a queue: > > I think 16 bits is probably not enough.... Already, on the "out of the > box" system that I have at hand, one can queue more than 2^16-1 > signals: > > $ cat /proc/$$/status | grep SigQ > SigQ: 2/126065 Yup :( Well, actually it would be enough to have only 1 bit as "flags" and the rest (31 at least) for the number. But taking into account Oleg's wish to have an ability to extend the amount of flags in the future, we should make addr point to something like struct siginfo_peek_options { unsigned int flags; unsigned int pos; }; and force flags to contain zero in all the bits but one, and this latter bit is to select between private or shared queue. In this case the patch loses its main advantage -- the simplicity.(Continue reading)
RSS Feed