ptrace(2): wrong kernel version for PTRACE_SEIZE and others

ptrace(2): wrong kernel version for PTRACE_SEIZE and others

[Patrick Donnelly]

The ptrace(2) man page says that PTRACE_SEIZE, PTRACE_LISTEN, and
PTRACE_INTERRUPT was introduced in Linux 3.4. In fact, this was added
in 3.1:

$ git diff v3.0 v3.1 include/linux/ptrace.h | grep SEIZE
+#define PTRACE_SEIZE           0x4206
+/* flags in @data for PTRACE_SEIZE */
+#define PTRACE_SEIZE_DEVEL     0x80000000 /* temp flag for development */
+#define PT_SEIZED      0x00010000      /* SEIZE used, enable new behavior */
+               if (child->ptrace & PT_SEIZED)


-- 
Patrick Donnelly
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ptrace(2): wrong kernel version for PTRACE_SEIZE and others

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Fri, Mar 18, 2016 at 05:21:28PM -0400, Patrick Donnelly wrote:
> The ptrace(2) man page says that PTRACE_SEIZE, PTRACE_LISTEN, and
> PTRACE_INTERRUPT was introduced in Linux 3.4. In fact, this was added
> in 3.1:
> 
> $ git diff v3.0 v3.1 include/linux/ptrace.h | grep SEIZE
> +#define PTRACE_SEIZE           0x4206
> +/* flags in @data for PTRACE_SEIZE */
> +#define PTRACE_SEIZE_DEVEL     0x80000000 /* temp flag for development */

Yes, PTRACE_SEIZE was introduced by commit v3.1-rc1~308^2~28, but
it had to be used along with a temporary flag PTRACE_SEIZE_DEVEL,
which was removed later by commit v3.4-rc1~109^2~20.

That is, between v3.0 and v3.4 we had a test mode of PTRACE_SEIZE API,
which was not compatible with the current PTRACE_SEIZE API introduced
in Linux 3.4.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: ptrace(2): wrong kernel version for PTRACE_SEIZE and others

[Michael Kerrisk (man-pages)]

Hi Dmitry,

On 23 March 2016 at 00:16, Dmitry V. Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> wrote:
> On Fri, Mar 18, 2016 at 05:21:28PM -0400, Patrick Donnelly wrote:
>> The ptrace(2) man page says that PTRACE_SEIZE, PTRACE_LISTEN, and
>> PTRACE_INTERRUPT was introduced in Linux 3.4. In fact, this was added
>> in 3.1:
>>
>> $ git diff v3.0 v3.1 include/linux/ptrace.h | grep SEIZE
>> +#define PTRACE_SEIZE           0x4206
>> +/* flags in @data for PTRACE_SEIZE */
>> +#define PTRACE_SEIZE_DEVEL     0x80000000 /* temp flag for development */
>
> Yes, PTRACE_SEIZE was introduced by commit v3.1-rc1~308^2~28, but
> it had to be used along with a temporary flag PTRACE_SEIZE_DEVEL,
> which was removed later by commit v3.4-rc1~109^2~20.
>
> That is, between v3.0 and v3.4 we had a test mode of PTRACE_SEIZE API,
> which was not compatible with the current PTRACE_SEIZE API introduced
> in Linux 3.4.

So, it sounds like the page is good as it stands, right?

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ptrace(2): wrong kernel version for PTRACE_SEIZE and others

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On 28 Mar 2016 16:55, Michael Kerrisk (man-pages) wrote:
> On 23 March 2016 at 00:16, Dmitry V. Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> wrote:
> > On Fri, Mar 18, 2016 at 05:21:28PM -0400, Patrick Donnelly wrote:
> >> The ptrace(2) man page says that PTRACE_SEIZE, PTRACE_LISTEN, and
> >> PTRACE_INTERRUPT was introduced in Linux 3.4. In fact, this was added
> >> in 3.1:
> >>
> >> $ git diff v3.0 v3.1 include/linux/ptrace.h | grep SEIZE
> >> +#define PTRACE_SEIZE           0x4206
> >> +/* flags in @data for PTRACE_SEIZE */
> >> +#define PTRACE_SEIZE_DEVEL     0x80000000 /* temp flag for development */
> >
> > Yes, PTRACE_SEIZE was introduced by commit v3.1-rc1~308^2~28, but
> > it had to be used along with a temporary flag PTRACE_SEIZE_DEVEL,
> > which was removed later by commit v3.4-rc1~109^2~20.
> >
> > That is, between v3.0 and v3.4 we had a test mode of PTRACE_SEIZE API,
> > which was not compatible with the current PTRACE_SEIZE API introduced
> > in Linux 3.4.
> 
> So, it sounds like the page is good as it stands, right?

if the commented source has these details, then yes.  otherwise, might
be good to stash them in the commented block.  i don't think it should
be exposed to the user.

glancing at the source, i'm not seeing a commented block.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: ptrace(2): wrong kernel version for PTRACE_SEIZE and others

[Michael Kerrisk (man-pages)]

Hi Mike,

On 28 March 2016 at 17:30, Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org> wrote:
> On 28 Mar 2016 16:55, Michael Kerrisk (man-pages) wrote:
>> On 23 March 2016 at 00:16, Dmitry V. Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> wrote:
>> > On Fri, Mar 18, 2016 at 05:21:28PM -0400, Patrick Donnelly wrote:
>> >> The ptrace(2) man page says that PTRACE_SEIZE, PTRACE_LISTEN, and
>> >> PTRACE_INTERRUPT was introduced in Linux 3.4. In fact, this was added
>> >> in 3.1:
>> >>
>> >> $ git diff v3.0 v3.1 include/linux/ptrace.h | grep SEIZE
>> >> +#define PTRACE_SEIZE           0x4206
>> >> +/* flags in @data for PTRACE_SEIZE */
>> >> +#define PTRACE_SEIZE_DEVEL     0x80000000 /* temp flag for development */
>> >
>> > Yes, PTRACE_SEIZE was introduced by commit v3.1-rc1~308^2~28, but
>> > it had to be used along with a temporary flag PTRACE_SEIZE_DEVEL,
>> > which was removed later by commit v3.4-rc1~109^2~20.
>> >
>> > That is, between v3.0 and v3.4 we had a test mode of PTRACE_SEIZE API,
>> > which was not compatible with the current PTRACE_SEIZE API introduced
>> > in Linux 3.4.
>>
>> So, it sounds like the page is good as it stands, right?
>
> if the commented source has these details, then yes.  otherwise, might
> be good to stash them in the commented block.

Yes, that seems a wise idea. Done.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html