<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git, branch v2.6.27.9</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Linux 2.6.27.9</title>
<updated>2008-12-13T23:56:16+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2008-12-13T23:56:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5defaf81d28daf50c6b148fa6d482cb7e0e61d73'/>
<id>5defaf81d28daf50c6b148fa6d482cb7e0e61d73</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>ib700wdt.c - fix buffer_underflow bug</title>
<updated>2008-12-13T23:29:36+00:00</updated>
<author>
<name>Wim Van Sebroeck</name>
<email>wim@iguana.be</email>
</author>
<published>2008-10-15T08:53:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c6e9f8086227d824a45de8b0d9f626d66a30c6b0'/>
<id>c6e9f8086227d824a45de8b0d9f626d66a30c6b0</id>
<content type='text'>
commit 7c2500f17d65092d93345f3996cf82ebca17e9ff upstream.

This fixes Bug 11399:
if ibwdt_set_heartbeat(int t) is called with value 30 then
the check "if ((t &lt; 0) || (t &gt; 30))" in ibwdt_set_heartbeat
is not going to fail because t == 30, but in the loop, the
check wd_times[i] &gt; t is never going to be true because
none of the wd_times are greater than the value of t (i.e. 30).
So we are exiting the loop with i == -1 and therefore setting
wd_margin to -1 which is wrong.

Reported-by: Zvonimir Rakamaric &lt;zrakamar@cs.ubc.ca&gt;
Signed-off-by: Wim Van Sebroeck &lt;wim@iguana.be&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7c2500f17d65092d93345f3996cf82ebca17e9ff upstream.

This fixes Bug 11399:
if ibwdt_set_heartbeat(int t) is called with value 30 then
the check "if ((t &lt; 0) || (t &gt; 30))" in ibwdt_set_heartbeat
is not going to fail because t == 30, but in the loop, the
check wd_times[i] &gt; t is never going to be true because
none of the wd_times are greater than the value of t (i.e. 30).
So we are exiting the loop with i == -1 and therefore setting
wd_margin to -1 which is wrong.

Reported-by: Zvonimir Rakamaric &lt;zrakamar@cs.ubc.ca&gt;
Signed-off-by: Wim Van Sebroeck &lt;wim@iguana.be&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>applicom: Fix an unchecked user ioctl range and an error return</title>
<updated>2008-12-13T23:29:36+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@redhat.com</email>
</author>
<published>2008-10-13T09:45:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c832f62d3d057abfc1125621c80ede5840cf7aef'/>
<id>c832f62d3d057abfc1125621c80ede5840cf7aef</id>
<content type='text'>
commit a7be18d436f0c7007794965e5af29fa1ffff1e05 upstream.

Closes bug #11408 by checking the card index range for command 0
Fixes the ioctl to return ENOTTY which is correct for unknown ioctls

Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a7be18d436f0c7007794965e5af29fa1ffff1e05 upstream.

Closes bug #11408 by checking the card index range for command 0
Fixes the ioctl to return ENOTTY which is correct for unknown ioctls

Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>XFS: Fix hang after disallowed rename across directory quota domains</title>
<updated>2008-12-13T23:29:35+00:00</updated>
<author>
<name>Dave Chinner</name>
<email>david@fromorbit.com</email>
</author>
<published>2008-12-03T22:09:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b1e58876b39029fb4f1b49504ba01f5454428878'/>
<id>b1e58876b39029fb4f1b49504ba01f5454428878</id>
<content type='text'>
commit 576a488a27f267af203f3ea69c700a1612335e9f upstream.

When project quota is active and is being used for directory tree
quota control, we disallow rename outside the current directory
tree. This requires a check to be made after all the inodes
involved in the rename are locked. We fail to unlock the inodes
correctly if we disallow the rename when the target is outside the
current directory tree. This results in a hang on the next access
to the inodes involved in failed rename.

Reported-by: Arkadiusz Miskiewicz &lt;arekm@maven.pl&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;
Tested-by: Arkadiusz Miskiewicz &lt;arekm@maven.pl&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 576a488a27f267af203f3ea69c700a1612335e9f upstream.

When project quota is active and is being used for directory tree
quota control, we disallow rename outside the current directory
tree. This requires a check to be made after all the inodes
involved in the rename are locked. We fail to unlock the inodes
correctly if we disallow the rename when the target is outside the
current directory tree. This results in a hang on the next access
to the inodes involved in failed rename.

Reported-by: Arkadiusz Miskiewicz &lt;arekm@maven.pl&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;
Tested-by: Arkadiusz Miskiewicz &lt;arekm@maven.pl&gt;
Signed-off-by: Lachlan McIlroy &lt;lachlan@sgi.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc: Use cpu_thread_in_core in smp_init for of_spin_map</title>
<updated>2008-12-13T23:29:35+00:00</updated>
<author>
<name>Milton Miller</name>
<email>miltonm@bga.com</email>
</author>
<published>2008-10-20T15:37:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ec9ea180923639380683ebb52d135bc01959f2b1'/>
<id>ec9ea180923639380683ebb52d135bc01959f2b1</id>
<content type='text'>
commit 6a75a6b8e85e92cc774d42a4e113c76c30b5a539 upstream.

We used to assume that even numbered threads were the primary
threads, ie those that would be listed and started as a cpu from
open firmware.  Replace a left over is even (% 2) check with a check
for it being a primary thread and update the comments.

Tested with a debug print on pseries, identical code found for cell.

Signed-off-by: Milton Miller &lt;miltonm@bga.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6a75a6b8e85e92cc774d42a4e113c76c30b5a539 upstream.

We used to assume that even numbered threads were the primary
threads, ie those that would be listed and started as a cpu from
open firmware.  Replace a left over is even (% 2) check with a check
for it being a primary thread and update the comments.

Tested with a debug print on pseries, identical code found for cell.

Signed-off-by: Milton Miller &lt;miltonm@bga.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>pnp: make the resource type an unsigned long</title>
<updated>2008-12-13T23:29:34+00:00</updated>
<author>
<name>Rene Herman</name>
<email>rene.herman@keyaccess.nl</email>
</author>
<published>2008-10-16T05:03:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c53129f96b5f2d7fa3979d39a9b641bafec430b9'/>
<id>c53129f96b5f2d7fa3979d39a9b641bafec430b9</id>
<content type='text'>
commit b563cf59c4d67da7d671788a9848416bfa4180ab upstream.

PnP encodes the resource type directly as its struct resource-&gt;flags value
which is an unsigned long.  Make it so...

Signed-off-by: Rene Herman &lt;rene.herman@gmail.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Acked-by: Bjorn Helgaas &lt;bjorn.helgaas@hp.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b563cf59c4d67da7d671788a9848416bfa4180ab upstream.

PnP encodes the resource type directly as its struct resource-&gt;flags value
which is an unsigned long.  Make it so...

Signed-off-by: Rene Herman &lt;rene.herman@gmail.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Acked-by: Bjorn Helgaas &lt;bjorn.helgaas@hp.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cifs: fix a regression in cifs umount codepath</title>
<updated>2008-12-13T23:29:34+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2008-12-10T11:44:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=39493f2809c5d4ee52ab118e0197644ad9490d13'/>
<id>39493f2809c5d4ee52ab118e0197644ad9490d13</id>
<content type='text'>
backport of 469ee614aaa367d9cde01cbdd2027212f56c6cc6 upstream.

Several cifs patches were added to 2.6.27.8 to fix some races in the
mount/umount codepath. When this was done, a couple of prerequisite
patches were missed causing a minor regression.

When the last cifs mount to a server goes away, the kthread that manages
the socket is supposed to come down. The patches that went into 2.6.27.8
removed the kthread_stop calls that used to take down these threads, but
left the thread function expecting them. This made the thread stay up
even after the last mount was gone.

This patch should fix up this regression and also prevent a possible
race where a dead task could be signalled.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Cc: Suresh Jayaraman &lt;sjayaraman@suse.de&gt;
Acked-by: Steve French &lt;smfrench@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
backport of 469ee614aaa367d9cde01cbdd2027212f56c6cc6 upstream.

Several cifs patches were added to 2.6.27.8 to fix some races in the
mount/umount codepath. When this was done, a couple of prerequisite
patches were missed causing a minor regression.

When the last cifs mount to a server goes away, the kthread that manages
the socket is supposed to come down. The patches that went into 2.6.27.8
removed the kthread_stop calls that used to take down these threads, but
left the thread function expecting them. This made the thread stay up
even after the last mount was gone.

This patch should fix up this regression and also prevent a possible
race where a dead task could be signalled.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Cc: Suresh Jayaraman &lt;sjayaraman@suse.de&gt;
Acked-by: Steve French &lt;smfrench@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: delete OSI(Linux) DMI dmesg spam</title>
<updated>2008-12-13T23:29:34+00:00</updated>
<author>
<name>Len Brown</name>
<email>lenb@kernel.org</email>
</author>
<published>2008-12-08T21:03:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=631867888f51ec9dc40bc8f7cb43cc39a6892158'/>
<id>631867888f51ec9dc40bc8f7cb43cc39a6892158</id>
<content type='text'>
In 2.6.28 a6e0887f21bbab337ee32d9c0a84d7c0b6e9141b removed this code
because the linux-acpi community no longer needs the feedback
that these console messages solicit.

here in .stable, we apply a simpler version of that patch,
but for the exact same reasons.

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In 2.6.28 a6e0887f21bbab337ee32d9c0a84d7c0b6e9141b removed this code
because the linux-acpi community no longer needs the feedback
that these console messages solicit.

here in .stable, we apply a simpler version of that patch,
but for the exact same reasons.

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/virtex5: Fix Virtex5 machine check handling</title>
<updated>2008-12-13T23:29:34+00:00</updated>
<author>
<name>Grant Likely</name>
<email>grant.likely@secretlab.ca</email>
</author>
<published>2008-12-04T05:39:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1d3bac578875da221abaabc7beba5f1d4f316acb'/>
<id>1d3bac578875da221abaabc7beba5f1d4f316acb</id>
<content type='text'>
commit 640d17d60e83401e10e66a0ab6e9e2d6350df656 upstream.

The 440x5 core in the Virtex5 uses the 440A type machine check
(ie, they have MCSRR0/MCSRR1). They thus need to call the
appropriate fixup function to hook the right variant of the
exception.

Without this, all machine checks become fatal due to loss
of context when entering the exception handler.

Signed-off-by: Grant Likely &lt;grant.likely@secretlab.ca&gt;
Signed-off-by: Josh Boyer &lt;jwboyer@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 640d17d60e83401e10e66a0ab6e9e2d6350df656 upstream.

The 440x5 core in the Virtex5 uses the 440A type machine check
(ie, they have MCSRR0/MCSRR1). They thus need to call the
appropriate fixup function to hook the right variant of the
exception.

Without this, all machine checks become fatal due to loss
of context when entering the exception handler.

Signed-off-by: Grant Likely &lt;grant.likely@secretlab.ca&gt;
Signed-off-by: Josh Boyer &lt;jwboyer@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tracehook: exec double-reporting fix</title>
<updated>2008-12-13T23:29:34+00:00</updated>
<author>
<name>Roland McGrath</name>
<email>roland@redhat.com</email>
</author>
<published>2008-12-10T03:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0501da32b55823305835b43af5a8eb8c48e8406b'/>
<id>0501da32b55823305835b43af5a8eb8c48e8406b</id>
<content type='text'>
commit 85f334666a771680472722eee43ae0fc8730a619 upstream.

The patch 6341c39 "tracehook: exec" introduced a small regression in
2.6.27 regarding binfmt_misc exec event reporting.  Since the reporting
is now done in the common search_binary_handler() function, an exec
of a misc binary will result in two (or possibly multiple) exec events
being reported, instead of just a single one, because the misc handler
contains a recursive call to search_binary_handler.

To add to the confusion, if PTRACE_O_TRACEEXEC is not active, the multiple
SIGTRAP signals will in fact cause only a single ptrace intercept, as the
signals are not queued.  However, if PTRACE_O_TRACEEXEC is on, the debugger
will actually see multiple ptrace intercepts (PTRACE_EVENT_EXEC).

The test program included below demonstrates the problem.

This change fixes the bug by calling tracehook_report_exec() only in the
outermost search_binary_handler() call (bprm-&gt;recursion_depth == 0).

The additional change to restore bprm-&gt;recursion_depth after each binfmt
load_binary call is actually superfluous for this bug, since we test the
value saved on entry to search_binary_handler().  But it keeps the use of
of the depth count to its most obvious expected meaning.  Depending on what
binfmt handlers do in certain cases, there could have been false-positive
tests for recursion limits before this change.

    /* Test program using PTRACE_O_TRACEEXEC.
       This forks and exec's the first argument with the rest of the arguments,
       while ptrace'ing.  It expects to see one PTRACE_EVENT_EXEC stop and
       then a successful exit, with no other signals or events in between.

       Test for kernel doing two PTRACE_EVENT_EXEC stops for a binfmt_misc exec:

       $ gcc -g traceexec.c -o traceexec
       $ sudo sh -c 'echo :test:M::foobar::/bin/cat: &gt; /proc/sys/fs/binfmt_misc/register'
       $ echo 'foobar test' &gt; ./foobar
       $ chmod +x ./foobar
       $ ./traceexec ./foobar; echo $?
       ==&gt; good &lt;==
       foobar test
       0
       $
       ==&gt; bad &lt;==
       foobar test
       unexpected status 0x4057f != 0
       3
       $

    */

    #include &lt;stdio.h&gt;
    #include &lt;sys/types.h&gt;
    #include &lt;sys/wait.h&gt;
    #include &lt;sys/ptrace.h&gt;
    #include &lt;unistd.h&gt;
    #include &lt;signal.h&gt;
    #include &lt;stdlib.h&gt;

    static void
    wait_for (pid_t child, int expect)
    {
      int status;
      pid_t p = wait (&amp;status);
      if (p != child)
	{
	  perror ("wait");
	  exit (2);
	}
      if (status != expect)
	{
	  fprintf (stderr, "unexpected status %#x != %#x\n", status, expect);
	  exit (3);
	}
    }

    int
    main (int argc, char **argv)
    {
      pid_t child = fork ();

      if (child &lt; 0)
	{
	  perror ("fork");
	  return 127;
	}
      else if (child == 0)
	{
	  ptrace (PTRACE_TRACEME);
	  raise (SIGUSR1);
	  execv (argv[1], &amp;argv[1]);
	  perror ("execve");
	  _exit (127);
	}

      wait_for (child, W_STOPCODE (SIGUSR1));

      if (ptrace (PTRACE_SETOPTIONS, child,
		  0L, (void *) (long) PTRACE_O_TRACEEXEC) != 0)
	{
	  perror ("PTRACE_SETOPTIONS");
	  return 4;
	}

      if (ptrace (PTRACE_CONT, child, 0L, 0L) != 0)
	{
	  perror ("PTRACE_CONT");
	  return 5;
	}

      wait_for (child, W_STOPCODE (SIGTRAP | (PTRACE_EVENT_EXEC &lt;&lt; 8)));

      if (ptrace (PTRACE_CONT, child, 0L, 0L) != 0)
	{
	  perror ("PTRACE_CONT");
	  return 6;
	}

      wait_for (child, W_EXITCODE (0, 0));

      return 0;
    }

Reported-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
CC: Ulrich Weigand &lt;ulrich.weigand@de.ibm.com&gt;
Signed-off-by: Roland McGrath &lt;roland@redhat.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 85f334666a771680472722eee43ae0fc8730a619 upstream.

The patch 6341c39 "tracehook: exec" introduced a small regression in
2.6.27 regarding binfmt_misc exec event reporting.  Since the reporting
is now done in the common search_binary_handler() function, an exec
of a misc binary will result in two (or possibly multiple) exec events
being reported, instead of just a single one, because the misc handler
contains a recursive call to search_binary_handler.

To add to the confusion, if PTRACE_O_TRACEEXEC is not active, the multiple
SIGTRAP signals will in fact cause only a single ptrace intercept, as the
signals are not queued.  However, if PTRACE_O_TRACEEXEC is on, the debugger
will actually see multiple ptrace intercepts (PTRACE_EVENT_EXEC).

The test program included below demonstrates the problem.

This change fixes the bug by calling tracehook_report_exec() only in the
outermost search_binary_handler() call (bprm-&gt;recursion_depth == 0).

The additional change to restore bprm-&gt;recursion_depth after each binfmt
load_binary call is actually superfluous for this bug, since we test the
value saved on entry to search_binary_handler().  But it keeps the use of
of the depth count to its most obvious expected meaning.  Depending on what
binfmt handlers do in certain cases, there could have been false-positive
tests for recursion limits before this change.

    /* Test program using PTRACE_O_TRACEEXEC.
       This forks and exec's the first argument with the rest of the arguments,
       while ptrace'ing.  It expects to see one PTRACE_EVENT_EXEC stop and
       then a successful exit, with no other signals or events in between.

       Test for kernel doing two PTRACE_EVENT_EXEC stops for a binfmt_misc exec:

       $ gcc -g traceexec.c -o traceexec
       $ sudo sh -c 'echo :test:M::foobar::/bin/cat: &gt; /proc/sys/fs/binfmt_misc/register'
       $ echo 'foobar test' &gt; ./foobar
       $ chmod +x ./foobar
       $ ./traceexec ./foobar; echo $?
       ==&gt; good &lt;==
       foobar test
       0
       $
       ==&gt; bad &lt;==
       foobar test
       unexpected status 0x4057f != 0
       3
       $

    */

    #include &lt;stdio.h&gt;
    #include &lt;sys/types.h&gt;
    #include &lt;sys/wait.h&gt;
    #include &lt;sys/ptrace.h&gt;
    #include &lt;unistd.h&gt;
    #include &lt;signal.h&gt;
    #include &lt;stdlib.h&gt;

    static void
    wait_for (pid_t child, int expect)
    {
      int status;
      pid_t p = wait (&amp;status);
      if (p != child)
	{
	  perror ("wait");
	  exit (2);
	}
      if (status != expect)
	{
	  fprintf (stderr, "unexpected status %#x != %#x\n", status, expect);
	  exit (3);
	}
    }

    int
    main (int argc, char **argv)
    {
      pid_t child = fork ();

      if (child &lt; 0)
	{
	  perror ("fork");
	  return 127;
	}
      else if (child == 0)
	{
	  ptrace (PTRACE_TRACEME);
	  raise (SIGUSR1);
	  execv (argv[1], &amp;argv[1]);
	  perror ("execve");
	  _exit (127);
	}

      wait_for (child, W_STOPCODE (SIGUSR1));

      if (ptrace (PTRACE_SETOPTIONS, child,
		  0L, (void *) (long) PTRACE_O_TRACEEXEC) != 0)
	{
	  perror ("PTRACE_SETOPTIONS");
	  return 4;
	}

      if (ptrace (PTRACE_CONT, child, 0L, 0L) != 0)
	{
	  perror ("PTRACE_CONT");
	  return 5;
	}

      wait_for (child, W_STOPCODE (SIGTRAP | (PTRACE_EVENT_EXEC &lt;&lt; 8)));

      if (ptrace (PTRACE_CONT, child, 0L, 0L) != 0)
	{
	  perror ("PTRACE_CONT");
	  return 6;
	}

      wait_for (child, W_EXITCODE (0, 0));

      return 0;
    }

Reported-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
CC: Ulrich Weigand &lt;ulrich.weigand@de.ibm.com&gt;
Signed-off-by: Roland McGrath &lt;roland@redhat.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
