From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH] ptrace: add ability to retrieve signals without removing them from a queue Date: Tue, 19 Feb 2013 23:47:34 +0400 Message-ID: <5123D6D6.7010904@parallels.com> References: <1360768595-31943-1-git-send-email-avagin@openvz.org> <5123BC20.9040405@parallels.com> <20130219193424.GA9606@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130219193424.GA9606-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Oleg Nesterov Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Andrey Vagin , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Roland McGrath , Andrew Morton , "Paul E. McKenney" , David Howells , Dave Jones , Linus Torvalds List-Id: linux-api@vger.kernel.org On 02/19/2013 11:34 PM, Oleg Nesterov wrote: > On 02/19, Pavel Emelyanov wrote: >> >> On 02/19/2013 04:15 PM, Michael Kerrisk (man-pages) wrote: >>> On Wed, Feb 13, 2013 at 4:16 PM, Andrey Vagin 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 > > I am not sure this is really needed, and we can add more PTRACE_PEEK_ > codes later. I am fine either way, we can even add PEEK_PRIVATE/SHARED > right now. > > But, given that every PEEK does list_for_each() until it finds the > necessary sequence number, I am wondering how this O(n**2) will work > if you want to dump 126065 signals ;) Isn't it the great reason for making the addr point to a structure, that would look like struct siginfo_peek_arg { unsigned flags; /* all bits but 0th, that selects between private/shared queues, should be zero */ unsigned int off; /* from which siginfo to start */ unsigned int nr; /* how may siginfos to take */ }; ? :) > Oleg. > > . Thanks, Pavel