We (the -stable team) are announcing the release of the 2.6.25.10

kernel.
It contains a number of assorted bugfixes all over the tree.  And once

again, any users of the 2.6.25 kernel series are STRONGLY encouraged to

upgrade to this release.
I'll also be replying to this message with a copy of the patch between

2.6.25.9 and 2.6.25.10
The updated 2.6.25.y git tree can be found at:

        git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git

and can be browsed at the normal kernel.org git web browser:

        http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=su...
thanks,
greg k-h
-------------
 Makefile                                    |    2

 arch/x86/kernel/i387.c                      |    4 -

 arch/x86/kernel/ptrace.c                    |   45 +++++++------

 arch/x86/kernel/smpboot_64.c                |    1

 drivers/char/drm/i915_drv.c                 |    1

 drivers/infiniband/hw/mthca/mthca_memfree.c |    6 +

 drivers/net/hamradio/6pack.c                |    2

 drivers/net/hamradio/mkiss.c                |    8 +-

 drivers/net/irda/irtty-sir.c                |    4 -

 drivers/net/ppp_async.c                     |    3

 drivers/net/ppp_synctty.c                   |    3

 drivers/net/slip.c                          |   14 +++-

 drivers/net/wan/x25_asy.c                   |   10 ++-

 drivers/net/wireless/strip.c                |    3

 include/asm-x86/msr.h                       |    2

 kernel/futex.c                              |   93 +++++++++++++++++++++-------

 kernel/sched.c                              |    1

 17 files changed, 147 insertions(+), 55 deletions(-)
Alan Cox (1):

      TTY: fix for tty operations bugs
Dmitry Adamushko (1):

      sched: fix cpu hotplug
Eli Cohen (1):

      IB/mthca: Clear ICM pages before handing to FW
Greg Kroah-Hartman (1):

      Linux 2.6.25.10
Jie Luo (1):

      DRM: enable bus mastering on i915 at resume time
Max Asbock (1):

      x86: shift bits the ...
[ message continues ]

Hello Greg,
Thanks for all the work you and the stable team are doing on the

stable series. To me the above message is a little bit cryptic however

-- which bugs have been fixed, and what was their impact ? I know it

takes time to write down such information, sometimes called release

notes. But I think including this information with the announcements

of the stable releases would be a great service to the people reading

these announcements.
Bart.

--

The release notes are there in the shortlog in the email announcement

and full Changelog on the kernel.org site for exactly what specifically

was fixed:

	http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.10
If you have any specific questions about any of the individual changes,

please let us, and the developers who made those fixes know.
thanks,
greg k-h

--

Sometimes I have to backport bugfixes to older kernels. In that case

it's important to know in which kernel version the bug was introduced.

This info is included for some of the bugfix patches in the changelog,

but not for all.
Bart.

--

That's because sometimes no one digs through the code to find this out.

I would recommend using 'git blame' to determine this if it is something

that you need to have.
But for the most part, -stable doesn't really care about older kernel

versions, we have to draw the line somewhere, sorry.
thanks,
greg k-h

--

Adding 2 more addresses to this thread, as they were said to have

questions about this kernel release.
Again, if the above information is somehow insufficient as to what

exactly is fixed in the -stable releases, and anyone has questions about

how these release announcements are created, please let me know.
thanks,
greg k-h

--

[spender's asked to be off the CC]
not only this one, but every commit for the past few years that fixed

bugs with security impact. for reference:
http://lwn.net/Articles/285438/

http://lwn.net/Articles/286263/

http://lwn.net/Articles/287339/
what is the disclosure policy used for commits fixing bugs with security

impact (both vanilla and -stable, especially if there's a difference)?
what do you include/omit?
how does it relate to what is declared in Documentation/SecurityBugs?
--

Sorry for the delay, was on vacation...
As I'm somewhere there is no web access, mind summarizing these if they
Personally, I omit posting full "and here is explicitly how to exploit

this problem" notices as that is foolish.
But also remember that -stable releases are just a compilation of

patches that developers have sent to the stable developers, we use the

original commit messages as published in the main kernel tree, except

where the patch differs, which is rare.  So it's not like these releases

are any different than the main kernel releases on descriptions of
That deals with how security bugs that are sent to security@kernel.org

are handled, which is totally different from -stable releases, right?
thanks,
greg k-h

--

That means only people with the time, energy, and expertise to create an

exploit will have an exploit. This includes probably 90% of the people who

would use the exploit maliciously and 100% of the people who pose a real

thread to the community. It does, however, ensure that the majority of

ordinary users won't be able to test their systems to see if they're

vulnerable or if the vulnerability is fixed. So at least it will have some

effect.
DS
--

haven't you ever heard of script-kiddies? they are by far the majority of

attacks on systems but do not have the expertise to create exploits. it

takes someone else writing the exploit for them and packaging it to make

them a threat.
in the meantime there's a chance for the fix to get propogated out to a

released version and for people to upgrade their systems. providing

exploit code along with the bugfix means that the script kiddies have the

exploit immediatly, but the fix isn't in any released version (not even a 
how many people run exploits against their production systems to 'see if

they are fixed', very few, and those only on strict schedules with lots of

adnvance notice and other safeguards.
David Lang
--

Nobody is saying you should package the exploit. If they need someone else

to package it, they'll still need that. So the question is not if this will

deter script kiddies but whether it will deter the people who package

exploits for them. And from experience, I can tell you that answer is no.

Manys attacks that were believed too difficult for the script kiddies to do

were packaged by people who had the expertise and then used by script
I can tell you how many run exploits against their production systems when

they don't know the exploits exist -- zero. It takes, at a minimum, the

knowledge that an exploit is possible. In the cases being discussed, even

this was withheld.
Fixes will not be widely deployed on a timely basis unless, at an absolute

minimum, it is known that there is an exploitable bug that has been fixed.
DS
--

Obvious exploits are generally written by random "joe hackers" to get a

name. However, most kernel exploits are really complex, and written by

the person who discover them because they're the only ones with enough
People generally don't run kernel exploits on their production systems,

simply because either the exploit works as expected and the system remains

safe, or it fails, and it generally means system crashes, freezes, or will

need a reboot very soon. The same is generally true for proof-of-concepts,

but those tend to touch less things and have less side effects in case of
To be clear, *I* am for telling people that they might be facing a problem

(and for not releasing exploits). This is probably because I work on

slow-moving code that people upgrade once a year or so. I know that when

you're wondering whether you'll upgrade your system after that long, you

need to what it will really fix, otherwise you don't upgrade it. That's

why I include indicators when I have them, whether they are about security,

or stability.
In fact, for people always running latest version and upgrading fast,

having all the details or not does not matter much. But as soon as the

code starts to stabilize, they don't upgrade that often, and they need

justifications for an upgrade. Right now, people running 2.6.25 would

have no reason not to upgrade, considering the variety of fixes each

version still carries. People running 2.4 or 2.6.16 *need* details.

And that's even more true for people maintaining their own kernels

or backporting fixes.
However, there is a point nobody has evocated here about backports.

For a long time I've been annoyed by not finding enough information

in some commit logs. But I finally figured that it was as simple as

asking privately either the reporter or the patch author to get that

sensible information sorted out. So the only remaining hard part of

the problem is to identify possible candidates in the huge patch flow

that 2.6 mainline it. That's true too for pure bugs, ...
[ message continues ]

a collective one, i take it, as noone else bothered to respond either ;).
anyway, you must have been at an interesting place i suppose as you

even managed to slip a mail through a wormhole that somehow arrived
they're very relevant and rather long, you should take your time and read

them whenever you're back on the normal net. or you can do like RMS and
so it's full disclosure for both vanilla and -stable, there's no difference?
now are they totally different or not? ;)
in any case, you say the full disclosure policy applies. what does that mean

for you? does it mean omitting security impact information you know about

(not 'here is a working exploit' but 'this is a buffer overflow' or 'this

is an exploitable bug')? because such omissions have repeatedly occured for

the past many years (you'll find several examples pointed out at those LWN
do you also omit any of the usual security related words, such as, say,

'buffer overflow', 'security' when describing a bug? say, look at today's

2.6.25.11 and its single fix that doesn't say anything about 'security',

heck, not even its announcement does. do you think it's what constitutes
you at least add CVE IDs on occasion, mainline commits are even worse in
yes, the real and more important problem is with the mainline development

itself, you're mostly suffering collateral damage, so to speak. but since

you're also part of that development process, you can't hide behind that.
so guys (meaning not only Greg but Andrew, Linus, et al.), when will you

publicly explain why you're covering up security impact of bugs? and even

more importantly, when will you change your policy or bring your process

in line with what you declared?
cheers,

  PaX Team
--

We went through this discussion a couple of weeks ago, and I had

absolutely zero interest in explaining it again.
I personally don't like embargoes. I don't think they work. That means

that I want to fix things asap. But that also means that there is never a

time when you can "let people know", except when it's not an issue any

more, at which point there is no _point_ in letting people know any more.
So I personally consider security bugs to be just "normal bugs". I don't

cover them up, but I also don't have any reason what-so-ever to think it's

a good idea to track them and announce them as something special. 
So there is no "policy". Nor is it likely to change. 
			Linus

--

The only plausible solution people have found to this problem is

"letting the world know", so everyone involved in the different stages

of IT maintenance can do their part and properly spread the solution

throughout the assets.
Unless you have a better idea, the full-disclosure policy must remain or
Either someone classify and inform it as it is, a *security problem*, or

the issue is likely to pass unnoticed by the majority or to not receive

the necessary attention by the involved parts.
Right. You don't want your developers to be responsible for classifying

bugs towards security. Fine. Even though my intuition and personal

experience tell that the question must be approached by those deeply

involved in the development life-cycle, which, on their side, are

responsible for finding, classifying, advising and fixing the security

issues. This seems appropriate. Further, this appears to be what the big

software houses nowadays do: from early design and development stages,

have people to [security] review their applications before deployment,

up to giving high attention and adequate support to any reported

security problem, afterwards release. Maybe this is all silly and the

world is swimming in the wrong direction.
Opinions apart, what really matters: we have an ultimate declaration

about Linus' tree -- we may forget the pre-official (?) announcement

[Documentation/SecurityBugs] and know that someone else must,

eventually, classify and inform the world about security bugs existent

in their software.

 From our consumer side, every time an issue of this nature is found,

let's pray for some intermediate, gray, angel to send us an "warning"

message.
Not more I can do but to make sure that all my peers are informed of

such a grave reality.
Sincerely,

Tiago
--

The Security Comunity as a whole (especially the commercial service offices

who gat paied to make up new security leaks) is very good in finding,

tracking and classifying bugs. This together with the distributors works
Well, since most often the developers rely on the same source to be notified

about it, its not really a problem.
Gruss

Bernd

--

The only plausible solution people have found to this problem is

"letting the world know", so everyone involved in the different stages

of IT maintenance can do their part and properly spread the solution

throughout the assets.
Unless you have a better idea, the full-disclosure policy must remain or
Either someone classify and inform it as it is, a *security problem*, or

the issue is likely to pass unnoticed by the majority or to not receive

the necessary attention by the involved parts.
Right. You don't want your developers to be responsible for classifying

bugs towards security. Fine. Even though my intuition and personal

experience tell that the question must be approached by those deeply

involved in the development life-cycle, which, on their side, are

responsible for finding, classifying, advising and fixing the security

issues. This seems appropriate. Further, this appears to be what the big

software houses nowadays do: from early design and development stages,

have people to [security] review their applications before deployment,

up to giving high attention and adequate support to any reported

security problem, afterwards release. Maybe this is all silly and the

world is swimming in the wrong direction.
Opinions apart, what really matters: we have an ultimate declaration

about Linus' tree -- we may forget the pre-official (?) announcement

[Documentation/SecurityBugs] and know that someone else must,

eventually, classify and inform the world about security bugs existent

in their software.

 From our consumer side, every time an issue of this nature is found,

let's pray for some intermediate, gray, angel to send us an "warning"

message.
Not more I can do but to make sure that all my peers are informed of

such a grave reality.
Sincerely,

Tiago
--

i don't follow you here. you're making 4 statements essentially:
A. 'i want to fix bugs asap'

B. 'i can let people know only when it's not an issue any more'

C. 'there is no point in letting people know when it's not an issue any more'

D. A implies B and/or C
let's see them one by one.
A: fine and even commendable.
B: that's part of the disclosure policy, so be it, although it raises

   the question of *when* a bug is no longer an issue. when the fix is

   in your git tree? in all/some affected vendor trees? in all affected

   linux trees in existence? or does it depend on when x % of the

   affected machines is running it? what's your criterion?
C: do you realize what you just said? effectively, 'there's no point

   in disclosure'. that's diametrically opposite to what you previously

   argued for (rather vehemently, as vendor-sec readers surely remember).

   to remind yourself of your own words:
     http://lkml.org/lkml/2005/1/12/205

     http://lkml.org/lkml/2005/1/12/363

     http://lkml.org/lkml/2005/1/13/305
   in any case, who decided this? you? did you ask anyone actually

   affected (vendors, users, whatnot)? in case you missed about two

   decades of security problems and their (mis)handling by proprietary

   vendors, this was the *exact* reason why they got shamed repeatedly

   in public (does bugtraq mean anything to you?) and why we have

   public security mailing lists and a whole industry nowadays.
D: this one is a non-sequitur, the timeline (or even willingness) of

   fixing bugs does not imply their disclosure policy. you can surely

   fix a bug independently of telling about it. so the question stays:

   why do you think not disclosing security impact info at all is good,
security bugs aren't just 'normal bugs', the more serious of them

allow to completely break the security model of the kernel. the world

at large has long ago decided that such bugs *are* special and there's

an entire industry dedicated to finding/fixing/exploiting/etc them,...
[ message continues ]

Hi, so I'm guessing you're new to the Linux kernel.  What you are

missing is while *Linus* is unwilling to play the disclosure game,

there are kernel developers (many of whom work for distributions, and

who *do* want some extra time to prepare a package for release to

their customers) who do.  So what Linus has expressed is his personal

opinion, and he is simply is not on any of the various mailing lists

that receive limited-disclosure information, such as the general

vendor-sec@lst.de mailing list, or the security@kernel.org list

mentioned in Documentation/SecurityBugs.
Both vendor-sec and security@kernel.org are not formal organizations,

so they can not sign NDAs, but they will honor non disclosure

requests, and the subscription list for both lists is carefully

controlled.
People like Linus who have a strong, principled stand for Full

Disclosure simply choose not to request to be placed on those mailing

lists.  And if Linus finds out about a security bug, he will fix it

and check it into the public git repository right away.  But he's very

honest in telling you that is what he will do --- so you can choose

whether or not to include him in any disclosures that you might choose

to make.
The arguments about whether or not Full Disclosure is a good idea or

not, and whether or not the "black hat" and "grey hat" and "white hat"

security research firms are unalloyed forces for good, or whether they

have downsides (and some might say very serious downsides) have been

arguments that I have personally witnessed for over two decades

(Speaking as someone who helped to dissect the Robert T. Morris

Internet Worm in 1988, led the Kerberos development team at MIT for

many years, and chaired the IP SEC Working Group for the IETF, I have

more than my fair share of experience).  It is clear that we're not

going settle this debate now, and certainly not on the Linux Kernel

Mailing List.
Suffice it to say, though, that there are people whose views on these

matters span the entire gamut, and...
[ message continues ]

Hello!
not that new, just not a subscriber, but i've been following it on and
Linus has just explained that he does *not* have any stand on full
yes, he does that. what he doesn't do is mention the fact that he's
Ted, the discussion is *not* about what the best disclosure policy

would be for the kernel. the problem i raised was that there's one

declared policy in Documentation/SecurityBugs (full disclosure) yet

actual actions are completely different and now Linus even admitted

it. the problem arising from such inconsistency is that people relying

on the declared disclosure policy will make bad decisions and potentially

endanger their users. there're two ways out of this sitution: either

follow full disclosure in practice or let the world at large know

that you (well, Linus) don't want to. in either case people will adjust

their security bug handling processes and everyone will be better off.
cheers,

  PaX Team
--

Huh?
How does what is described there differ from what Linus said, or the

-stable team has been doing so far?
What specifically are you asking for that is different?
The -stable commits are exactly the same as they are in mainline

(Linus's tree).  Are you upset by the fact that I am not saying, "Hey,

look, here's a bugfix that might be security related and here's how to

reproduce it!" in big flashing letters?
thanks,
greg k-h

--

read his mails and my responses, it's all in there. basically, he said

so himself that he knowingly withholds information. no matter how you spin

that, that's not full disclosure. note that i'm not advocating for using

that disclosure policy for kernel bugs, it's what *you* guys chose and

i'm just asking why you're not practicing it. you're also free to change
that doc says full disclosure, it doesn't say 'but withholding this

or that'. if you don't know what 'full disclosure' means then you're

welcome to ask on proper security mailing lists such as bugtraq or
yes, you should include that at least. i didn't say that btw, your fellow

-stable maintainer did:
  Had I realized there was a security issue, I would highlight it in the

  announce message.  In fact, that's our standard procedure for -stable.

  (http://lkml.org/lkml/2008/6/10/328)
the 2.4 maintainer agreed with him:
  I don't like obfuscation at all WRT security issues, it does far more

  harm than good because it reduces the probability to get them picked

  and fixed by users, maintainers, distro packagers, etc...

  (http://lkml.org/lkml/2008/6/10/452)
i think you're outgunned here Greg. and no, i'm not upset (after all, i'm

the one catching you cover up security bugs, right? you're not hurting me),
no, that doesn't really belong there but it's a nice addition for certain

people.
Greg, instead of pretending to be surprised and upset or whatever, go

read the whole thread first.
cheers,

  PaX Team
--

From: Greg KH <greg@kroah.com>
Don't sweat it Greg.
This complaint about "full disclosure" is coming from someone who isn't

even willing to communicate with the world using his real name.
The ultimate irony, in my book :-)

--

you too are welcome to read the thread. the issue is not full disclosure

per se, but your not practicing what you promised. that can be changed

either way. as for my real name, it's John Smith. will you take me now
your using of this anonymous person's code is probably an even bigger irony ;)
http://lkml.org/lkml/2004/7/1/30
--

From: pageexec@freemail.hu
It's not about whether your code is correct or not, in that particular

case it was, and I therefore merged it.
And at the time, if you recall, I did give you a piece of my mind

about having to attribute your work using an email that didn't refer

to a real person's name.

--

Does a symbolic reference change the truth behind it? No, it doesn't.

Nor does "David Miller" change the utter idiocy of your commentary.
--t

--

From: Tiago Assumpcao <tiago@assumpcao.org>
That's not the point.
The point is that he's a hypocrit because he's not willing to give the

world what he expects the world to give back to him.
That's, basically, unreasonable.

--

The point that is not is that of his identity. Be it true or false the

inadequacy of his anonymity.
BTW, it seems like one previous e-mail regarding the relevant point of

the discussion has never arrived. I'll give it a try on resending.
--t

--

where did i expect the world to give out his/her/its real name? also, i'm

not talking in my own name really, i don't personally care whether you cheat

in your security bug statistics or not, i know better than that and so do

many people in the security industry and elsewhere. the actual damage is

done to innocent users who may not get timely fixes because you covered them

up despite having promised not to do so. any other discussion is irrelevant,
--

Yes. Because the only place I consider appropriate is the kernel

changelogs, and since those get published with the sources, there is no

way I can convince myself that it's a good idea to say "Hey script 
Umm. And they mostly do a crap job at it, only focusing on a small

percentage (the ones that were considered to be "big issues"), and because

they do the reporting they also feel they have to have embargoes in place.
That's why I don't do reporting - it almost inevitably leads to embargoes.
So as far as I'm concerned, "disclosing" is the fixing of the bug. It's

the "look at the source" approach.
		Linus

--

if you worry about script kiddies (btw, for someone not bothering with

the whole security circus you surely do use their terms as bogeymen

to rationalize your stand) triggering or even exploiting local kernel

bugs then you imply that they're already local users on that box and

that in turn means they have already been having fun all that time.

just remember how Andrew put it:
  But there are so many ways to cripple a Linux box once you have

  local access. (http://lkml.org/lkml/2005/1/12/379)
in other words, try a better argument, possibly without bogeymen.
next, what about, say, sysadmins	, bigger and smaller distro maintainers,

etc trying to figure out whether they need to backport a given fix or

not? do you think you're helping them too?
on a sidenote, what do you know about script kiddies? how do you think

they operate? do you think they're watching a real-time rss from kernel.org

to catch the latest and greatest security fixes? do you think they can

write PoC or actual exploit code based on commits?
last but not least, if i submitted a security fix with the commit message

actually saying that it fixes a security problem, would you remove that

information before committing? based on the above that sounds as a 'yes',
people consider and backport patches that come to their attention,

which in turn happens by their scanning the changes, following various

threads of discussions (both public and private, depending on what they

have access to), etc. if you withhold security impact information then

you're skewing their 'big issue' detector as well, further reducing
i don't see you embargo normal bug fixes, why would you embargo security
when you fix a bug, the commit describes what it fixes without omitting

anything relevant. when you fix a security bug, its commit doesn't say

what it fixes (not even that it's a security fix, never mind actual

impact information), that is, you omit relevant information (based on

some ill-conceived argument that i deconstructed at the be...
[ message continues ]

You know what - when nobody does embargoes, I'll consider your argument to

have a point.
In the meantime, I'm not in the least interested in your idiotic 
Exactly. I don't embargo them. I refuse to have anything to even _do_ with

organizations like vendor-sec that I think is a corrupt cluster-fuck of

people who just want to cover their own ass.
They're just normal bugs.
But that also doesn't mean that I see any reason to make it obvious what

to do to trigger them, and cause problems at universities and such. So I

don't do "here's how to exploit it" commit logs, for example.
(If you haven't been at a univerisity, you don't know how many smart young

people want to "try it to see". And if you have been there, and don't

think it's a problem when they do and wouldn't be happier if they didn't,

you probably don't know what the word "empathy" means).
			Linus

--

Btw, and you may not like this, since you are so focused on security, one

reason I refuse to bother with the whole security circus is that I think

it glorifies - and thus encourages - the wrong behavior.
It makes "heroes" out of security people, as if the people who don't just

fix normal bugs aren't as important.
In fact, all the boring normal bugs are _way_ more important, just because

there's a lot more of them. I don't think some spectacular security hole

should be glorified or cared about as being any more "special" than a

random spectacular crash due to bad locking.
Security people are often the black-and-white kind of people that I can't

stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in

that they make such a big deal about concentrating on security to the

point where they pretty much admit that nothing else matters to them.
To me, security is important. But it's no less important than everything

*else* that is also important!
			Linus

--

True, there are other serious types of bugs (silent data corruption is one particularly nasty one). However, for *any* serious bug, it's important to be clear on what the likely impact is and what's affected. This goes particularly for the ones that might otherwise not be obvious to the person affected until it's too late, such as security and silent data corruption bugs, but really it applies to all serious bugs. I'm not convinced these descriptions are clear enough.
Aidan

--

diff --git a/Makefile b/Makefile

index 3eb71f8..e26eb7d 100644

--- a/Makefile

+++ b/Makefile

@@ -1,7 +1,7 @@

 VERSION = 2

 PATCHLEVEL = 6

 SUBLEVEL = 25

-EXTRAVERSION = .9

+EXTRAVERSION = .10

 NAME = Funky Weasel is Jiggy wit it
 # *DOCUMENTATION*

diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c

index d2e39e6..5f04579 100644

--- a/arch/x86/kernel/i387.c

+++ b/arch/x86/kernel/i387.c

@@ -130,7 +130,7 @@ int xfpregs_get(struct task_struct *target, const struct user_regset *regset,

 		void *kbuf, void __user *ubuf)

 {

 	if (!cpu_has_fxsr)

-		return -ENODEV;

+		return -EIO;
 	init_fpu(target);
@@ -145,7 +145,7 @@ int xfpregs_set(struct task_struct *target, const struct user_regset *regset,

 	int ret;
 	if (!cpu_has_fxsr)

-		return -ENODEV;

+		return -EIO;
 	init_fpu(target);

 	set_stopped_child_used_math(target);

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c

index 9003e0b..a10ba65 100644

--- a/arch/x86/kernel/ptrace.c

+++ b/arch/x86/kernel/ptrace.c

@@ -1309,42 +1309,49 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)

 		break;
 	case PTRACE_GETREGS:	/* Get all gp regs from the child. */

-		return copy_regset_to_user(child, &user_x86_32_view,

-					   REGSET_GENERAL,

-					   0, sizeof(struct user_regs_struct32),

-					   datap);

+		ret = copy_regset_to_user(child, &user_x86_32_view,

+					  REGSET_GENERAL,

+					  0, sizeof(struct user_regs_struct32),

+					  datap);

+		break;
 	case PTRACE_SETREGS:	/* Set all gp regs in the child. */

-		return copy_regset_from_user(child, &user_x86_32_view,

-					     REGSET_GENERAL, 0,

-					     sizeof(struct user_regs_struct32),

-					     datap);

+		ret = copy_regset_from_user(child, &user_x86_32_view,

+					    REGSET_GENERAL, 0,

+					    sizeof(struct user_regs_struct32),

+					    datap);

+		break;
 	case PTRACE_GETFPREGS:	/* Get the child FPU state. */

-		return copy_regset_to_user(child, &user_x86_32_view,

-					   RE...
[ message continues ]