gmane.linux.kernel.api

Grant Donation!!!

Adrian & Gillian Bayford — 2013-05-19T23:02:10

We are donating 1.5million pounds to you, Send Name, Country, Mobile Number, Sex, Age, Occupation for more details.

Re: [PATCH 1/1] posix-timers: Show clock ID in proc file

Greg KH — 2013-05-17T16:22:06

Ok, just making sure :)

Re: [PATCH 1/1] posix-timers: Show clock ID in proc file

Pavel Emelyanov — 2013-05-17T16:10:35


Acked-by: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ< at >public.gmane.org>

Re: [PATCH 1/1] posix-timers: Show clock ID in proc file

Greg KH — 2013-05-17T15:59:16

What userspace tool just broke by adding a new field to this file?

thanks,

greg k-h

[PATCH 1/1] posix-timers: Show clock ID in proc file

Pavel Tikhomirov — 2013-05-16T22:12:03

Expand information about posix-timers in /proc/<pid>/timers by adding
info about clock, with which the timer was created. I.e. in the forth
line of timer info after "notify:" line go "ClockID: <clock_id>".

Signed-off-by: Pavel Tikhomirov <snorcht-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
---
 fs/proc/base.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 2dad4a9..8a38eef 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
< at >< at > -2079,6 +2079,7 < at >< at > static int show_timer(struct seq_file *m, void *v)
 nstr[notify & ~SIGEV_THREAD_ID],
 (notify & SIGEV_THREAD_ID) ? "tid" : "pid",
 pid_nr_ns(timer->it_pid, tp->ns));
+seq_printf(m, "ClockID: %d\n", timer->it_clock);
 
 return 0;
 }

[PATCH 0/1] posix timers: Expand exitsting info in proc file

Pavel Tikhomirov — 2013-05-16T22:12:02

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(+)

Re: [PATCH 0/3] posix timers: Extend kernel API to report more info about timers (v3)

Pavel Emelyanov — 2013-04-11T11:56:27

Dear Sirs,

Any feedback on this set will be highly appreciated.

Yours sincerely,
Pavel

How about allowing ptracing processes in the TASK_UNINTERRUPTIBLE state?

Jann Horn — 2013-03-22T11:47:39

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 amou

Info

Margaret Jones — 2013-03-12T21:19:44

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-mawtdLnHQX0aKw7/G3svNvXRex20P6io< at >public.gmane.org

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

[PATCH 3/3] posix-timers: Show sigevent info in proc file

Pavel Emelyanov — 2013-03-11T09:13:08

Previous patch added proc file to list posix timers created by task.
Expand the information provided in this file by adding info about
notification method, with which timers were created. I.e. after
the "ID:" line there go

1. "signal:" line, that shows signal number and sigval bits;
2. "notify:" line, that shows the timer notification method.

Thus the timer entry would looke like this:

ID: 123
signal: 14/0000000000b005d0
notify: signal/pid.732

This information is enough to understand how the timer_create() was
called for each particular timer.

Signed-off-by: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ< at >public.gmane.org>
---
 fs/proc/base.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 01def9f..a193086 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
< at >< at > -2018,6 +2018,7 < at >< at > struct timers_private {
 struct pid *pid;
 struct task_struct *task;
 struct sighand_struct *sighand;
+struct pid_namespace *ns;
 unsigned long flag

[PATCH 2/3] posix-timers: Introduce /proc//timers file

Pavel Emelyanov — 2013-03-11T09:12:45

Currently kernel doesn't provide any API for getting info about
what posix timers are configured by tasks. It's implied, that
task, that configured some timers, knows what it did. However,
for external tools it's impossible to get this information. In
particular, this is critical for checkpoint-restore project to
have this info.

That said, the proposal is to introduce the per-pid proc file
with information about posix timers. Since these timers are shared
between threads, this file is present on tgid level only, no such
thing in tid subdirs.

The file format is expected to be the "/proc/<pid>/smaps"-like,
i.e. each timer will occupy seveal lines to allow for future
extending.

Each new timer entry starts with the

ID: <number>

line which is added by this patch.

Signed-off-by: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ< at >public.gmane.org>
---
 fs/proc/base.c |   83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 83 insertions(+), 0 deletions(-)

diff --git a/fs/proc/base.c b/fs/

[PATCH 1/3] posix timers: Allocate timer id per process (v2)

Pavel Emelyanov — 2013-03-11T09:12:21

Currently kernel generates IDs for posix timers in a global manner --
there's a kernel-wide IDR tree from which IDs are created. This makes
it impossible to recreate a timer with a desired ID (in particulat
this is done by the CRIU checkpoint-restore project) -- since these
IDs are global it may happen, that at the time we recreate a timer, the
ID we want for it is already busy by some other timer.

In order to address this, I'd like to replace the mentioned IDR tree
with global hash table for timers and makes timer IDs unique per
signal_struct (to which timers are linked anyway). With this, two
timers belonging to different tasks may have equal IDs and we can
recreate either of them with ID we want.

Signed-off-by: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ< at >public.gmane.org>
---
 include/linux/posix-timers.h |    1 +
 include/linux/sched.h        |    3 +-
 kernel/posix-timers.c        |  106 +++++++++++++++++++++++++++---------------
 3 files changed, 72 insertions(+), 38 deletions(-)

diff --git a/incl

[PATCH 0/3] posix timers: Extend kernel API to report more info about timers (v3)

Pavel Emelyanov — 2013-03-11T09:11:53

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

Greetings from George Daniels

Germaine Sandoval — 2013-03-10T21:42:36


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-VpKtJLNTnGPuFKmmi/icCA< at >public.gmane.org Have a pleasant day.

George Daniels

Re: [PATCH 1/3] posix timers: Allocate timer id per process (v2)

Thomas Gleixner — 2013-03-08T12:50:28

Pavel,

On Thu, 21 Feb 2013, Pavel Emelyanov wrote:


I think the patches are ready to go, though the changelog needs quite
some care.

It's explaining what the patch does and not why. Can you please
rework?

Thanks,

tglx

Re: [PATCH 0/3] posix timers: Extend kernel API to report more info about timers (v2)

Thomas Gleixner — 2013-03-08T09:56:39


Sir,

that caught my attention. Will move it up on my todo list :)

Re: [PATCH 0/3] posix timers: Extend kernel API to report more info about timers (v2)

Pavel Emelyanov — 2013-03-08T08:40:41

Gentlemen,

If you don't mind, I'd like to remind you about this set :) If you could
find some time in your schedule and share your thoughts about one, it would
be appreciated!

Thank you.

[PATCH 2/2] selftest: add a test case for PTRACE_PEEKSIGINFO

Andrey Vagin — 2013-03-04T10:46:35

* Dump signals from process-wide and per-thread queues with
  different sizes of buffers.
* Check error paths for buffers with restricted permissions. A part of
  buffer or a whole buffer is for read-only.
* Try to get nonexistent signal.

Cc: Roland McGrath <roland-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b< at >public.gmane.org>
Cc: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8< at >public.gmane.org>
Cc: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Cc: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
Cc: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ< at >public.gmane.org>
Cc: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b< at >public.gmane.org>
Cc: Pedro Alves <palves-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
Signed-off-by: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A

[PATCH 1/2] ptrace: add ability to retrieve signals without removing from a queue (v4)

Andrey Vagin — 2013-03-04T10:46:34

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 support

Private message

JMW SOLICITORS LLP — 2013-03-03T20:12:22

I am the Family lawyer of late James Campbell, My late client bequeathed his inheritance to you, i request your urgent response to this Issue.
Barr Colin Lee

Re: [PATCH 1/2] ptrace: add ability to retrieve signals withoutremoving from a queue (v3)

Oleg Nesterov — 2013-02-27T18:38:50

Cough... You are optimist. You want to handle the case when the
tracee has 1 << 33 or more pending sigqueues. OK good luck ;)

Looks correct, just one nit.


Imho, this is confusing. Just do

for (i = 0; i < arg.nr; ) {
...

data += sizeof(siginfo_t);
i++;

if (signal_pending(current))
break;

Oleg.